Subject: RE: Simplification for UNNUM draft.

From: "Kullberg, Alan" <[email-masked]>
Date: Wed, 24 Oct 2001 11:44:43 -0400

George,

I like the change you suggest.  See 2 comments below.

Alan

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2001 5:17 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Simplification for UNNUM draft.
> 
> 
> 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.  

If the interface identified by the Unnumbered Interface ID ER Hop is
bundled, then the last sentence causes a problem.  How about if the last
sentence is changed to:

   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,
   except when the interface identified by the Unnumbered Interface
   ID subobject is bundled, in which case the IF_INDEX contains
   the component ID of the selected component.

Note that this suggestion assumes that a change will be made to
the GMPLS Signaling draft as discussed on the CCAMP mail list
starting on 9/12/01 with the subject line:
   "FW: Questions on draft-ietf-mpls-bundle-00"

Following is an excerpt from Edward Harrison's email with the above
subject dated 9/13/2001, to which there was no reply from the authors:

   Yakov,

   > > Can you clarify whether you are proposing removing the
   COMPONENT_IF_UPSTREAM
   > > TLV from the INTERFACE_ID hop object (or were you just saying that
Steve
   > > needn't use it if he doesn't want to)?
   > 
   > I am proposing to remove the COMPONENT_IF_UPSTREAM.

   In this case, am I right in thinking it makes sense to remove
   COMPONENT_IF_DOWNSTREAM too, and signal the (single) component interface
   identifier, in the IPv4, IPv6 or IF_INDEX TLV?

   We'd be interested to hear if anyone on the mailing list finds this
approach
   overly restrictive.

   Ed.

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

Did you mean step 3 in above instead of step 2?

> 
>    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: George Swallow <[email-masked]>
Date: Wed, 24 Oct 2001 12:15:56 -0400

>    the component ID of the selected component.

This is fine by me.  It's the way I suggested it last December!

> Did you mean step 3 in above instead of step 2?

Yes.  Thanks.

...George

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