Subject: [mpls] RFC 4561 clarification

From: "Harish Sitaraman" <[email-masked]>
Date: Wed, 30 Jul 2008 11:47:15 -0400

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