The MPLS WG Archive

[neil.2.harrison@bt.com]

Bora....I read the draft and did indeed note that backwards compatibility
had been addressed.  However, I raised this issue since it had not come up
in discussion, and if there was a valid reason to object to the proposal
this would be it.  If this is not the case, then I cannot see any strong
reason for *technical* objection.  It therefore seems to me that the matter
should be decided on the basis of whether the EERO solves any
problems/deficiencies of the existing ERO case.  I think that is the key
challenge.

BTW - The issue I raised in the previous mail on fast-prot-sw is still valid
IMO, though we can park that for now since its a different problem.

regards, Neil   

> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: 28 February 2001 15:35
> To: neil.2.harrison@bt.com
> Cc: kireeti@juniper.net; eric.gray@sandburst.com; mpls@UU.NET;
> vkompella@JasmineNetworks.com; yakov@juniper.net
> Subject: RE: Expanded ERO draft
> 
> 
> 
> 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 
> > 
>