[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>>
>>
>