Subject: changes to unnumbered and link bundling

From: Yakov Rekhter <[email-masked]>
Date: Fri, 02 Nov 2001 09:01:57 -0800

Folks,

Based on the results of the e-mail exchange on this list
I plan to make the following changes in draft-ietf-mpls-bundle,
draft-ietf-mpls-rsvp-unnum, and in draft-ietf-mpls-crldp-unnum:

1) Mandate that one always use the IF_ID HOP on bundled links
   (thus eliminating the Implicit Indication from
    draft-ietf-mpls-bundle-00.txt).

2) Do away with the COMPONENT_IF_* TLV, and just use IF_INDEX for
   identifying (unnumbered) components in link bundling

3) Mandate that one always use the IF_ID HOP object on an unnumbered
   link.

4) Make handling numbered and unnumberd interfaces in the ERO
   more consistent/uniform by changing the semantics of the Unnumbered
   interface subobject (or more precisely the Interface ID field
   of this subobject) from:

       The Interface ID is the outgoing interface identifier with 
       respect to the LSR specified by the router ID.

   to

       The Interface ID is the interface identifier assigned to 
       the interface by the LSR specified by the router ID.

   and making other appropriate changes in the text to reflect this.

Yakov.

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 06 Nov 2001 10:31:12 -0500

Yakov

The proposed change is not quite clearly stated. Can you please
restate in more precise language. Is it possible to put a diagram
in the draft? E.g if we have nodes A,B,C,D with unnumbered i/f
1-6 (I have made them distict for ease of illustration):

      1       2   3          4   5      6 
    A --------- B ------------ C -------- D

The language in Section 6 of the unnum-02 draft would appear to 
mandate an unnumbered ERO as follows: A1,B3,C5

What are you proposing to change it to? Is it B1,C3,D5?

Or are you proposing that both of the above be allowed?

Please clarify.

Thanks
Nabil Seddigh
[email-masked]

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 06 Nov 2001 08:03:34 -0800

Nabil,

> 1-6 (I have made them distict for ease of illustration):

Certainly not, as I am proposing that "The Interface ID is the interface 
identifier assigned to the interface by the LSR specified by the router ID." 

With this in mind B1 is not a valid combination, as the interface
identifier 1 is assigned by A, not by B. And with my proposal
you can't put in the Unnumbered Interface subobject the
interface identifier assigned to the interface by one LSR, and
the router ID of some other LSR.

Ditto for C3 and D5.

Yakov.

P.S. Just like a numbered interface on an LSR is identified by the
IP address that the LSR assigns to that interface, I am suggesting
that an unnumbered interface be identified by the identified
(i/f index) that the LSR assigns to that interface and the Router-ID
of the LSR itself.

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 06 Nov 2001 11:10:55 -0500

Yakov

For the simple example below, based on your proposal what would
the ERO look like?

Thanks
Nabil Seddigh

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 06 Nov 2001 08:18:42 -0800

Nabil,

> For the simple example below, based on your proposal what would

Exactly the same, as if the interfaces would be numbered. That
is, construct the ERO assuming that all interfaces are numbered.
Then replace each IP address with a tuple <interface id, Router-ID>.

Yakov.

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 6 Nov 2001 09:41:22 -0800

This is similar to the discussion we had on the expanded ERO issue
(draft-akyol-mpls-expanded-ero-00.txt, now expired) a while ago. I concur
with Yakov that one has to identify unnumbered interfaces by the tuple
(Router ID, ifindex) where ifindex is some 32 bit quantity assigned by the
router that is advertising this interface in the IGP TE advertisements.

If one does sit on a broadcast media where a router may have multiple
interfaces sitting on the same segment, then even the proposal below is not
sufficient to uniquely identify the full path specified by the ERO.

As A1 uniquely identifies the egress interface out of A, but we can not
identify (assuming that this is happening on an Ethernet segment where B has
multiple interfaces connected) which ingress interface of B we want to use.

Which is why I think, the best way to specify an ERO is to write
Router ID, Egress Interface, Router ID, Ingress Interface

This leaves pretty much nothing to "interpretation" and results in a precise
definition.

If there is interest, I may revive the expanded ERO draft.

Bora

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 06 Nov 2001 13:31:35 -0500

Yakov,

From what you write below, the ERO will be B2,C4,D6.
Is this correct?

Another question: is your proposal precluding an ERO of
A1,B3,C5?

Best,
Nabil Seddigh

>>>
>>> Certainly not, as I am proposing that "The Interface ID is 
>>> the interface identifier assigned to the interface by the LSR 
>>> specified by the router ID.
> "
> > >

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 06 Nov 2001 15:20:22 -0800

Nabil,

> >From what you write below, the ERO will be B2,C4,D6.

yes, this is certainly a valid option.

> Another question: is your proposal precluding an ERO of

no, it doesn't preclude this.

Yakov.

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 06 Nov 2001 19:04:39 -0500

Yakov

The next question is just begging to be asked. If both B2,C4,D6
and A1,B3,C5 are valid EROs, does this not pose interoperability
problems?

Maybe it's useful to add a field in the unnum ero subobject 
that specifies whether the i/f is outgoing or incoming relative
to the router id. The draft could also mandate that all ero
subobjects in a PATH msg must be of the same type - i.e. 
have i/f that are incoming or outgoing.

Best,
Nabil

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 06 Nov 2001 17:00:24 -0800

Nabil,

> and A1,B3,C5 are valid EROs, does this not pose interoperability

No more no less than if the interface would be numbered.

> have i/f that are incoming or outgoing.

there is no such restriction when interfaces are numbered.
Therefore, there is no need to place such restriction when
interfaces are unnumbered.

Yakov.

---

From: Nabil Seddigh <[email-masked]>
Date: Wed, 07 Nov 2001 11:54:01 -0500

Yakov,

I agree that the RSVP-TE-09 draft section 4.3.3.2 doesn't explicitly
state if the numbered ip addr is outgoing or incoming. However,
I think it's generally accepted that the ERO ip sub-object 
always specifies the next-hop incoming interface ip address?

I don't believe this is the case for unnumbered. Some folks seem
to want outgoing i/f while others want incoming i/f while yet
others propose both incoming and outgoing i/f be specified 
(Bora Akyol's draft).

I think something precise needs to be written in the unnumbered 
draft. For that matter, I think section 4.3.3.2 of the rsvp-te-09
can also benefit from added precision.

Best,
Nabil