Subject: Re: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 28 Jul 2005 12:18:49 -0700 (PDT)

Hi Adrian,

Thanks for your exhaustive review and comments.
Looks like I missed this mail. Sorry about that.

Please see inline for my replies to some questions/issues raised. For
formatting issues, I will turn to JP so that we can address them in the
next rev. Thanks!

> I have not caught all of the typos, I am sure. Also worried that the
> number of changes needed may have obscured some technical issues, so we
> will have to go around this at least once more.
AA-----> Fair enough.

> ## The next paragraph is a bit unclear. Why not it with...
> ## Per-domain computation applies where the full route to an
> ## inter-domain LSP cannot be or is not determined at the ingress
> ## point of the LSP, and is not signaled across domain boundaries.
> ## This is most likely to arrise owing to TE visibilty limitations.
> ## The signaling message indicates the destination and nodes up to
> ## the next domain boundary. It may also indicate further domain
> ## boundaries or domain identifiers. The route through each domain,
> ## possibly including the choice of exit point from the domain,
> ## must be determined within the domain.
AA-------> Sounds better to me.

> The principle of per-domain path computation specified in this document
> comprises of a GMPLS or MPLS node along an inter-domain LSP path,
> computing a path up to the last reachable hop within its domain. It
> covers cases where this last hop (domain exit point) may already be
> specified in the signaling message as well the case where this last hop
> may need to be determined by the GMPLS node.
>

> ABR Routers: routers used to connect two IGP areas (areas in OSPF or
> L1/L2 in IS-IS)
> ##replace "L1/L2" with "levels"
AA----> Yep.

> ## Missing ASBR. Just point to Interconnect routers
AA----> Okay.

> Boundary LSR: a boundary LSR is either an ABR in the context of inter-
> area MPLS TE or an ASBR in the context of inter-AS MPLS TE.
>
> Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
> over a common facility.
>
> CSPF: Constraint-based Shortest Path First.
> ## I searched for the uses of this acronym and I thought all of them
> ## should be less specific (that is allowing any path computation
> ## technique). In which case, you will not need this in the terminology
> ## section.
AA---> That is true.

<snipped>
>
> ## The next paragpraph is true but irrelevant to this I-D.
AA---> Agree.
> There are different ways in which inter-domain TE LSP path computation
> may be performed. For example, if the requirement is to get an end-to-
> end constraint-based shortest path across multiple domains, then a
> mechanism using one or more distributed PCEs could be used to compute
> the shortest path across different domains. Alternatively, one could
> also use some static or discovery mechanisms to determine the next
> boundary LSR per domain as the inter-domain TE LSP is being signaled.
> Other offline mechanisms for path computation are not precluded either.
> Depending on the Service ProviderÆs requirements, one may adopt either
> of these techniques for inter-domain path computation.
>
<snipped>

> ## Why do you mention CSPF? The path computation algorithm in use is
> ## surely not relevant to this I-D.
AA----> Agree.

> Note that PCE-based path computation may be mentioned in this document
> for the sake of reference but such techniques are outside the scope of
> this document.
> ## Then don't mention them.
AA----> :-)

> ## Do you need to say that you also support the case where area2 is
> ## not a spearate area, but is part of area 1?
> ##
> ## Do you support routing across (i.e. into and out of) an area
> ## that is not area zero?
AA----> Don't see why not.

> - The various ASBRs are BGP peers, without any IGP running on the
> single hop links interconnecting the ASBRs and also referred to as
> inter-ASBR links,
> ## Whoah! I hope you will explain why you *need* to run BGP, and
> ## how you will manage non-TE distribution of reachability
> ## information when the destination of a TE-LSP is a TE address.
> ## Will you perhaps be mandating (stronger than recommending) that
> ## the destination of an inter-AS TE LSP is the TE Router ID of
> ## the egress in order to be sure that this address is one of the
> ## reachable addresses advertised by BGP?
AA--------> See below.

> hop at least has IP reachability (via IGP or BGP). If the next-hop is
> not reachable, then the path computation stops and the LSR sends back a
> PathErr upstream. If the next-hop is reachable, then it finds an
> ABR/ASBR to get to the next-hop. In the absence of an auto-discovery
> mechanism, the ABR in the case of inter-area TE or the ASBR in the
> next-hop AS in the case of inter-AS TE should be the loose next-hop in
> the ERO and hence should be accessible via the TED, otherwise the path
> computation for the inter-domain TE LSP will fail.
> ## I would like you to make it VERY clear what you are doing here.
> ## You are using the Routing Database to make TE routing decisions.
> ## This may (or may not) be OK in people's minds
> ## I will send separate mail to the CCAMP list because this is a BIG
> ## DEAL in GMPLS networks.
AA---> I noticed the mail that you sent out. Thanks! However, there have
been no replies yet. But I think this ID does state that that if the next
hop is not in the TED and does not have IP reachability, then such a
computation would fail. Should we raise this point again either at the
WG meeting or when we post the next rev ?

