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

[Arthi Ayyangar <arthi@juniper.net>]

Hi Christian,

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

> To me, BGP clusters and confederations could also be examples of an AS which
> 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.

> 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)?
--------> 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.

> 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?
-------> 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.

> 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.
--------> I'll delete the parenthesis.

[clipped..]

> 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.
---------> 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
> "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.
----------> 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 ?

> 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.
--------> Will do so in the next revision.

> 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...").
--------> 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.

> 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.
---------> 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.

> 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.
--------> 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.

> What's a "resource affinity"? Does the notion of "color" refer to a specific
> DSCP marking (if so, I would use this wording)?
---------> The semantics are as defined in RFC 2702. I will add
the appropriate reference there.

> What's the use for an exit point to be able to determine the FA LSP or the
> LSP segment the 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?
------------> 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.

> 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.
--------> 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,
> 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?
---------> Yes, the "source" here is the HE LSR for the inter-region LSP.
I will calrify this.


> 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)?
---------> 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.


> 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?
---------> By default, it would be the entry region boundary LSR. The
first paragraph in 4.1 defines exactly this.

> 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).
---------> 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.


> 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).
---------> 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.

> 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.
----------> 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.

> 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.
------------> 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.

> 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?
---------> See explanation above.

> 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.
-----------> No TE information is expected to be flooded across domains,
as explained above.

[clipped..]

> 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 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..]
> 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.
-----------> 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.

> Section 6.2, page 13:
>
> What's the influence of having the knowledge of the TE information on the
> backup path algorithm?
-------> So that they can be computed instead of being configured
statically.

> The notion of "partial" CSPF computation should deserve some elaboration -
> 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
> 6.3).
-------> This is an error in text, I'll fix it.

> Section 7, page 15:
>
> Should the re-optimisation parameters be taken into account by the CSPF
> computation?
--------> Yes.

> Section 8: I would put the contents of this section in the appropriate
> 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