The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00386



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Expanded ERO draft

  • From: neil.2.harrison@bt.com
  • Date: Wed, 28 Feb 2001 12:46:10 -0000
  • Cc: mpls@UU.NET, vkompella@JasmineNetworks.com, yakov@juniper.net

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