Subject: Comments and questions to draft-ayyangar-inter-region-te-00.txt (long message)

From: "JACQUENET Christian FTLD/IAP" <[email-masked]>
Date: Thu, 3 Jul 2003 17:41:00 +0200

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.

---

From: Arthi Ayyangar <[email-masked]>
Date: Mon, 7 Jul 2003 17:47:51 -0700 (PDT)

Hi Christian,

Thanks a lot for your detailed comments. I have tried to address
most of your questions/comments. Please find my replies inline.

> would be composed of multiple regions,
--------> Yes, BGP confederation could be yet another example of a region.
But if all the members of a confed run a single IGP, then it's not
clear why each member would form a region.

> paragraph seems to tell the contrary (and I don't see the restriction in
--------> Do you mean per region or overall ? So, as the inter-region
TE LSP traverses different regions, more that one region along the
path could decide to stitch this TE LSP onto some intra-region LSP segment.
In any case, I will modify the text to clarify this.

> 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]..."
--------> The notion of 'local protection' here is applicable within a
region as well as across regions as explained in Section 6.

> intent is to incorporate the contents of [INTER-AS] into this document?
-------> Not as of now; the solution proposed in [INTER-AS] is different
from the solution proposed here. Section 2 which is the introductory
section does explain the basic difference.

> sub-ASes, etc.
--------> I'll delete the parenthesis.

[clipped..]

> definition, is out of the control of a given ISP.
---------> The idea is that since the FA-LSP and LSP segment are
originated per region, local policies/configurations can control how
and when these get setup. I shall elaborate on the above in the next
revision.

Also, the notion of
> be viewed as transit LSP paths, at least from an intra-region TE policy.
----------> The notion of 'transit' here depends on the originating and
terminating regions. While FA-LSPs and LSP segments start and terminate in
the same region (they are intra-region), LSPs that originate in some other
region and traverse this region are viewed to be 'transit LSPs'. As far as
the inter-region TE policy goes, therefore, the inter-region LSPs would be
treated as 'transit'. Ofcourse, other TE policies, local to the region,
could also be applicable to the intra-region LSPs that transport the
inter-region LSPs.
	I am not quite clear about your last sentence "since both the
latter may *also* be viewed as transit LSP paths, at least from an
intra-region TE policy". Could you elaborate ?

> are concerned, and how (well) this document addresses such requirements.
--------> Will do so in the next revision.

> sentence ("In the absence of...").
--------> Auto-discovery was not intended to be a mandatory mechanism. The
reason it was stressed here was so that the LSP paths (EROs) are specified
correctly.

> negotiate related QoS requirements and (TE) capabilities.
---------> Wouldn't this depend on the nature of the region itself ?
i.e. while the above may be true for an inter-AS LSP setup, especially
when the ASes belong to different SPs, it need not be applicable to an
inter-area LSP setup. Section 8.4 addresses this for inter-AS case.

> operators, from a resource planning and optimisation standpoint.
--------> This is an error in the text. I will correct it.
The dynamic bandwidth adjustment was to be based not on the number of
inter-region TE LSPs, but on the cumulative b/w requested by these
inter-region TE LSPs.

> DSCP marking (if so, I would use this wording)?
---------> The semantics are as defined in RFC 2702. I will add
the appropriate reference there.

> LSP segment the received Path message relates to, since I understand this
------------> One of the reasons it is needed, is because depending on
whether the HE has done stitching or nesting, the egress LSR for the
FA-LSP/LSP segment needs to do correct label allocations (in the Resv
messages sent back upstream). This has been explained in section 5.

> that would convey the traffic transported in inter-region LSP paths.
--------> Absolutely. That is exactly what the first sentence tries to
convey: "FA-LSPs or LSP segments can be pre-configured on any region
boundary LSR".
	The second sentence only says that in case of dynamic FA-LSP or
LSP segment setup (i.e. when they are *not* pre-provisioned), it is the
region boundary LSRs which are at the entry to the region which will
trigger the setup of the intra-region LSPs. So this is just stating who
is the default candidate for dynamic FA-LSP/LSP segment setup. This is
useful so that a region boundary LSR can determine if it needs to trigger
the setup of an intra-region LSP.

>Also,
---------> Yes, the "source" here is the HE LSR for the inter-region LSP.
I will calrify this.

> (somewhat related to one of the previous comments above)?
---------> Then it is assumed that the nexthop in the ERO would specify
the region boundary LSR for that region, so that the previous hop can
expand the loose hop and compute a path to the region boundary LSR.
Section 3 explains this in detail.

