Subject: Node-id: Concerned about using one of the last RRO flag bits for this

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Jun 2003 09:48:24 -0400

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 04 Jun 2003 19:49:17 -0400

In message <[email-masked]>, Phi
> Am I missing something? Is there a good reason to use a flag bit?

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