Subject: RE: TE Requirements Draft - ELSP

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Nov 2001 07:20:28 -0500

I think this captures my concern very nicely.
Most everything is "a slight addition ...".
In producing engineering products, avoiding the big unnecessary features is 
easy.  It is avoiding being nibbled to death by ducks (tiny incremental 
features) that is hard.  In defining standards this is actually an even 
larger problem because it is so easy to define just another little feature.
Yes, we have mechanisms to remove them later.  But it is better not to put 
in the features in the first place.
So, what I am asking for is not "what does this feature do?"  I understand 
what it does.  What I still don't understand is what problem it 
solves.  Label utlization?  Recovery time?  (Bias:  I happen to think that 
those two goals are not worth the added complexity.  But that would be up 
to the WG, not me.)

Yours,
Joel M. Halpern

At 11:09 AM 11/21/01 +0100, Roberto Mameli (ERI) wrote:
>So, only a slight addition to the protocol, with minor impact and 
>preserving backward compatibility. Why not?

---

From: Nabil Seddigh <[email-masked]>
Date: Wed, 21 Nov 2001 14:50:14 -0500

Joel,

You may not think that reduced scalability issues associated with 
the number of LSPs or robust protection/restoration mechanisms are 
key benefits. However, in many of the emerging L2VPN deployment 
scenarios, both items are key features! Sending multiple OAs on 
an E-LSP makes the L2VPN story more viable.

Of course, others on this list have stated many other reasons
why they desire full E-LSP support in the DS-TE solution.

Kind Regards,
Nabil

> What I still don't understand is what problem it
> solves.  Label utlization?  Recovery time?  (Bias:  I happen to 
> think that those two goals are not worth the added complexity.  
> But that would be up to the WG, not me.)
> 
> Yours,
> Joel M. Halpern
>