The MPLS WG Archive

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



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

New Internet Draft: TE over Unnumbered Links

  • From: Markus Jork <mjork@avici.com>
  • Date: Tue, 25 Jul 2000 09:41:45 -0400
  • cc: rahul@redback.com, mpls@UU.NET

Kireeti/Rahul,

now you are confusing me. I thought the draft was pretty clear
(although too concise).

[...]
> In our first pass at this draft, the ERO subobject included both a
> router ID (of the PHOP) and the interface index.  We then decided
> that just the interface index is sufficient; see below.
> 
> > 2. This is more of a clarification. Consider:
> > A----------B-----------C
> >  Ia     Ib          Ic
> > 
> > The link from B to C is unnumbered. My understanding from the draft is 
> > that B will generate the interface id for Ic. (and C for Ib) Is that
> > correct? 
> 
> B will indeed generate the interface id Ic, but C has nothing to do
> with Ib (as I see your picture).
> 
> > The ero could be <Ib, Ic>. Since B generated the id for Ic, it will know the
> > outgoing interface to send the path msg to C.
> 

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.

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

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