Subject: RE: Expanded ERO draft

From: [email-masked]
Date: Wed, 28 Feb 2001 12:46:10 -0000

Kireeti Kompella [mailto:[email-masked]] 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

---

From: Bora Akyol <[email-masked]>
Date: Wed, 28 Feb 2001 07:35:21 -0800 (PST)

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