The MPLS WG Archive

[Rahul Aggarwal <rahul@redback.com>]

Kireeti,
Thanks for the response. First of all the approach in the draft is pretty slick.
I have a few inline comments regarding some of the assumptions:


On Tue, Jul 25, 2000 at 01:56:37AM -0700, Kireeti Kompella wrote:
> Hi Rahul,
> 
> > A couple of comments:
> > 
> > 1. Maybe there is a need to enhance the semantics of the RSVP_HOP object
> > to work over unnumbered links. The ip address of the previous hop
> > could be set to the router id of the previous hop. 
> 
> 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.

I think there still is a need to enhance the semantics of the RSVP_HOP object.
Please 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).

Yes. The picture should have been:

A----------B-----------C
 Ia     Ib  Ib1        Ic

Now C will generate the interface id Ib1. 


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

Here is where the RSVP_HOP object is required. As per the RSVP spec B when
sending the path msg to C will set the source ip address to the sender's
address (i.e A's address). Hence there is no way for C to tell which LSR it
got the path msg from. If the RSVP_HOP object gives the router id of the PHOP, 
things work fine. I am curious to know how you do this. I can think of other
ways, but none of them will hold in all cases.


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

This is what I assumed. Sounds fine. 


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

Goes back to the previous point. How does C know the router id of the LSR 
sending the path msg? 

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

The situation does sound contrived, but I guess it can happen. I would be 
in favor of adding a router id to the ERO subobject. 

Thanks,
rahul