Subject: Re: [mpls] RFC 4561 clarification

From: Kenichi AOYAGI <[email-masked]>
Date: Wed, 13 Aug 2008 17:58:12 +0900

Hi all,

I just started studying MPLS FRR recently and have read RFC 3209 & RFC 4561.
I have some questions regarding the interpretation of these standards.

As Harish mentioned, it seems the order of <I, L> in the RRO
should be kept as specified by RFC 3209. I think this order should also be 
kept even when RFC 4561 is also supported (e.g., when the node-id
sub-object is pushed onto RRO).

Therefore, as Harish mentioned, it is reasonable that the formats: <N, L,
I>, <I, L, N>, <N, L> and <I, N, L> are not allowed.

On the other hand, only the formats like <I, L>, <N, I, L>, <N, L, I, L>
and <I, L, N, L> are allowed when RFC 3209 and RFC 4561 are supported.

However, <N, L> is indicated as an example of implementation in RFC 4561.

 Section 3:

   An implementation may decide to either:

   1) Add the node-id sub-object in the RRO carried in an RSVP Resv
      message and, when required, also add another IPv4/IPv6 sub-object
      to record interface address.

In my understanding, RFC 3209 has not been obsoleted or updated by RFC4561 
although it has been updated some other RFCs as quoted below.

-------- quote from RFC index -----------

3209 RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche, L.
     Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001.
     (Format: TXT=132264 bytes) (Updated by RFC3936, RFC4420, RFC4874,
     RFC5151) (Status: PROPOSED STANDARD)

----------- end -------------------------
I think it is confusing since the order <N, L>is not allowed by RFC 3209.

Why is the implementation of the pushing the interface-address sub-object
onto RRO not mandatory in RFC 4561 while it is mandatory in RFC3209?

Has any vendor implemented using <N, L> format?

Any suggestion or comments are appreciated.

Regards,
- Kenichi

On Wed, 30 Jul 2008 11:47:15 -0400
"Harish Sitaraman" <[email-masked]> wrote:
> 
> Hi,
> 
> Regarding RFC 4561: Definition of RRO Node-Id Sub-Object
> 
> RFC 4561 does not seem to clearly specify certain details regarding the 
> allowed formats in the RRO and how such information in the RRO could be
> parsed by a PLR.
> 
> Would it be possible for somebody to provide some clarifications for the
> 
> following issues ? 
> --
> 
> For the purpose of this discussion, we would like to use the following
> symbols:
> 
> N   = node-id (node-id sub-object)
> I   = interface-address (IPv4 sub-object)
> L   = label
> |   = marker distinguishing information from adjacent nodes
> < > = Order of RRO information from a single node
> 
> 1. Section 3 seems to allow various formats in the RRO when adding the
> node-id
>    sub-object. Its not clear whether points (1) and (2) list the set of
> formats
>    that are allowed or if these just serve as examples of certain
> formats.
>    
>    From interpretation, it seems like the following are allowed:
> 
>    Point (1) example: <N, L> ; <N, I, L> , <N, L, I>, <I, N, L>, <I, L,
> N>
> 
>    Point (2) example: <I, L, N> though the order of the objects is not
>                       specified. 
> 
>    If <N, L, I> , <I, L, N> and <N, L> are allowed, then these are not
> compliant 
>    with RFC 3209 since only interface addresses seem to be allowed in
> the IPv4
>    sub-object and the IPv4 sub-object is pushed after pushing the label.
> 
>    Section 4.4.1.1. Subobject 1: IPv4 address:
> 
>      IPv4 address
> 
>          A 32-bit unicast, host address. Any network-reachable
>          interface address is allowed here. Illegal addresses, such as
>          certain loopback addresses, SHOULD NOT be used.
> 
>    Section 4.4.3:
> 
>          The newly added subobject MUST be this router's IP address. The
>          address to be added SHOULD be the interface address of the
> outgoing
>          Path messages.  If there are multiple addresses to choose from,
> the
>          decision is a local matter.  However, it is RECOMMENDED that
> the same
>          address be chosen consistently.
> 
>          The Label Record subobject is pushed onto the RECORD_ROUTE
> object
>          prior to pushing on the node's IP address.  A node MUST NOT
> push on a
>          Label Record subobject without also pushing on an IPv4 or IPv6
>          subobject.
> 
> 
>    RFC 3209 provides clear guidelines regarding the order in which
> objects are
>    pushed on the stack.
> 
>    Such stacking guidelines when pushing a node-id sub-object are
> required. 
> 
>    Considering the above (and since RFC 4561 does not update RFC 3209),
> it  
>    seems like the following formats should not be allowed:
> 
>    <N, L, I>,  <I, L, N>, <N, L>, <I, N, L>
> 
> 2. Section 1 provides the techniques that are used by a PLR in selecting
> a
>    bypass (backup) tunnel. It seems like the description assumes the 
>    existence of a traffic-engineering database and that the IGP-TE 
>    extensions are enabled in the network.
> 
>    There are network scenarios where IGP-TE extensions are not enabled,
> yet LSPs
>    are established using the information provided by the IGP. 
> 
>    This makes it difficult for a PLR to accurately parse the RRO to find
> the 
>    MP address depending on the RRO formats added by downstream routers.
> The
>    addresses added by a node can be incorrectly parsed as belonging to
> the next node.
> 
>    Few examples to illustrate the issue of an upstream node trying to
> differentiate
>    between the formats just by parsing the received RRO:
> 
>    <N L> | <I L> | <I L>
>    and
>    <N L I L> | <I L>
> 
>    <N L I> | <N L>
>    and
>    <N L> | <I N L>
> 
>    <I L N> | <I L>
>    and
>    <I L> | <N I L>
> 
>    <N L I> | <N L> 
>    and
>    <N L> | <I N L>
> 
>    <N I L> | <N L I L>
>    and
>    <N I L> | <N L> | <I L>
> 
>    As seen above, its not possible to clearly find the information added
> by a
>    single node since there isn't any delimiter (label ?) in the RRO.
> This also
>    serves to illustrate that allowing formats that include the label in
> between
>    the addresses makes it difficult to parse the RRO.
> 
>    Using the traffic-engineering database to validate the addresses in
> the above
>    formats to find the set of addresses that belong to a single node
> doesn't work
>    in the inter-area/AS case (especially for node-protection), assuming
> a TE database
>    exists. 
> 
> Thanks,
> Harish
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Harish Sitaraman" <[email-masked]>
Date: Thu, 14 Aug 2008 14:57:55 -0400

