The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Jul> msg00383



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

New Internet Draft: TE over Unnumbered Links

  • From: Rahul Aggarwal <rahul@redback.com>
  • Date: Tue, 25 Jul 2000 11:12:53 -0700
  • Cc: Kireeti Kompella <kireeti@juniper.net>, rahul@redback.com, mpls@UU.NET

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 them.
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 done?
> > > 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.
> > 
> 
>