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

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Jun 2003 13:48:19 -0400

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:[email-masked]]
> Sent: 2003-Jun-04 19:49
> To: Philip Matthews
> Cc: [email-masked]
> Subject: Re: Node-id: Concerned about using one of the last RRO flag
> bits for this
> 
> 
> 
> In message 
> <[email-masked]>, 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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 05 Jun 2003 15:10:17 -0400

In message <[email-masked]>, Phi
lip Matthews writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C32B8A.A6394C40
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> See my comments inline.
> 
> - Philip
> 

Third is:

(strict, ingress-address-on-rtr2)
(strict, router-id-of-rtr2)
(strict, ingress-address-on-rtr3)
(strict, router-id-of-rtr3)
(strict, ingress-address-on-rtr4)
(strict, router-id-of-rtr4)

and it interoperates with the other two.

> from the RRO by stripping out sub-objects they did not understand.

The addition of a subobject to RRO object is not as much of an issue
as the RRO being used to create an ERO in route pinning.  It does say
ignored and passed on.  If passed into the ERO, then any router that
didn't understand the new subobject would not be able to proccess the
first entry in the ERO that it needed to look at.

> Perhaps one of the authors of the draft might say why they chose the

Probably because two of the three implementations ignores flags that
it doesn't understand as discovered with soft preempt testing and it
was suggested that ignoring flag bits that are not understood should
be mandated in the next spin of rfc3209.

We should mandate ignoring flag bits that are not understood but that
is a separate issue.

The new type code is still attractive because it doesn't take up
another flag bit.  If there were a way for the ingress to indicate it
understands this, then stripping it when pinning would not be an issue
(if the ingress doesn't understand, don't use the new type code).

It might be worth considering a capabilities advertisement (new TE
TLV) for each router to be flooded into the IGP more for other
features in which the ingress must know capabilities along the path.
For this it would be worth having a capabilities object in the PATH
message for features where ingress capability must be known.  For
other extensions it may be useful to have capabilities subobjects in
both path or resv for features where there is a need to know if each
hop has a given capability.

Curtis