The MPLS WG Archive

[Philip Matthews <pmatthews@hyperchip.com>]

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

See my comments inline.

- Philip

PS. My apologies to those who see this message as something other than
    plain text. It seems that Microsoft Outlook, when configured to send
    Plain-Text messages, actually sends multi-part MIME messages with both
    plain-text and Rich Text. If anyone knows how to fix this, please e-mail
    me privately.

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: 2003-Jun-04 19:49
> To: Philip Matthews
> Cc: mpls@UU.NET
> Subject: Re: Node-id: Concerned about using one of the last RRO flag
> bits for this
>
>
>
> 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.

Hmmm... My testing department tells me one major router vendor generates
EROs that look like
        (strict, ingress-address-on-rtr2)
      (strict, egress-address-on-rtr2)
      (strict, ingress-address-on-rtr3)
      (strict, egress-address-on-rtr3)
      (strict, ingress-address-on-rtr4)
      (strict, egress-address-on-rtr4)
      ...
while the other major vendor generates EROs that look like:
        (strict, ingress-address-on-rtr2)
      (strict, ingress-address-on-rtr3)
      (strict, ingress-address-on-rtr4)
      ...
and neither includes router ids in its ERO.
I haven't investigated this myself.

>
> 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.

Well, perhaps it is wishful thinking on my part, but I was hoping that
most routers supported section 4.4.5 of RFC 3209, which starts:

    4.4.5. Forward Compatibility

       New subobjects may be defined for the RRO.  When processing an RRO,
       unrecognized subobjects SHOULD be ignored and passed on. 
       [Rest of text omitted]

My thought was that all routers would include the existing sub-object
and use it to specify the egress interface (as described in section 4.4.3).
In addition, routers that wanted to include their router id would include
the new Node-ID subobject, which would be ignored by routers that did not
understand it. Routers that want to do route pinning would create the ERO
from the RRO by stripping out sub-objects they did not understand.

>
> 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.
>

Perhaps one of the authors of the draft might say why they chose the
flag bit approach?

- Philip