> ## In any case, can you please clarify that this process MUST NOT be
> ## used when the next-hop is within the same domain but does not
> ## appear in the TED, or does not have TE connectivity available.
AA-------> Okay, this will be clarified.

<snipped>
>              or LSP segment(s) already exist, then it SHOULD try to
>              select from among those intra-area/AS LSPs. Depending
>              on local policy, it MAY signal a new FA-LSP/LSP segment
>              if this selection fails. If the FA-LSP/LSP segment is
>              successfully signaled or selected, it propagates the
>              inter-domain Path message to the next-hop following the
>              procedures described in [LSP-HIER]. If, for some reason
>              the dynamic FA-LSP/LSP segment setup to the next-hop
>              boundary LSR fails, the path computation stops and a
> ## Is it the path computation that stops?
> ## Is there no scope for retires or fall-back to ordinary routing?
AA-------> This is the case which JL mentioned as well in his email.
There could be multiple exit points and if one fails, then another could
be tried based on routing information and local policies. So I agree that
a retry is possible and  if all attempts fail then an error is propagated.

<snipped>
> 4.1.   Example with an inter-area TE LSP
>
> 4.1.1.  Case 1: T1 is a contiguous TE LSP
>
> ## I think your example should start at the ingress! It seems you
> ## cut back to that after the first paragraph.
AA---> Okay.

> ## What does the user supply? What does the ingress compute?
> ## How is ABR1 selected? (I like ABR2: it is a nicer color. Why
> ## can't I have ABR2?)
> ## There is also some repeated text in this section.
> ## Also, why are you considering Example 1 since it is out of scope
> ## for you?
AA--------> Not clear to me what is out of scope and why ?

> ## Presumably, Example 3 only applies if areas 1 and 2 are actually
> ## part of the same area, so you should say so.
>
> When the path message reaches ABR1, it first determines the egress LSR
> from its area 0 along the LSP path (say ABRÆ1), either directly from
> the ERO (if for example the next hop ABR is specified as a loose hop in
> the ERO) or by using some constraint-aware auto-discovery mechanism. In
> ## Wow! "A constraint-aware auto-discovery mechanism." I borrowed
> ## one of those from Batman once, but I could never get it to work.
AA---------> :-)

> ## What are you talking about?
> ## Yes, I see this in section 3, 1) and in section 4, 1) but it does
> ## not explain what you are suggesting may exist. I must say it sounds
> ## suspisciously like TE aggregation advertisement using BGP.
AA-------> I don't think "constraint-aware" stuff is relevant to this
document and I am okay with getting rid of it. We need discovery of exit
points...but that's about it.

<snipped>
>
> ## Can you explain why the TE information pertaining to the inter-AS
> ## links *needs* to be flooded within the ASs?
AA-----> Hmm...I don't think we say that TE information for inter_AS links
*needs* to be flooded. See below for answer to why ?

It is surely enough that
> ## the ASBRs have access to the TE information about their own TE links.
AA----> Yes they do, but the previous hop LSR in this AS that picked
this ASBR as the exit point doesn't have that information. So, if the LSR
selecting this ASBR had that information (and used it in path
computation), then if the ASBR-ASBR link was a bottleneck, then it could
have chosen another exit ASBR instead.

> ## After all, you have defined that the ASBRs in the *next* AS can do
> ## hop resolution and crankback. Why should the ASBRs in *this* AS also
> ## not perform that operation if necessary?
AA---> Sure it can.

> ## You are reducing the chance of call setup failure at the expense of
> ## increasing the scope of the TE information flooded. But we know
> ## how that works!
AA-----> How many ASBR-ASBR links are we talking about ?

<snipped>
> 4.2.2.  Case 2: T1 is a stitched or nested TE LSP
>
> The signaling procedures are very similar to the inter-area LSP setup
> case described earlier. In this case, the FA-LSPs or LSP segments will
> only be originated by the ASBRs at the entry to the AS.
> ## This is a really important point that you should bring out a bit!
> ## An FA cannot exist out of the IGP instance that contains its
> ## component TE links.
> ## What about non-FAs? Could I operate a stitched segment for just the
> ## link between ASBRs? I think so. Indeed, I might want to.
> ## Could I run a hierarchical LSP for just the link between ASBRs? Yes
> ## although I am not convinced it adds value, but maybe there is some
> ## administrative benefit when crossing a trust boundary (for example,
> ## all I have to do is count the packets with one label).
AA-------> Is your point that FA-LSPs and LSP segments can originate and
terminate on any a) boundary node or b) any other node that has local
configuration/policy to do so (for originating) ? If yes, then I agree. I
think this ID needs to be fixed to explicitly state that.

<snipped>
>
> 6.     MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs
> ## The following section is valuable in the context of the popularity
> ## of RFC 4090, but you cannot produce this I-D in CCAMP without also
> ## discussing the use of Segment Protection to achieve the same
> ## function in the data plane.
AA-------> Agree.

