The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

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