RE: RE : Last call status draft-ietf-tewg-interarea-mpls-te-req-0 1.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=20
Harald Alvestrand:
Comment:
[2004-09-16] Reviewed by Mary Barnes, Gen-ART

Nits:=20
-----=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]=20
  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 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
> =20
>    As quality sensitive applications are deployed, one of the key=20
>    requirements is to provide fast recovery mechanisms, allowing to=20
>    guarantee traffic recovery on the order of tens of msecs, in case =
of=20
>    network element failure. Note that this cannot be achieved by =
relying=20
>    only on IGP rerouting. =20

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
> =20
>    Being able to achieve the requirements listed in this document =
MUST=20
>    be performed while preserving the IGP scalability, which is of the =

>    utmost importance. The hierarchy preservation objective addressed =
in=20
>    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=20
>    amount of extra information and MUST not unreasonably increase the =

>    IGP flooding frequency.=20


> 7.2. Inter-Area TE-LSP signalling
> =20
>    The solution MUST allow for the signalling of inter-area TE-LSPs,=20
>    using RSVP-TE.=20
> =20
>    The proposed solution MUST allow the head-end LSR to explicitly=20
>    specify a set of LSRs, including ABRs, by means of strict or loose =

>    hops for the inter-area TE LSP. =20
>     =20
>    In addition, the proposed solution SHOULD also provide the ability =
to =20
>    specify and signal certain resources to be explicitly excluded in =
the=20
>    inter-area TE LSP path establishment. =20
> =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=20
>    are required to compute an optimal path. These additional =
mechanisms=20
>    MUST not alter the IGP hierarchy principles.=20
>    Particularly, in order to maintain containment of routing =
information=20
>    and preserve the overall IGP scalability, the solution MUST =
preclude=20
>    the leaking across area of any TE Topology related  information =
even=20
>    in a summarized form.=20

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

> 7.8. Intra/Inter-area Path selection policy
>     =20
>    For inter-area TE LSPs whose head-end and tail-end LSRs reside in =
the=20
>    same IGP area, there may be intra-area and inter-area feasible =
paths.=20
>    In case the shortest path is an inter-area path, an operator may=20
>    either want to avoid, as far as possible, crossing area and thus=20
>    prefer selecting a sub-optimal intra-area path, or conversely may=20
>    prefer to use a shortest path, even if it crosses areas.=20
>    Thus, the solution MUST allow to enable/disable IGP area crossing, =
on=20
>    a per-LSP basis, for TE LSPs whose head-end and tail-end reside in =

>    the same IGP area. =20

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

Where's a "TE mesh" defined?

> 8. Evaluation criteria
>     =20
> 8.1. Performances =20
>     =20
>    The solution SHOULD clearly be evaluated with respects to the=20
>    following criteria: =20

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 =20
>        the failure of an ABR, capability to share bandwidth among =
backup =20
>        tunnels protecting independent facilities.

ditto

>    (3) Inter-area TE LSP set up time.=20

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
> [mailto:[email protected]]
> Sent: Thursday, October 14, 2004 23:54
> To: Ed Kern; Wijnen, Bert (Bert); [email protected]
> Subject: RE : Last call status
> 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...
> What is the next step ???
>=20
> Regards,
>=20
> JL
>=20
> >-----Message d'origine-----
> >De : Ed Kern [mailto:[email protected]]=20
> >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 =
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 =20
> >incorporate comments into a new revision.
> >
> >And here it is:
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea
-mpls-te-=20
>req-02.txt
>
>
>The authors feel they have dealt with all last call comments in this =20
>draft.   Please read and comment  by July 12 otherwise we will=20
>advance =20
>the revision (with AD approval etc etc).
>
>Thanks for your patience around the longer then expected last=20
>call and =20
>the quick turnaround time on this revision.
>
>Ed
>
>