The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

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.
> > > 
> > 
> > 
> 
>