Subject: Questions on unnumbered links

From: David Charlap <[email-masked]>
Date: Tue, 23 Oct 2001 20:38:44 -0400

I'm trying to make sense of draft-ietf-mpls-rsvp-unnum-02, and have
several questions.

1: We need to see the BNF for modified Path/Resv messages that include
   the new objects.  More specifically, when a LSP_TUNNEL_INTERFACE_ID
   object is included in a Resv message, should it be part of the
   flow descriptor or should it be part of the main body of the
   message.  IMO, it belongs in the flow descriptor, since a single
   Resv can be sent for multiple LSPs, and each one will require a
   separate LSP_TUNNEL_INTERNFACE_ID.

2: There is mention of an IF_ID RSVP_HOP object.  Where is this
   defined?  I don't see any reference to another draft, and it's
   certainly not defined locally.  If this is a GMPLS-specific object,
   then it obviously should not be used in an MPLS environment.

3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
   for specifying an unnumbered link in the HOP object), why is it
   necessary?  The existing HOP object already has a field for LIH,
   which appears to have the same functionality as the interface ID
   field in the new ERO/RRO subobjects.

4: Is there any way for an ingress router to compute an ERO with
   unnumbered links in it if GMPLS is not implemented?  It appears
   that support for unnumbered links was deleted from the TE versions
   of OSPF and ISIS, and moved into the GMPLS versions of those
   protocols, making the necessary information for ERO computation
   unavailable in an MPLS environment.

-- David

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 24 Oct 2001 06:40:50 -0700

David,

>    separate LSP_TUNNEL_INTERNFACE_ID.

Unless there are any objections from the other folks on the list
I'll add some text as you suggested above to the next version
of the draft.

>    then it obviously should not be used in an MPLS environment.

It is defined in GMPLS RSVP Signaling. I am going to add a reference
to that draft in the next revision of draft-ietf-mpls-rsvp-unnum.

>    field in the new ERO/RRO subobjects.

As I recall, this has been discussed in the past. And the conclusion
was that the currently defined semantics of LIH makes it unsuitable
for carrying inteface ID.

>    unavailable in an MPLS environment.

You certainly don't need to implement all the GMPLS routing and 
signaling extensions in order to support unnumbered interfaces.

Yakov.

---

From: George Swallow <[email-masked]>
Date: Wed, 24 Oct 2001 11:14:02 -0400

>    field in the new ERO/RRO subobjects.

I fought hard for this.  Turns out that it was underspecified for too
long and the text about having meaning only to the sender taken too
literally by some implementors.  Squatter's rights have prevailed and
we had to get a new field.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: David Charlap <[email-masked]>
Date: Wed, 24 Oct 2001 12:48:47 -0400

Yakov Rekhter wrote:
>>    that support for unnumbered links was deleted from the TE
>>    versions of OSPF and ISIS, and moved into the GMPLS versions of
>>    those protocols, making the necessary information for ERO
>>    computation unavailable in an MPLS environment.
> 

Understood.  But if an ERO is to be auto-generated, and not manually
entered, the box doing the computation needs to know the topology. 
Without the unnumbered extensions in OSPF/ISIS, any topology derived
from routing will not distinguish multiple parallel unnumbered links. 
This will make it impossible to compute an ERO that uses the new ERO
subobject to specify one such link.

It wouldn't be very nice to require all of GMPLS in order to compute an
ERO that specifies unnumbered links.

I hope my explanation of this problem is clear.

-- David

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 24 Oct 2001 13:25:59 -0400 (EDT)

Hi,

>    field in the new ERO/RRO subobjects.
-------> I guess the main reason this idea was dropped was because the LIH
coming in the RSVP_HOP Obj in the Path msg needs to be reflected back in
the RSVP-HOP Obj in the Resv. If this field is going to be changed during
the Resv then it is a problem.

-arthi

---

From: David Charlap <[email-masked]>
Date: Wed, 24 Oct 2001 13:40:52 -0400

Arthi Ayyangar wrote:
> I guess the main reason this idea was dropped was because the LIH
> coming in the RSVP_HOP Obj in the Path msg needs to be reflected
> back in the RSVP-HOP Obj in the Resv. If this field is going to be
> changed during the Resv then it is a problem.

Since when does a Resv message reflect back the HOP object received in a
Path???

