Re: [mpls] RFC 4561 clarification

[Kenichi AOYAGI <[e-mail]>]

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" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls




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