[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re : MPLS Inter-area TE requirement draft
Hi Jim,
Please find answer to your comments in the text.
(Apologize for this late answer)
> -----Message d'origine-----
> De : Jim Boyle [mailto:jboyle@pdnets.com]
> Envoyé : mercredi 31 décembre 2003 03:30
> À : Jean Philippe Vasseur
> Cc : te-wg@ops.ietf.org; ejk@tech.org; Jim Boyle;
> bwijnen@lucent.com; LE ROUX Jean-Louis FTRD/DAC/LAN;
> Raymond_Zhang@infonet.com; Kenji Kumaki; Yuichi Ikejiri;
> Parantap Lahiri; ting_wo.chung@bell.ca
> Objet : Re: MPLS Inter-area TE requirement draft
>
>
>
>
> Jean Philippe and Jean Louis,
>
> I have read the draft of you and your 6 co-authors, I am
> happy that you now also agree that inter-area is important to
> consider (especially if inter-as is!). With 7 authors,
> including 2 editors, I am a bit amused that your references
> section seems out of sorts, you or your co-editor may want to
> cross-check them. You may also want to take a look at the
> RFC editor's policy on Author overload:
>
http://www.rfc-editor.org/policy.html#policy.authlist
Thanks, you are right, a contributor section will be added in next version.
>But some of the non-referenced references do actually hint at some of
>my concerns with
>the work that may lead out of inter-area and inter-as requirements. As examples
>[BANDWIDTH-PROTECTION], [PATH-COMP], [OSPF-TE-CAP], [LOOSE-PATH-REOPT], [NODE-ID] and
>[INTER-AS-TE-LINK]. Specifically, I worry about loosely bounded extensions, some of which >may seriously limit practical scalability of use (or ease of operation/understanding).
This list just gives potential solution building blocks as illustration. We do not want to restrict the solution field.
But actually this is a good point, and we will remove any solution related reference in next version.
>I would like to work to bring our drafts together, however first I
>think there is a
>crucial difference between them, something perhaps that some list comment may shed light >on.
Actually, these differences motivated us to write a separate draft. Basically your draft appears too solution dependant, which is not really the goal of a reqs ID, isn't it ?
It seems that you recommand only crankback routing approach, precluding any other approach.
If we refer to section 3.1 "In overview, the requirements below call for what may be called a
crankback method which employs head end direction for regional
optimization"
In return our draft do not assume any solution, it just lists a set of functional requirements.
Crankback is a possible solution, that do not allow to find the optimal path, and that may face path setup time issues. PCS is another solution that is quite scalable and allows to find a constrained shortest path in a recursive manner thanks to light message exchange between ABRs.
Our draft do not recommend any particular solution and do not preclude any solution provided that it meets functional requirements that are mandatory (MUST).
>In mine, edge to edge optimality yields to scalability. Solutions that
>come to mind
>include standard crankback approaches. LSPs are likely to be greedy within each region.
>In yours, it appears that scalability yields to optimality, or as another level of
>complexity, this is one possible mode.
Definitely no.
What we want to point out is that solutions allowing to compute an optimal path may require more job on LSRs, but without necessarily impacting network scalability.
> Your path computation servers would seem one
>approach here, as these "straddle" and can bridge at least two areas,
>however this would
>seem to involve a round of coordination with the head end, and once an LSP goes across
>the second area into a third (Such as an edge to edge LSP would likely do), there is
>again a limited visibility that must be dealt with.
Basically PCS approach allows, IMHO, to find an e2e optimal path. This path is computed in a polynomial time, thanks to recursive computation on ABRs. Actually it requires only a light coordination between Head-End LSR, Head-End ABR and Tail-End ABR.
But all in all there is definitely no text on PCS in our draft! (except in the reference, we will remove it), so I don't really catch the issue here.
-----------------------------------------------------
Hope this clarify possible misunderstanding
All in all, your draft also contains highly relevant points, (particularly a good analysis of current MPLS-TE uses
in section 1, that eases understanding of requirements in following sections),
and it appears, from a more recent mail you sent, that we are in strong aggreement
Thus, I think that it is now time to merge our proposals.
Best Regards,
JL