Subject: Re: New Internet Draft: TE over Unnumbered Links

From: Kireeti Kompella <[email-masked]>
Date: Tue, 25 Jul 2000 01:56:37 -0700 (PDT)

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.

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

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

---

From: Markus Jork <[email-masked]>
Date: Tue, 25 Jul 2000 09:41:45 -0400

Kireeti/Rahul,

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

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

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 25 Jul 2000 10:52:42 -0700

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:

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

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

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

> a link to C with index Ic.  (I will add this to the next rev.)

This is what I assumed. Sounds fine. 

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

> 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

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 25 Jul 2000 11:12:53 -0700

Markus,

> 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 Resv message. The other alternative is to make router C add

Interesting use of LIH ! I think it is overloading LIH semantics..

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 26 Jul 2000 06:41:39 -0700

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.

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 26 Jul 2000 10:11:01 -0700

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.

       Ib1   Ib2       Ic

thanks,
rahul