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:[email protected]]=20
>Envoy=E9 : jeudi 4 novembre 2004 13:44
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; [email protected]
>Objet : RE: RE : RE : Last call status=20
>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=20
>delivery date!??
>
>Bert
>> -----Original Message-----
>> From: LE ROUX Jean-Louis RD-CORE-LAN=20
>> [mailto:[email protected]]
>> Sent: Thursday, October 21, 2004 21:24
>> To: Wijnen, Bert (Bert); Ed Kern; [email protected]
>> Subject: RE : RE : Last call status=20
>> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>>=20
>>=20
>> Hi Bert,
>>=20
>> Thanks, we are going to revise the document based on IESG
>> comments ASAP.
>>=20
>> Regards,
>>=20
>> JL
>>=20
>> >-----Message d'origine-----
>> >De : Wijnen, Bert (Bert) [mailto:[email protected]]
>> >Envoy=E9 : jeudi 21 octobre 2004 20:57
>> >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Ed Kern; Wijnen, Bert=20
>> >(Bert); [email protected]
>> >Objet : RE: RE : Last call status=20
>> >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=20
>> >so. But then everyone also has access to the IDtracker pages=20
>> >and at least the WG chairs (should) have been notified when=20
>> >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:
>> >-----=20
>> >1. Page 1. Status of this memo.=CA 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/
>> > =20
>> >  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=20
>> >a pointer
>> >  was provided to the place where the already known issues are=20
>> >discussed.
>> >
>> >Alex Zinin:
>> >Comment:
>> >[2004-09-16] > 4.2.3. Fast recovery within an area
>> >> =20
>> >>    As quality sensitive applications are deployed, one of the key=20
>> >>    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=20
>> >IGP rerouting".
>> >
>> >> 5.3.2. Preserve Scalability
>> >> =20
>> >>    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=20
>> >>    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
>> >> =20
>> >>    The solution MUST allow for the signalling of
>> inter-area TE-LSPs,
>> >>    using RSVP-TE.
>> >> =20
>> >>    The proposed solution MUST allow the head-end LSR to=20
>explicitly=20
>> >>    specify a set of LSRs, including ABRs, by means of strict
>> >or loose
>> >>    hops for the inter-area TE LSP.
>> >>     =20
>> >>    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.
>> >> =20
>> >
>> >May it also be necessary to signal other constrains such as BW
>> >or admin groups?
>> >
>> >> 7.4. Inter-Area MPLS-TE Routing
>> >> =20
>> >>    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.=20
>> >>    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=20
>> >to other areas as
>> >topological info. Depending on how tunnel and physical=20
>> >topologies compare, it
>> >may or may not be useful.
>> >
>> >>    Conversely, this does not preclude the leaking of non topology=20
>> >>    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
>> >>     =20
>> >>    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.=20
>> >>    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
>> >>     =20
>> >>    Because the number of LSRs participating in some TE
>> mesh might be
>> >
>> >Where's a "TE mesh" defined?
>> >
>> >> 8. Evaluation criteria
>> >>     =20
>> >> 8.1. Performances
>> >>     =20
>> >>    The solution SHOULD clearly be evaluated with respects to the=20
>> >>    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=20
>against =20
>> >>        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,   =20
>> >>        message size
>> >
>> >Bert
>> >> -----Original Message-----
>> >> From: LE ROUX Jean-Louis RD-CORE-LAN=20
>> >> [mailto:[email protected]]
>> >> Sent: Thursday, October 14, 2004 23:54
>> >> To: Ed Kern; Wijnen, Bert (Bert); [email protected]
>> >> Subject: RE : Last call status=20
>> >> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>> >>=20
>> >>=20
>> >> Hi Ed, Bert
>> >>=20
>> >> The last call on this draft ended three monthes ago...=20
>What is the=20
>> >> next step ???
>> >>=20
>> >> Regards,
>> >>=20
>> >> JL
>> >>=20
>> >> >-----Message d'origine-----
>> >> >De : Ed Kern [mailto:[email protected]]
>> >> >Envoy=E9 : vendredi 2 juillet 2004 01:34
>> >> >=C0 : [email protected]
>> >> >Cc : Jean Philippe Vasseur; LE ROUX Jean-Louis FTRD/DAC/LAN
>> >> >Objet : Last call status=20
>> >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=20
>> >>advance
>> >>the revision (with AD approval etc etc).
>> >>
>> >>Thanks for your patience around the longer then expected last
>> >>call and =20
>> >>the quick turnaround time on this revision.
>> >>
>> >>Ed
>> >>
>> >>
>> >
>>=20
>