[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments and questions to draft-ayyangar-inter-region-te-00.txt (long message)
Dear colleagues,
Having read the aforementioned document, please find herein a list of
comments and questions.
Section 1, page 2:
To me, BGP clusters and confederations could also be examples of an AS which
would be composed of multiple regions,
I assume that there may be several LSP segments that may be inserted into an
inter-region LSP split, correct, although the last sentence of this
paragraph seems to tell the contrary (and I don't see the restriction in
such a case)?
Section 1, page 3: the notion of *local* protection should deserve some
elaboration, unless the notion of "local" is applied to the scale of a
region, as defined previously. If so, I would replace the current wording by
"...requesting protection at the scale of a region (as defined previously)
within the context of [FAST-REROUTE]..."
Section 2, page 3:
I would spend a line or two in this introductory section explaining the
interaction between this document and the [INTER-AS] document: maybe the
intent is to incorporate the contents of [INTER-AS] into this document?
The fact that ASes are mentioned in parenthesis when quoting "different
regions" is somehow confusing, since it introduces a 1:1 relationship
between the two notions, as opposed to the more generic definition stated in
section 1. I would either delete the parenthesis or extend it to areas,
sub-ASes, etc. Furthermore, I think the "other differences between the two
solutions" (end of the first paragraph) could find a natural place in a
specific section that would elaborate on the interaction between the two
documents.
The notion of "complete control" on FA-LSP and LSP segment should deserve
some elaboration as well, especially when the corresponding path computation
MAY be triggered by an incoming inter-region LSP Setup request, which, by
definition, is out of the control of a given ISP. Also, the notion of
"transit LSPs transported across that region" should be defined, including a
comparison with FA-LSP and LSP segments...since both the latter may *also*
be viewed as transit LSP paths, at least from an intra-region TE policy.
Section 3, page 4:
According to the first paragraph, I assume inter-area TE is a usage example
of the solution proposed in this document. I would tehrefore suggest a
reference to Jim's recent contribution as far as inter-area TE requirements
are concerned, and how (well) this document addresses such requirements.
The penultimate sentence of the third paragraph seems to make auto-discovery
mechanism (at least for the dynamic resolution of a next-hop boundary LSR)
somewhat *mandatory* for the completion of an inter-region TE solution, and
I think this should be clarified, especially when reading the previous
sentence ("In the absence of...").
The wording "...depending on the requirement of the operator of the transit
region" in the last paragraph should also deserve some elaboration, since I
suspect the need for (contractual) agreements between (participating)
operators (i.e. operators who would participate in the dynamic enforcement
of an inter-region TE policy), hence the need to exchange and possibly
negotiate related QoS requirements and (TE) capabilities.
Section 3, page 4:
Dynamic bandwidth adjustment by HE LSR routers which computre FA LSP paths
relies upon a specific knowledge which is the number of inter-region LSP
paths that may be carried by the FA LSP: how such a knowledge can be
acquired, since I assume this knowledge refers to predictable requests?
Traffic matrices? Else? I would suggest that this document be more explicit
on this engineering issue, which is one of the primary concerns of
operators, from a resource planning and optimisation standpoint.
What's a "resource affinity"? Does the notion of "color" refer to a specific
DSCP marking (if so, I would use this wording)?
What's the use for an exit point to be able to determine the FA LSP or the
LSP segment thje received Path message relates to, since I understand this
exit point is mostly used to propagate the inter-region LSP path Setup
towards the next hop region?
Section 4.1, page 5:
The second sentence introduces quite an important restriction I don't
understand. I guess operators could engineer FA LSP paths (if not LSP
segments) as specific transit LSP paths, without waiting for an incoming
inter-region LSP path Setup message, i.e. intra-region MPLS TE could also be
used to somehow *dedicate* specific LSPs for the "provisioning" of FA-LSP
that would convey the traffic transported in inter-region LSP paths. Also,
the notion of "source" should be more explicit: I assume you meant the
originating region or HE LSR for the computation of a given inter-region LSP
path, correct?
Section 4.1, page 6:
In the first paragraph, what if there is no auto-discovery mechanism
(somewhat related to one of the previous comments above)?
In the third paragraph, the notion of "FA-LSP/LSP segment candidate" should
deserve some elaboration. What would be the rules for eligibility, and do
you envision a dynamic "election" mechanism?
Section 4.2, page 7:
In the example, I'm not sure I understand the decision criteria which would
make router B establish a FA-LSP rather than a LSP segment (or vice versa).
Section 4.2, page 8:
The notion of "some specific inter-region LSPs" (end of first paragraph)
should be defined.
In the second paragraph, I still don't see the triggering mechanism that
makes B select a FA or a LSP segment in area 0, sicne the problem is related
to area 2 (hence the business of C, apart from sending the PathErr message
to B).
Also, I don't see the need of mentioning R0, R1 and R2 for this example.
Section 4.3, page 9:
Does the notion of "a single hop link (between two ASBR routers" implicitly
refer to the notion of eBGP multihop? If so, please be more specific.
In the case of ASBR-ASBR links and the corresponding TE information, you
mention the possibility of using a CSPF algorithm for path computation,
which seems rather odd from an inter-domain path computation standpoint,
especially because flooding path computation information between domains is
not really recommended.
Also, I somehow disagree with the assmption that states that propagation of
TE-related information between routers of a domain is implementation
specific: my guess is that such routers should support Opaque LSAs (in the
case of OSPF, together with the support of the TE extensions of OSPF as
defined in Katz' draft) and the equivalent in IS-IS, and the document should
at least provide a pointer to these references.
The advertisement of ASBR-ASBR-link-related TE information should be more
precisely defined: do you mean the propagation of such information between
ASBR routers and/or within a given domain, for redistribution purposes for
example?
Section 4.3, page 10:
The first sentence of the paragraph may yield some scalability issue, as far
as the volume of the TE information that will be flooded (presumably across
domains) is concerned.
The last paragraph before section 5 implicitly extends the definition of FA
LSP *beyond* the scope of a region.
Section 5, page 10:
Again the stitching decision criteria should deserve some elaboration, and
there may be an issue as far as the consistency (as well as the chronology)
of the RSVP setup messages related to the FA (or LSP segment) *and* the
inter-region LSP path computation is concerned. Also, the last sentence of
the first paragraph ("This may be desired...") is somewhat confusing as far
as the expectation on the number of LSP requests to be processed towards the
same destination is concerned.
Section 5, page 11:
What are the "in-between" LSRs (under the 0x04 LSP stitching wording)? What
would happen is such LSR changed the flag?
In the example provided, the question of the chronology is raised again.
Also, according to the penultimate sentence of this page, the "memory"
capabilities of C should deserve some elaboration: how control the
appropriate behavior of C?
Scetion 6.1, page 12:
I don't understand why there is no traffic disruption during the repair
period (end of the page), while C is computing a new path for the FA/LSP
segment that are affected by the "old" path which has been torn down.
Section 6.2, page 13:
What's the influence of having the knowledge of the TE information on the
backup path algorithm?
The notion of "partial" CSPF computation should deserve some elaboration -
does that refer to vendor-specific incremental SPF computations?
Also, the notion of "main" LSP path has not been defined (before section
6.3).
Section 7, page 15:
Should the re-optimisation parameters be taken into account by the CSPF
computation?
Section 8: I would put the contents of this section in the appropriate
requirements document ([INTER-AS]?).
Section 8.4, page 17:
Instead of "...there may be other inter-AS agreements...", I would put a
MUST (related to one of the previous comments above).
Section 10, page 17:
IPR issues should be elaborated and the IPR page of the IETF web site should
be updated accordingly.
Cheers,
Christian.
_________________ ________ ______ ______
/_____________ /__ /_ _ / / / / / Christian "I'm a ZZ Fan"
Jacquenet
/_________/ / / / / / / / / /__/ France Telecom Long
Distance ITP/CTO
/ / /___/__/___/_____/_/__/____ "'Been a while since I
made her smile,
/__/ /__________________________/_ And I know she's gonna dig
my style."
/_______________________________/ - Enjoy and get it on.