<snipped>
> 7.1.   Contiguous TE LSPs
>
> ## Need to generalize this section for areas, etc.
>
> After an inter-AS TE LSP has been set up, a more optimal route might
> appear in the various traversed ASes. Then in this case, it is
> desirable to get the ability to reroute an inter-AS TE LSP in a non-
> disruptive fashion (making use of the so called Make Before Break
> procedure) to follow this more optimal path. This is a known as a TE
> LSP reoptimization procedure.
>
> ## Is there any requirement to redescribe the procedures of
> ## [LOOSE-PATH-REOPT]? Why not simply state that...
> ## [LOOSE-PATH-REOPT] describes a mechanism to control discovery
> ## or more optimal paths, and to signal new paths using make before
> ## break.
AA----> Nope, no need at all.

> #### BEGIN DELETE
> #
> #
>
> [LOOSE-REOPT] proposes a mechanisms allowing:
> ## s/[LOOSE-REOPT]/[LOOSE-PATH-REOPT]/ -- change throughout the doc
> ## s/proposes/defines/
>
>
>  Vasseur, Ayyangar and Zhang                                  14
>
>
>
> draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005
>
>
>       - The head-end LSR to trigger on every LSR whose next hop is a
>       loose hop the re evaluation of the current path in order to
> ## s/re evaluation/re-evaluation/
>       detect a potentially more optimal path. This is done via
>       explicit signaling request: the head-end LSR sets the ôERO
>       Expansion requestö bit of the SESSION-ATTRIBUTE object carried
>       in the RSVP Path message.
>
>       - An LSR whose next hop is a loose-hop to signal to the head-
>       end LSR that a better path exists. This is performed by sending
>       an RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6
>       (Better path exists).
>
>       This indication may be sent either:
>
>             - In response to a query sent by the head-end LSR,
>              - Spontaneously by any LSR having detected a more
>              optimal path
>
> Such a mechanism allows for the reoptimization of a TE LSP if and only
> if a better path is some downstream area/AS is detected.
>
> The reoptimization event can either be timer or event-driven based (a
> link UP event for instance).
>
> Note that the reoptimization MUST always be performed in a non-
> disruptive fashion.
>
> Once the head-end LSR is informed of the existence of a more optimal
> path either in its head-end area/AS or in another AS, the inter-AS TE
> Path computation is triggered using the same set of mechanisms as when
> the TE LSP is first set up. Then the inter-AS TE LSP is set up
> following the more optimal path, making use of the make before break
> procedure. In case of a contiguous LSP, the reoptimization process is
> strictly controlled by the head-end LSR which triggers the make-before-
> break procedure, regardless of the location where the more optimal path
> is.
>
> Note that in the case of loose hop reoptimization, the TE LSP may
> follow a preferable path within one or more domain(s) whereas in the
> case of PCE-based path computation techniques, the reoptimization
> process may lead to following a completely different inter-domain path
> (including a different set of ABRs/ASBRs) since end-to-end shortest
> path is computed.
>
> #
> #
> #### END DELETE
>
> 7.2.   Stitched or nested (non-contiguous) TE LSPs
>
> ## This section contains quite a lot of repetition.
>
> In the case of a stitched or nested inter-domain TE LSP, the re-
> optimization process is treated as a local matter to any Area/AS. The
> main reason is that the inter-domain TE LSP is a different LSP (and
> therefore different RSVP session) from the intra-domain LSP segment or
>
> ## Your causality is broken. Being a different LSP does not imply
> ## being a different session. However, the key point *is* that this
> ## is a different session (with different ingress and egress).
AA-----> We'll simply highlight that this is a different session.

<snipped>

> 8.     Security Considerations
>
> ## This section seems very lightweight given the importance of
> ## inter-AS trust boundaries.
AA----> I agree. We should add details about policy control, trust
relationship; etc . They may be an overlap with the signaling
ID, but that's okay. Also, need to highlight how a boundary node (or any
other node) would handle the case where it is being overwhelmed with path
computation requests for an inter-domain LSP from some other domain.

thanks,
-arthi

---

From: JP Vasseur <[email-masked]>
Date: Fri, 29 Jul 2005 00:53:23 +0200

Thanks for your comments Adrian. I hadn't missed it, just did not  
find the time to reply yet ... More after this IETF.

Thanks.

JP.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Jul 2005 11:49:58 +0100

Hi Arthi,

[SNIPPED]

This would be a good topic to close at the meeting.
What you say here is OK: that is, if the hop is not in the TED *and* does
not have IP reachability, then computation fails.
Clearly, we also know what to do when the hop is in the TED (regardless of
IP reachability).

The issue we have to cover is what to do when the hop is *not* in the TED,
but we do have IP reachability.
What does this mean when we have a separate data and control plane? What
does it mean when the data and control planes are shared (as in MPLS)?
I think there may be some subtle operational issues hiding here and I feel
a BCP coming on :-(

If you could mention this in your slot, that would be valuable. If folks
with opinions could rush to the mic (or the mailing list), that would also
be helpful.

Cheers,
Adrian