Subject: RE : RE : 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, 4 Nov 2004 14:12:34 +0100

Hi Bert,

I will post a revision, based on IESG comments, tomorrow evening.
(I will copy the list, as IETF secretariat will not publish before the end of DC meeting)

Regards,

JL

>-----Message d'origine-----
>De : Wijnen, Bert (Bert) [mailto:[email-masked]] 
>Envoyé : jeudi 4 novembre 2004 13:44
>À : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; [email-masked]
>Objet : RE: RE : RE : Last call status 
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Oh well... not sure what ASAP means.
>I admit that I am also not always the fastest to react.
>But... this WG should be able to close down THIS YEAR.
>If things do not get resolved before the end of the year,
>we'll see how we can move them out of my queue.
>
>So... please... give me a realistic and reasonably soon 
>delivery date!??
>
>Bert
>> -----Original Message-----
>> From: LE ROUX Jean-Louis RD-CORE-LAN 
>> [mailto:[email-masked]]
>> Sent: Thursday, October 21, 2004 21:24
>> To: Wijnen, Bert (Bert); Ed Kern; [email-masked]
>> Subject: 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-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
>> >> 
>> >> 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: Fri, 5 Nov 2004 20:51:36 +0100

Bert, all

Please find attached version 03 of the Inter-Area MPLS-TE req ID, that has just been posted.
This version takes into account IESG comments.

See inline for some answers to IESG comments

Regards,

JL

>   per the new guidelines (RFC 3668)

Done

>2. Section 5.2, page 9. I think the "(i.e. bandwidth)" should be

Done

>puzzled by SRLG, and I think there are more.

Added some acronyms in section 2

>Comment:

Done

>  was provided to the place where the already known issues are 

Agree, security section has been updated

>>    requirements is to provide fast recovery mechanisms, allowing to 

>IP FRR in RTGWG. I would change it to say "only on classical 

Agree, text has been updated

>                              +"unreasonably" to match below?

Updated

>>    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 

Agree, updated

>If this is what the WG converged on--fine, but I want to make sure you

Yes , we agreed on this point.
Basically advertising TE-links, even cross-area FAs, would violate IGP hierarchy concept.

>>    related information, that are not taken into account during path 
>>    selection, such as static TE Node information like TE router ids. 
>
>>    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 

OK, 2119 ditto removed.

>>    Because the number of LSRs participating in some TE mesh might be 
>

Added definition for TE mesh

>Don't think 2119 lingo is appropriate here. How about "will be 

Agree, updated

>>    (2) Optimality of the computed backup paths protecting against  

Section 8 has been updated per your comments.