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