The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <8812A03F65CDD511AE98006008F5E87104DC131D@hermes.hyperchip.com>, 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
> 
> 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.

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.

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

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.

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

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