The MPLS WG Archive

[Rahul Aggarwal <rahul@redback.com>]

Yakov,
I don't see why this needs to be specified. RSVP-TE draft does not impose
any restrictions on the ERO format. Hence it could carry the outgoing interface
index or the incoming. Thus there should be no need to specify this for the 
unnumbered case either. And going from the email exchange with Kireeti, the 
*incoming* interface index works just fine too. 

Just to be clear on terminology. I refer to Ib1 as the incoming and Ib2 as
the outgoing interface index.

A----------B----------C---------D
       Ib1   Ib2       Ic

thanks,
rahul


On Wed, Jul 26, 2000 at 06:41:39AM -0700, Yakov Rekhter wrote:
> Rahul,
> 
> Just to clarify, the ERO carries the *outgoing* interface index,
> not the *incoming* interface index (we'll clarify this in the next
> revision of the Internet Draft).
> 
> Yakov.
> 
> > Markus,
> > 
> > On Tue, Jul 25, 2000 at 09:41:45AM -0400, Markus Jork wrote:
> > > Kireeti/Rahul,
> > > 
> > > now you are confusing me. I thought the draft was pretty clear
> > > (although too concise).
> > > 
> > > 
> > > I thought it works like this:
> > > 
> > > A----------B----------C---------D
> > >  A1      B1 Ib         Ic
> > > 
> > > A-B is a numbered link, B-C and C-D are unnumbered.
> > > A1 and B1 are the interface addresses, Ib and Ic are the interface IDs
> > > and A, B, C and D are the router IDs.
> > > 
> > > Then, the ERO sent by A would be:
> > >   B1 Ib C Ic D  (or replace B1 with B)
> > > Router B would then forward this ERO:
> > >   C Ic D
> > > Router C would then forward this ERO:
> > >   D
> > > 
> > > This should work just fine and I thought it's what the draft says.
> > > Every router can verify whether it's the first subobject in the ERO
> > > and knows where to go next.
> > 
> > There could be different ways of generating EROs. Your approach is one of the
> m.
> > The earlier mails were considering the case where the ERO has the incoming
> > interface index and not the outgoing interface index. And there is still
> > the case described by Kireeti where A could erroneously send the ERO to 
> > some other router D.  
> > 
> > > 
> > > The only problem is filling in the RRO in the Resv message
> > > going back. One alternative is to make router C add "C Ic"
> > > to the RRO. It would know Ic from the LIH in the NHOP object of
> > > the Resv message. The other alternative is to make router C add
> > 
> > Interesting use of LIH ! I think it is overloading LIH semantics..
> > 
> > > "Ib C" to the RRO. It would have to look up Ib in the link state
> > > database. The second alternative is probably the right thing to do.
> > 
> > If you were to use the ERO format as described by you, I would prefer the
> > second approach. 
> > 
> > > 
> > > Markus
> > > 
> > > 
> > > > > C will receive the ero as <Ic>. Now C needs to check the ero to see if
> > > > > it belongs to the first subobject i.e. Ic. How should this check be don
> e?
> > > > > This goes back to (1) above.
> > > > 
> > > > I assume that C can tell which LSR it got the path msg from (i.e., B).
> > > > C then looks to see in its TE link state database if B is advertising
> > > > a link to C with index Ic.  (I will add this to the next rev.)
> > > > 
> > > > One could be more paranoid and add a router ID to the unnumbered ERO
> > > > subobject.  Then the check is: a) does the router ID of the LSR sending
> > > > the path msg match the router ID in the subobject? AND b) if so, is
> > > > that LSR advertising a link to me with the index in the subobject (Ic)?
> > > > This approach is slightly more likely to catch errors because there are
> > > > two checks.  Suppose for example A sent the first Path message to D (by
> > > > mistake) AND D didn't catch this error.  Suppose also that D has an
> > > > unnumbered link to C with index Ic (same as B's).
> > > > 
> > > > Now, when C gets the path msg from D (without the router ID), it will
> > > > erroneously accept it.  However, for this to happen: A made a mistake;
> > > > D missed the mistake; and D had the same ifindex to C as B did.
> > > > 
> > > > Thanks for your comments!
> > > > 
> > > > Kireeti.
> > > > 
> > > 
> > > 
> > 
> > 
>