Subject: Simplification for UNNUM draft.

From: George Swallow <[email-masked]>
Date: Tue, 23 Oct 2001 17:16:55 -0400

draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
IF_ID Hop object to be used on an unnumbered link.  This leads to
unnecessary cases and extra checking at the incoming interface.

I suggest the following modifications:

a) mandate that one always use the IF_ID HOP object on an unnumbered
   link.

b) pop the unnumbered interface subobject off of the ERO before
   forwarding the Path message over the unnumbered link (the
   information is now in the PHOP

I've updated the text in sections 6.1 and 6.2 to reflect the changed
procedures.  If it looks a bit complicated it's only because I was
explicit about the interactions with the processing rules of [RSVP-TE]
where the current draft is underspecified.

Comments?

...George

======================================================================

6.1. Processing the Unnumbered Interface ID Subobject

   The Unnumbered Interface ID Subobject is related to the IF_ID
   RSVP_HOP object as follows.  Under normal (unerrored) processing,
   an Unnumbered Interface ID Subobject is removed from the ERO by the
   node who's router ID is contained in the object.  The link
   specified in that object is communicated to the following node by
   means of the IF_ID RSVP_HOP object.  The IF_ID RSVP_HOP object in the
   Path message MUST contain the same Router ID (IP Address) and
   IF_INDEX as carried in the Unnumbered Interface ID subobject.  

6.1.1.  ERO processing

   The ERO processing rules of [RSVP-TE] apply with the following
   exceptions.  In step 2 of section 4.3.4.1 if the first object is an
   Unnumbered Interface ID subobject and the node is also part of the
   second object abstract node and that node is loose, then a copy of
   the first object is saved for use in step 5b before it is deleted
   from the ERO.

   In step 4, if the first subobject is an Unnumbered Interface ID
   subobject the determination of topological adjacency is limited to
   the interface specified in the first object.

   In step 5, if the first object is loose but the previous object
   (saved as a result of step 2 above) is an Unnumbered Interface ID
   object, then the selection of the next hop is determined by the
   saved object.  

   In step 5b if the first object is an Unnumbered Interface ID
   subobject, then the selection of the next hop is determined by the
   saved object.

6.1.2.  Determination of the next hop

   The next hop is determined as follows.  The
   Interface ID in the subobject MUST refer to an outgoing interface
   identifier that this node allocated; if not, the LSR SHOULD return
   a "Bad EXPLICIT_ROUTE object" error. The next hop is the LSR at the
   other end of the link that the Interface ID refers to. If this is
   the LSR itself, the subobject is removed, and the process
   repeated. If the next hop is some other LSR, then this is the next
   hop to which a Path message must be sent.

6.1.3.  Forwarding the Path message

   When sending a Path message to the next hop, the IF_ID RSVP_HOP
   object MUST be used.  This object MUST contain the IF_INDEX TLV,
   with IP Address in that TLV set to the LSR's Router ID, and
   Interface ID set to the Interface ID carried which was carried in
   the Unnumbered Interface subobject.

6.2.  Processing the IF_ID RSVP_HOP object

   When a Path message is received containing the IF_ID RSVP_HOP
   object with the IF_INDEX TLV, the following processing rules apply.

   The LSR checks whether the tuple <Router ID, Interface ID> from the
   Unnumbered Interface subobject matches the tuple <Router ID,
   Forward Interface ID> of any of the LSPs for which the LSR is a
   tail-end. If a match is found, the match identifies the Forwarding
   Adjacency for which the LSR has to perform label allocation.

   Otherwise, the LSR MUST check whether the tuple <Router ID, Interface
   ID> from the Unnumbered Interface subobject matches the tuple <Router
   ID, Reverse Interface ID> of any of the bidirectional LSPs for which
   the LSR is the head-end. If a match is found, the match identifies
   the Forwarding Adjacency for which the LSR has to perform label
   allocation, namely, the reverse Forwarding Adjacency for the LSP
   identified by the match.

   Otherwise, the LSR must have information about the identifiers
   assigned by its neighbors to the unnumbered links (i.e., incoming
   interface identifiers from LSR's point of view). The LSR uses this
   information to find a link with tuple <Router ID, incoming interface
   identifier> matching the tuple <Router ID, Interface ID> from the
   Unnumbered Interface subobject. If the matching tuple is found, and
   the link is not a bundled link, the match identifies the link for
   which the LSR has to perform label allocation. If the matching tuple
   is found, and the link is a bundled link, the LSR follows the
   procedures for label allocation as described in [LINK-BUNDLE].

   Otherwise, the LSR SHOULD return a "Bad initial subobject" error.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 23 Oct 2001 16:34:51 -0700

George,

> where the current draft is underspecified.

If we mandate the use of IF_ID HOP for unnumbered, let me also
suggest that we mandate the use of IF_ID HOP for link bundling,
(thus eliminating the Implicit Indication from
draft-ietf-mpls-bundle-00.txt).

Comments ?

---

From: George Swallow <[email-masked]>
Date: Wed, 24 Oct 2001 10:37:57 -0400

> draft-ietf-mpls-bundle-00.txt).

Fine by me.

...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:52:10 -0400

> suggest that we mandate the use of IF_ID HOP for link bundling,

If we mandate the use of IF_ID HOP for unnumbered links, then the
object's definition needs to be moved into the unnumbered link draft,
since it will no longer be a GMPLS-specific object.

-- David

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 29 Oct 2001 08:35:45 -0800

George,

>    information is now in the PHOP

May I also suggest that we change the semantics of the Unnumbered
Interface ID subobject in the ERO 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 incoming interface identifier with respect to
   the LSR specified by the router ID.

Yakov.

---

From: George Swallow <[email-masked]>
Date: Mon, 29 Oct 2001 11:40:19 -0500

That would be fine.  In fact in that case, the upstream router would
not have to pop off the subobject, since the next node would receive a
an ero which has a valid first object.

...George