The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Neil

Just to follow up on your email:

1) There are no backwards compatibility issues by using the EERO. We
devoted a section of the draft to this matter. The main reason for
defining a new object was to avoid backwards compatibility issues.

2) The main motivation for this draft is to make ERO processing simpler
and to make parsing of an ERO quick and "obvious"

I think just the clarity of the EERO sub-objects is worth thinking more
seriously about this draft.

Bora

On Wed, 28 Feb 2001 neil.2.harrison@bt.com wrote:

> Kireeti Kompella [mailto:kireeti@juniper.net] asked on 27 February 2001
> 22:24
> > Who all think that adding a router ID to the unnumbered ERO subobject
> > would be beneficial?  A simple yes, no or don't care, please.
> 
> I don't think a simple Y/N/DC vote is good enough....the vote has to be
> supported by rationale.
> 
> Having carefully followed the discussion I come to the conclusion that (i)
> there appear to be some advantages to doing what Bora et al are advocating,
> and (ii) there are no technical disadvantages (or at least none have been
> stated that I can see....other than a clear reluctance from a few parties to
> accept a change, which is fair enough if there are serious backwards
> compatibility issues).
> 
> Having said that.....
> I think the biggest advantage is *clarity* of nodal identifier and
> interface.  I am reluctant to buy too hard into the fast-reroute arguments
> since:
> -	it will not cater for all possible failure modes (but only, I assume
> , below MPLS-layer failures, eg SDH)
> -	since an intermediate LSR in a LSP is *not* a trail termination
> point there are some defect handling issues that are not being considered,
> eg there should be a FDI from the failed LSP segment which gets merged with
> the 'new' (rerouted) LSP segment.....and since the CV flow will split (at
> point where new reroute starts) to take the new rerouted segment then
> (ideally) the FDI should be suppressed from the failed segment at the
> downstream merge point.
> 
> The above can be circumvented by always establishing a completely new
> server-layer LSP between the nodes where one wants to establish a
> prot-route....and this would have its own CV flow, disjoint from the
> (protected) segment of the client LSP.
> 
> So, in conclusion:
> -	do it for clarity *and* if true technical benefits result
> -	don't do it if any backwards compatibility is evident and there are
> no strong benefits....so are any backwards compatibility problems?
> -	don't do it for fast-rereoute reasons since (IMO) such a device
> appears to be architecturally flawed.
> 
> neil 
>