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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 14 Oct 2004 23:53:31 +0200

Hi Ed, Bert

The last call on this draft ended three monthes ago...
What is the next step ???

Regards,

JL

>-----Message d'origine-----
>De : Ed Kern [mailto:[email-masked]] 
>Envoyé : vendredi 2 juillet 2004 01:34
>À : [email-masked]
>Cc : Jean Philippe Vasseur; LE ROUX Jean-Louis FTRD/DAC/LAN
>Objet : Last call status 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  
>incorporate comments into a new revision.
>
>And here it is:
>
>http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te- 
>req-02.txt
>
>
>The authors feel they have dealt with all last call comments in this  
>draft.   Please read and comment  by July 12 otherwise we will 
>advance  
>the revision (with AD approval etc etc).
>
>Thanks for your patience around the longer then expected last 
>call and  
>the quick turnaround time on this revision.
>
>Ed
>
>

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 21 Oct 2004 21:23:54 +0200

Hi Bert,

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

Regards,

JL

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