The HOP object in a Resv message identifies the interface on the
downstream router that the Resv mesage is being sent from.  This is not
the same as the the HOP object from the corresponding Path message,
which identifies the interface on the upstream router that the Path
message is being sent from.

When links are numbered, these two objects will have different values. 
They will similarly have different values when the links are unnumbered.

-- David

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 24 Oct 2001 13:42:04 -0400 (EDT)

Hi,

> Since when does a Resv message reflect back the HOP object received in a
----> Not the addr but the LIH in the HOP needs to be reflected back.

"
 1.   When a node N forwards a Path message out a logical outgoing
           interface L, it includes in the message some encoding of the
           identity of L, called the "logical interface handle" or LIH.
           The LIH value is carried in the RSVP_HOP object.

      2.   The next hop node N' stores the LIH value in its path state.<<<

      3.   When N' sends a Resv message to N, it includes the LIH value
           from the path state (again, in the RSVP_HOP object).
	<<<<<<

      4.   When the Resv message arrives at N, its LIH value provides
           the information necessary to attach the reservation to the
           appropriate logical interface.  Note that N creates and
           interprets the LIH; it is an opaque value to N'.

"
-arthi

---

From: Eric Gray <[email-masked]>
Date: Wed, 24 Oct 2001 13:58:04 -0400

David,

    Maybe I missed something: I thought support for unnumbered links
needed to be added for GMPLS because there are problems with these
links in the general case.  I was not aware that there are problems with
unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
in basic signaling of MPLS explicit routes.

    What exactly are the problems with using unnumbered links in the
specific cases defined for MPLS?

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

---

From: Bora Akyol <[email-masked]>
Date: Wed, 24 Oct 2001 11:11:37 -0700

Eric

I think unnumbered links have value only in point-to-point links, I don't
think you can have unnumbered links on Ethernets.

The main problem with unnumbered links is that they are added as an
afterthought to both the ERO objects and the *-TE routing protocols.

I thought we had solved the issues that arise with the use of unnumbered
links by adding the TE router ID to the ERO object and by consistently
propagating this information via the routing protocols.

What still seems to be the issue?

Bora

---

From: David Charlap <[email-masked]>
Date: Wed, 24 Oct 2001 14:46:23 -0400

Eric Gray wrote:
> links in the general case.  I was not aware that there are problems
> with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> cases or in basic signaling of MPLS explicit routes.
>

Without extensions, an ERO can not specify which of several parallel
unnumbered links should be used for an LSP.

The unnumbered draft defines a new ERO subobject, which will allow for
this kind of specification.

But without thit unnumbered-link extensions in the IGP's topology, the
information necessary to compute an ERO using this subobject is not
present.

-- David

---

From: Bora Akyol <[email-masked]>
Date: Fri, 26 Oct 2001 09:46:01 -0700

Yes

And that object was based on my now expired draft in
draft-akyol-mpls-expanded-ero-00.txt

I guess as people get around to implementing this stuff, they realize that

they need more information. This is what happens when you first write the
draft and then write the code.

Additionally, there is quiet a few "implementation" decisions that you
make as you write the CSPF and traffic engineering database code as well.
Sounds like fun, it sure is.

Bora

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 26 Oct 2001 14:06:18 -0700 (PDT)

Bora,

> draft-akyol-mpls-expanded-ero-00.txt

I'm not sure what you mean by "that object"; the only reference to
an object in David's mail is

> this kind of specification.

The unnumbered draft (and the ERO subobject for specifying unnumbered
links) *preceded* your expired draft; what's your basis for claiming
that the ERO subobject is based on your draft?

Kireeti.

------------ Original Mail --------------

Date: Fri, 26 Oct 2001 09:46:01 -0700
From: Bora Akyol <[email-masked]>
To: David Charlap <[email-masked]>
CC: [email-masked]
Subject: Re: Questions on unnumbered links

Yes

Bora

---

From: Bora Akyol <[email-masked]>
Date: Fri, 26 Oct 2001 14:12:48 -0700

I accept I was being cryptic. The addition of the router ID to the unnumbered
ERO sub-object was based on the discussion the mpls mailing list triggered by
the draft-akyol-mpls-expanded-ero-00.txt draft.

The definition of the ERO subobject describing unnumbered interfaces prior to
the "Expanded ERO" draft did not include the router ID.

No intent to claim credit for the **entire** ERO sub-object on my part.

Bora