Hi,

[Reposting earlier message]

Would it be possible for the RFC authors to provide some clarifications
on the following issues ? 
--

1. Section 3 seems to allow various formats in the RRO when adding the 
   node-id sub-object. Its not clear whether points (1) and (2) list the
set 
   of formats that are allowed or if these just serve as examples of
certain 
   formats.

   Point (1) example: <N, L> ; 
                      <N, I, L> , <N, L, I>, <I, N, L>, <I, L, N>

   If <N, L, I> , <I, L, N> and <N, L> are allowed, then these are not 
   compliant with RFC 3209 since only interface addresses seem to be 
   allowed in the IPv4 sub-object and the IPv4 sub-object is pushed
after 
   pushing the label.

     IPv4 address

   Section 4.4.3:

         The newly added subobject MUST be this router's IP address. The
         address to be added SHOULD be the interface address of the 
         outgoing Path messages.  If there are multiple addresses to 
         choose from, the decision is a local matter.  However, it is 
         RECOMMENDED that the same address be chosen consistently.

         The Label Record subobject is pushed onto the RECORD_ROUTE 
         object prior to pushing on the node's IP address.  A node 
         MUST NOT push on a Label Record subobject without also 
         pushing on an IPv4 or IPv6 subobject.

   RFC 3209 provides clear guidelines regarding the order in which
objects are pushed on the stack.

   Considering the above (and since RFC 4561 does not update RFC 3209), 
   it seems like the following formats should not be allowed:

2. Section 1 provides the techniques that are used by a PLR in selecting
   a bypass (backup) tunnel. It seems like the description assumes the 
   existence of a traffic-engineering database and that the IGP-TE 
   extensions are enabled in the network.

   There are network scenarios where IGP-TE extensions are not enabled,
   yet LSPs are established using the information provided by the IGP. 

   the MP address depending on the RRO formats added by downstream
routers. 
   The addresses added by a node can be incorrectly parsed as belonging 
   to the next node.

   Few examples to illustrate the issue of an upstream node trying to 
   differentiate between the formats just by parsing the received RRO:

   <N L> | <I L> | <I L>
   and
   <N L I L> | <I L>

   <N L I> | <N L>
   and
   <N L> | <I N L>

   <I L N> | <I L>
   and
   <I L> | <N I L>

   <N L I> | <N L> 
   and
   <N L> | <I N L>

   <N I L> | <N L I L>
   and
   <N I L> | <N L> | <I L>

   As seen above, its not possible to clearly find the information added
   by a single node since there isn't any delimiter (label ?) in the
RRO. 
   This also serves to illustrate that allowing formats that include the

   label in between the addresses makes it difficult to parse the RRO.

   Using the traffic-engineering database to validate the addresses in 
   the above formats to find the set of addresses that belong to a
single 
   node doesn't work in the inter-area/AS case (especially for
node-protection), 
   assuming a TE database exists. 

Thanks,
Harish