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