RE : RE : Last call status draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi Bert,

Thanks, we are going to revise the document based on IESG comments ASAP.

Regards,

JL

>-----Message d'origine-----
>De : Wijnen, Bert (Bert) [mailto:[email protected]]=20
>Envoy=E9 : jeudi 21 octobre 2004 20:57
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; Wijnen, Bert=20
>(Bert); [email protected]
>Objet : RE: RE : Last call status=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Well, we're actually at revision 2.
>Yet, the document is in ID-tracker state:
>  New revision needed.
>
>The comments that we (IESG) like to see responses to are
>as follows (Did these not get forwarded to the=20
>authors/chairs/WG quite a while ago? Appology if I did not do=20
>so. But then everyone also has access to the IDtracker pages=20
>and at least the WG chairs (should) have been notified when=20
>the doc state changes.
>
>Anyway, here are the comments that you may want to address/answer:
>
>Discusses and Comments=20
>Harald Alvestrand:
>Comment:
>[2004-09-16] Reviewed by Mary Barnes, Gen-ART
>
>Nits:=20
>-----=20
>1. Page 1. Status of this memo.=CA Needs updating to the new template,
>   per the new guidelines (RFC 3668)
>
>2. Section 5.2, page 9. I think the "(i.e. bandwidth)" should be
>   "(e.g. bandwidth)"
>
>
>
>Steve Bellovin:
>Comment:
>[2004-09-11] There are some undefined acronyms -- I was=20
>puzzled by SRLG, and I think there are more.
>
>Russ Housley:
>Comment:
>[2004-09-14]=20
>  s/7.15. nter-area/7.15. Inter-area/
> =20
>  Section 9 says: "Inter-area MPLS-TE does not raise any new=20
>security issue,
>  beyond those of intra-area MPLS-TE."  It would be helpful is=20
>a pointer
>  was provided to the place where the already known issues are=20
>discussed.
>
>Alex Zinin:
>Comment:
>[2004-09-16] > 4.2.3. Fast recovery within an area
>> =20
>>    As quality sensitive applications are deployed, one of the key=20
>>    requirements is to provide fast recovery mechanisms, allowing to=20
>>    guarantee traffic recovery on the order of tens of msecs,=20
>in case of=20
>>    network element failure. Note that this cannot be=20
>achieved by relying=20
>>    only on IGP rerouting.
>
>The last statement is not entirely correct. We are working on=20
>IP FRR in RTGWG. I would change it to say "only on classical=20
>IGP rerouting".
>
>> 5.3.2. Preserve Scalability
>> =20
>>    Being able to achieve the requirements listed in this=20
>document MUST=20
>>    be performed while preserving the IGP scalability, which=20
>is of the=20
>>    utmost importance. The hierarchy preservation objective=20
>addressed in=20
>>    the above section is actually an element to preserve IGP=20
>scalability.
>>    The solution MUST also not increase IGP load which could=20
>compromise
>                              ^
>                              +"unreasonably" to match below?
>>    IGP scalability. In particular, a solution satisfying those=20
>>    requirements MUST not require for the IGP to carry some=20
>unreasonable=20
>>    amount of extra information and MUST not unreasonably=20
>increase the=20
>>    IGP flooding frequency.
>
>
>> 7.2. Inter-Area TE-LSP signalling
>> =20
>>    The solution MUST allow for the signalling of inter-area TE-LSPs,=20
>>    using RSVP-TE.=20
>> =20
>>    The proposed solution MUST allow the head-end LSR to explicitly=20
>>    specify a set of LSRs, including ABRs, by means of strict=20
>or loose=20
>>    hops for the inter-area TE LSP. =20
>>     =20
>>    In addition, the proposed solution SHOULD also provide=20
>the ability to =20
>>    specify and signal certain resources to be explicitly=20
>excluded in the=20
>>    inter-area TE LSP path establishment. =20
>> =20
>
>May it also be necessary to signal other constrains such as BW=20
>or admin groups?
>
>> 7.4. Inter-Area MPLS-TE Routing
>> =20
>>    As already mentioned in 5.1, IGP hierarchy does not allow=20
>the Head-
>>    End LSR computing an end-to-end optimal path. Additional=20
>mechanisms=20
>>    are required to compute an optimal path. These additional=20
>mechanisms=20
>>    MUST not alter the IGP hierarchy principles.=20
>>    Particularly, in order to maintain containment of routing=20
>information=20
>>    and preserve the overall IGP scalability, the solution=20
>MUST preclude=20
>>    the leaking across area of any TE Topology related =20
>information even=20
>>    in a summarized form.=20
>
>If this is what the WG converged on--fine, but I want to make sure you
>understand that this precludes at least one form of a=20
>hierarchical approach
>where cross-area TE tunnels are pre-engineered and announced=20
>to other areas as
>topological info. Depending on how tunnel and physical=20
>topologies compare, it
>may or may not be useful.
>
>>    Conversely, this does not preclude the leaking of non topology=20
>>    related information, that are not taken into account during path=20
>>    selection, such as static TE Node information like TE router ids.=20
>
>> 7.8. Intra/Inter-area Path selection policy
>>     =20
>>    For inter-area TE LSPs whose head-end and tail-end LSRs=20
>reside in the=20
>>    same IGP area, there may be intra-area and inter-area=20
>feasible paths.=20
>>    In case the shortest path is an inter-area path, an operator may=20
>>    either want to avoid, as far as possible, crossing area and thus=20
>>    prefer selecting a sub-optimal intra-area path, or conversely may=20
>>    prefer to use a shortest path, even if it crosses areas.=20
>>    Thus, the solution MUST allow to enable/disable IGP area=20
>crossing, on=20
>>    a per-LSP basis, for TE LSPs whose head-end and tail-end=20
>reside in=20
>>    the same IGP area. =20
>
>Observation: note that the above is rather an implementation=20
>req, rather
>than one for the solution.
>
>> 7.14. Auto-discovery of TE meshes
>>     =20
>>    Because the number of LSRs participating in some TE mesh might be=20
>
>Where's a "TE mesh" defined?
>
>> 8. Evaluation criteria
>>     =20
>> 8.1. Performances =20
>>     =20
>>    The solution SHOULD clearly be evaluated with respects to the=20
>>    following criteria: =20
>
>Don't think 2119 lingo is appropriate here. How about "will be=20
>evaluated"?
>
>>    (1) Optimality of the computed inter-area TE LSP paths.
>
>In what terms?
>
>>    (2) Optimality of the computed backup paths protecting against =20
>>        the failure of an ABR, capability to share bandwidth=20
>among backup =20
>>        tunnels protecting independent facilities.
>
>ditto
>
>>    (3) Inter-area TE LSP set up time.=20
>
>expressed how?
>
>>    (4) RSVP-TE and IGP scalability (state impact, number of=20
>messages,   =20
>>        message size
>
>Bert
>> -----Original Message-----
>> From: LE ROUX Jean-Louis RD-CORE-LAN
>> [mailto:[email protected]]
>> Sent: Thursday, October 14, 2004 23:54
>> To: Ed Kern; Wijnen, Bert (Bert); [email protected]
>> Subject: RE : Last call status
>> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>>=20
>>=20
>> Hi Ed, Bert
>>=20
>> The last call on this draft ended three monthes ago...
>> What is the next step ???
>>=20
>> Regards,
>>=20
>> JL
>>=20
>> >-----Message d'origine-----
>> >De : Ed Kern [mailto:[email protected]]=20
>> >Envoy=E9 : vendredi 2 juillet 2004 01:34
>> >=C0 : [email protected]
>> >Cc : Jean Philippe Vasseur; LE ROUX Jean-Louis FTRD/DAC/LAN
>> >Objet : Last call status=20
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>> >
>> >
>> >
>> >Hi folks,
>> >
>> >We delayed last call closure for a bit to give the authors time to =20
>> >incorporate comments into a new revision.
>> >
>> >And here it is:
>> >
>> >http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea
>-mpls-te-=20
>>req-02.txt
>>
>>
>>The authors feel they have dealt with all last call comments in this =20
>>draft.   Please read and comment  by July 12 otherwise we will=20
>>advance =20
>>the revision (with AD approval etc etc).
>>
>>Thanks for your patience around the longer then expected last=20
>>call and =20
>>the quick turnaround time on this revision.
>>
>>Ed
>>
>>
>