Re: TE Requirements Draft - ELSP

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

Francois,

This WG has embarked on the process of creating a Requirements doc 
prior to blessing any particular technology solutions. In principle,
this is a sound practice.

However, it appears to me, that the authors of this doc as the 
representatives of the collective views would ensure that this
doc is not just a rubber stamping of any existing technology 
proposals or specific vendor capability.

The Requirements doc must reflect input from not only SPs but
the other folks who form an integral part of the IETF standards
process: e.g vendors, academics - of course all acting as individuals.

I would think that the requirements doc would capture "What people
want to do today as well as what they "may" want to do tomorrow" -
where "tomorrow" is not some indefinite time period but a span
of finite time. e.g. 1 year, 2 years, 5 years - take your pick. 
And "may" is backed up with some reasonable example scenarios.

Thus, having a requirements doc that mandates use of DS-TE to 
L-LSPs and a single OA per E-LSP, appears to be highly restrictive.
There ARE folks who ARE interested in sending multiple OAs on a 
single LSP. Why not put this in the requirements draft!!

Then let us see if folks can come up with creative solutions
that address scalability of IGP route advertisements, can
facilitate either single OA per E-LSP or multiple OAs per E-LSP,
will allow L-LSP and do not introduce unnecessary complexity
in the protocols.

Best,
Nabil 



Francois wrote:
> The document we are talking about is a "requirements" document. 
> My understanding of its role is that it is here precisely to draw 
> the boundary between "what seems like a good idea" and "what SPs 
> actually want to do".
> [.....]
> It would seem appropriate to establish that someone is actually 
> likely to need this before adding this new requirement (which, 
> as we all know, entails specific protocol extensions, which have 
> been considered in the past during the making of 
> ietf-mpls-diff-ext and deliberately rejected to
> due lack of clear SP requirements).