> you envision a dynamic "election" mechanism?
---------> By default, it would be the entry region boundary LSR. The
first paragraph in 4.1 defines exactly this.

> make router B establish a FA-LSP rather than a LSP segment (or vice versa).
---------> That is a decision local to the region (based on configuration
on the LSR) whether it wants to do nesting or stitching. If the goal is
say, scalability, then in order to transport several inter-region LSPs
over an intra-region LSP the operator may want to nest all the
inter-region LSPs on a FA-LSP. On the other hand, if the operator would
rather have one intra-region LSP per inter-region LSP, then he may choose
to do stitching with an LSP segment in that region.

> to area 2 (hence the business of C, apart from sending the PathErr message
---------> Please see explanation above.

> Also, I don't see the need of mentioning R0, R1 and R2 for this example.
---------> Okay. I'll remove them if they remain unused.

> especially because flooding path computation information between domains is
----------> It is not expected that path computation information be
flooded between different domains (regions). Here, we are only interested
in obtaining the TE-information associated with the local links originated
by the ASBR in the ASBR's TED. e.g. in the example discussed in 4.3, the
TE information associated with link BC would be added to B's TED.
Secondly, so that path computation in AS1 can take into account the TE
information for links BC, B'C', the ASBRs B and B' would need to advertise
the TE information for BC, B'C' in AS1's IGP.

> at least provide a pointer to these references.
------------> I will add the references to these documents. Also, it was
*not* the mechanism used for propagation of TE information (TE extensions
for OSPF/ISIS) which was to be 'implementation specific'. It was the
mechanism used to determine the node (ASBR) and the links to the node
(ASBR-ASBR links) for which TE information is to be advertised, that was
supposed to be implementation specific.  I will rephrase the document to
clarify this.

> ASBR routers and/or within a given domain, for redistribution purposes for
---------> See explanation above.

> as the volume of the TE information that will be flooded (presumably across
-----------> No TE information is expected to be flooded across domains,
as explained above.

[clipped..]

> would happen is such LSR changed the flag?
-----------> In case a region boundary LSR decides to do LSP stitching
then it would set the above flag for the intra-region LSP segment. The
flag is examined by the egress LSR for the intra-region LSP segment. All
other LSRs in that region are "in-between". This flag is not expected to
be changed because it is used for signaling an attribute for that
intra-region LSP session and indicates the behavior of the HE LSR.

[clipped..]
> segment that are affected by the "old" path which has been torn down.
-----------> The paths for local protection are pre-computed and
pre-established as per [FAST-REROUTE]. So when failure occurs, you would
only need to switch to the backup path causing minimum traffic loss.
This is similar to MPLS Fast-reroute mechanisms which exist today.
Will rephrase.

> What's the influence of having the knowledge of the TE information on the
-------> So that they can be computed instead of being configured
statically.

> does that refer to vendor-specific incremental SPF computations?
-------> No, it does not refer to any vendor-specific incremental SPF
computations. It means expanding the ERO upto the first reachable
boundary LSR in the region (which has either been specified as loose hop
in the ERO or has been determined via auto-discovery mechanism). I will
fix the text to elaborate this.

> Also, the notion of "main" LSP path has not been defined (before section
-------> This is an error in text, I'll fix it.

> Should the re-optimisation parameters be taken into account by the CSPF
--------> Yes.

> requirements document ([INTER-AS]?).
----------> This section is meant to show that the solution proposed
in this draft satisfies requirements for Inter-AS TE as specified in
[INTER-AS-TE-REQTS] in case the region is an AS.

Thanks again for all the comments!

thanks,
-arthi

---

From: "JACQUENET Christian FTLD/IAP" <[email-masked]>
Date: Thu, 10 Jul 2003 11:11:07 +0200

Hi Arthi,

Thanks for your clarifications - a couple of additional comments below.

[snip]

Hi Christian,

CJ: I'm not sure I understand your point. All I meant is that a sub-AS (as
part of a BGP confederation) could be viewed as a region by itself.

[snip]
Also, the notion of

CJ: what I meant is that, since FA and segments are computed to convey
traffics that relate to inter-region LSP paths, both the FA and segment LSPS
can be viewed as transit LSPs within a given domain, whereas they may have
been (pre)-computed as part of the enforcement of an intra-domain TE policy.

[snip]

CJ: I tend to agree with you, but I'm not sure your comment is strictly
relevant since the text refers to *the operator of the transit region*,
which, to me, implictly assumes an inter-AS context: otherwise, I don't see
why an operator of a given *area* should be different from the one who
manages another area...within a given domain.

Cheers,

Christian.