[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
Inline
> >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)
>
> Done
>
Well, you still talk about RFC2026.
I think the text that we need is something aka:
(doing this from airplane, so not 100% sure):
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Pls check a recent I-D to be sure
There is also new text on IPR and DISCLAIMER and such at the end
of a document
> >
> >2. Section 5.2, page 9. I think the "(i.e. bandwidth)" should be
> > "(e.g. bandwidth)"
>
> Done
>
OK
> >
> >
> >
> >Steve Bellovin:
> >Comment:
> >[2004-09-11] There are some undefined acronyms -- I was
> >puzzled by SRLG, and I think there are more.
>
> Added some acronyms in section 2
>
Thanks. Hope you did them all.
Important also... first time you use an excronym, then
expand it. SOmething aka: Simple Network Management Protocol (SNMP)
and then later it is OK to use juts SNMP.
> >
> >Russ Housley:
> >Comment:
> >[2004-09-14]
> > s/7.15. nter-area/7.15. Inter-area/
> Done
>
OK
> >
> > 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.
>
> Agree, security section has been updated
>
Good.
> >
> >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".
>
> Agree, text has been updated
>
> >
> >> 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?
>
> Updated
>
> >> 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?
>
> Agree, updated
>
> >
> >> 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.
>
> Yes , we agreed on this point.
> Basically advertising TE-links, even cross-area FAs, would
> violate IGP hierarchy concept.
>
Pls check with Alex if this answer is OK
>
> >
> >> 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.
>
> OK, 2119 ditto removed.
>
Pls check WIth Alex if that is OK
> >
> >> 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?
>
> Added definition for TE mesh
>
> >
> >> 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"?
>
> Agree, updated
>
> >
> >> (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
>
> Section 8 has been updated per your comments.
>
>
>
I think this is good.
I have forwarded the answer to ALex to ask him is he is OK with them.
Bert