[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : RE : RE : Last call status draft-ietf-tewg-interarea-mpls-te-req-01.txt
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:bwijnen@lucent.com]
>Envoyé : jeudi 4 novembre 2004 13:44
>À : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; te-wg@ops.ietf.org
>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:jeanlouis.leroux@francetelecom.com]
>> Sent: Thursday, October 21, 2004 21:24
>> To: Wijnen, Bert (Bert); Ed Kern; te-wg@ops.ietf.org
>> 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:bwijnen@lucent.com]
>> >Envoyé : jeudi 21 octobre 2004 20:57
>> >À : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; Wijnen, Bert
>> >(Bert); te-wg@ops.ietf.org
>> >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:jeanlouis.leroux@francetelecom.com]
>> >> Sent: Thursday, October 14, 2004 23:54
>> >> To: Ed Kern; Wijnen, Bert (Bert); te-wg@ops.ietf.org
>> >> 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:ejk@tech.org]
>> >> >Envoyé : vendredi 2 juillet 2004 01:34
>> >> >À : te-wg@ops.ietf.org
>> >> >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
>> >>
>> >>
>> >
>>
>