The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <8812A03F65CDD511AE98006008F5E8710677DCB6@hermes.hyperchip.com>, Phi
lip Matthews writes:
> 
> I would like to repeat my concerns with the proposal in
>    draft-ietf-mpls-nodeid-subobject-01
> 
> Though I strongly support the concept of a node-id sub-object,
> as it will be very useful for Fast Re-route,
> I remain concerned about the proposal to use one of the
> last unallocated flag bits in the RRO to indicate this object.
> 
> For those who have not read the draft, it proposes to use a flag
> bit in the IPv4 or IPv6 address subject to indicate that the address
> given in the subobject is not an interface address, but instead a router ID.
> Nodes that wanted to include both an interface address and their
> router id would include the IPv4 (or IPv6) subobject twice,
> one with the flag set and one not.
> 
> To me, a much more obvious method is to assign a new type code
> to the node-id subobject, rather than using a flag bit. Since there are
> currently 252 unassigned subcodes, but only 3 unassigned flag bits
> (or just 2 if this proposal goes through), it seems to me that
> there needs to be a strong justification to use up one of the
> three remaining bits.
> 
> I also feel that using a new type code would improve interoperability
> with nodes that do not support this flag.
> 
> 
> Am I missing something? Is there a good reason to use a flag bit?
> 
> - Philip


Currently in the ERO every other entry is a router-id but none are
identified as such.  This is not a requirement but it is current
practice.  Each hop sees its own router-id and then looks at the next
entry.  The RRO usually reflects what is in the ERO.

If the new type code is added to the RRO only, it still affects route
pinning (copy the RRO into the ERO replacing any loose hops).

If the nodes were changed to a new type code it would virtually insure
that an older router that didn't understand the change would cause an
interoperability problem.  If a bit is set, we can hope that the bit
is ignored, but I think that too is wishful thinking based on prior
attempts to add bits to the same flag.

If either approach causes interoperability problems with older nodes,
then a new type code would be preferable IMHO.  If so, it should be
noted that all routers MUST be upgraded before the feature is enabled,
and that an implementation MUST provide the ability to enable or
disable this feature by configuration.

Curtis