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

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 05 Jun 2003 14:51:26 -0400

Hi Philipp,

At 09:48 AM 6/4/2003 -0400, Philip Matthews wrote:

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

if you define a new type code, you would need to add the new subobject in 
addition to the existing IPv4 subobject in order to be compliant with the 
FRR draft. Defining a new flag allows to use the same required IPv4 but 
just set the flag and use the router-id address instead of the outgoing 
interface.

thanks

JP.

>- Philip

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 05 Jun 2003 17:40:57 -0400

Hi Philip,

At 05:22 PM 6/5/2003 -0400, Philip Matthews wrote:

>Jean Philippe Vasseur wrote:
> > if you define a new type code, you would need to add the new subobject 
> in addition to the existing
> > IPv4 subobject in order to be compliant with the FRR draft. Defining a 
> new flag allows to use the
> > same required IPv4 but just set the flag and use the router-id address 
> instead of the outgoing
> > interface.
>
>I think I understand now:
>a) You want each node to independently decide whether to push an interface 
>address,
>    a router id, or both.

That's exactly right. Actually, pushing an router id is the only thing that 
FRR requires. In addition, an additional IPv4 sub-object can be added to 
record the interface.

>b) I would like each node to always push an interface address, and 
>optionally push a router id.

The problem is that you may need to add a router id for each fast 
reroutable LSP since it can potentially be an inter-area or inter-AS TE LSP 
and trying to determine whether a TE LSP is inter-area/AS may not be so 
obvious. Hence, this simple solution of pushing the router-id and setting 
up the flag. Routers that do not understand the flag will just ignore it 
and the RRO will be shorter with this option.

>With option (a), there may be some advantage in using a flag, since 
>routers out
>there today that do not understand the flag will see just an IPv4/v6 
>Address subobject
>and will hopefully do more-or-less the right thing. However, as Curtis 
>points out,
>there are routers out there that are known to have problems with new flags.
>
>With option (b), there is no advantage to using a flag, assuming nodes can 
>ignore
>unknown sub-objects.

but the RRO length will be unnecessarily increased.

>My concern with option (a) is that it removes my ability to parse the RRO and
>tell which sub-objects belong to the same node. For example, if the RRO 
>contains:
>
>      (address-1, flag=0), (address-2, flag=1), (address-3, flag=0)
>
>then I don't know whether this represents 2 nodes or 3 nodes. This makes it
>impossible for a router to display the RRO to the operator in a nicely 
>formatted
>manner (that groups together the information for a single node).

Well no I do not agree here ... this is even worse without the flag since 
currently an implementation can perfectly add more than one IPv4 subobject 
in every RRO object. So you can have the following: (address-1, flag=0), 
(address-2, flag=0), (address-3, flag=0). Then you can still use the TE 
database to determine that they all belong to the same node.

>Option (a) also gives the operator less information, because he/she will 
>not always
>see the egress interface of the LSP.

The outgoing address can also be added

>However, option (a) does have the advantage that RROs can be shorter.
>
>So there seem to be three questions for the WG to decide:
>1) Do we want to do for option (a) or option (b)?

JP.

>2) Do we want to use a flag or a new sub-object?
>3) Do we need to add capability advertisements to do any of this
>    (as Curtis is suggesting)?
>
>I personally have a medium preference for option (b), and a medium preference
>for a new sub-object. I also hope that people will simply fix their routers
>so we don't need to introduce capability advertisements.
>
>- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Jun 2003 17:22:09 -0400

> if you define a new type code, you would need to add the new subobject in
addition to the existing
> IPv4 subobject in order to be compliant with the FRR draft. Defining a new
flag allows to use the
instead of the outgoing

With option (a), there may be some advantage in using a flag, since routers
out
there today that do not understand the flag will see just an IPv4/v6 Address
subobject
and will hopefully do more-or-less the right thing. However, as Curtis
points out,
there are routers out there that are known to have problems with new flags.

My concern with option (a) is that it removes my ability to parse the RRO
and
tell which sub-objects belong to the same node. For example, if the RRO
contains:

Option (a) also gives the operator less information, because he/she will not
always
see the egress interface of the LSP.

I personally have a medium preference for option (b), and a medium
preference
for a new sub-object. I also hope that people will simply fix their routers
so we don't need to introduce capability advertisements.

- Philip