Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

In Paris you said that you hoped for comments on this revision soon so
that you could do a quick re-spin and request last call.

So here are my comments.

Cheers,
Adrian

===

Section 2.1
   Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that
   is setup across multiple domains using RSVP-TE signaling procedures
   described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are
   required to signal a contiguous TE LSP and the same RSVP-TE
   information for the TE LSP is maintained along the entire LSP path.
s/[RSVP-TE]and/[RSVP-TE] and/

====

Section 2.1
   Nesting - Nesting one or more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can also be used to nest
   one or more inter-domain TE LSPs into an intra-domain FA-LSP. While
   similar to stitching in the control plane, in the data plane, nesting
   allows for one or more inter-domain LSPs to be transported over a
   single intra-domain FA-LSP using the label stacking construct.
s/technique can also be used/technique can be used/

Not sure that I like you saying "FA-LSP" here. The intra-domain LSP may be
an FA-LSP or it may be a TE LSP advertised as a TE link into the other
domain.

It's a bit odd to compare with stitching which you haven't described yet.
Suggest you re-write the paragraph as...
   Nesting - Nesting one or more TE LSPs into another TE LSP is
   described in [LSP-HIERARCHY]. This technique can be used to nest
   one or more inter-domain TE LSPs into an intra-domain TE LSP
   using the label stacking construct.

====

Section 2.1
   Stitching - The concept of LSP stitching as well as the required
   signaling procedures are described in [LSP-STITCHING]. This technique
   can be used to stitch an inter-domain TE LSP to an intra-domain LSP
   segment. A inter-domain stitched TE LSP is a TE LSP made up of
   different TE LSP segments within each domain which are "stitched"
   together in the data plane so that an end-to-end LSP is achieved in
   the data plane. In the control plane, however, the different LSP
   segments are signaled as distinct RSVP sessions which are independent
   from the RSVP session for the inter-domain LSP.
s/signaling procedures are described/signaling procedures is described/
(yes, really)

You could add the comparison with hierarchies here. For example...
   While stitching is similar to nesting in the control plane, in the data
plane
   stitching allows for only one inter-domain LSPs to be associated with
   any one intra-domain LSP, but does not require the use of label stacks.

====

Section 2.1

I think this section should say that later in the document you will define
signaling extensions that allow the initiator of an inter-domain LSP to
request the type of signaling technique used. This will help the flow of
section 3.

====

Section 3 and 3.1
Could you format the bullet paragraphs better, please.

====

Section 3

   Whether an inter-domain TE LSP is contiguous, nested or stitched is
   determined mostly by the signaling method supported by or configured
   on the intermediate nodes, usually the domain boundary nodes that the
   inter-domain TE LSP traverses through. It may also depend on certain
s/traverses through/traverses/

====

Section 3

   inter-domain TE LSP traverses through. It may also depend on certain
   parameters signaled by the head-end node for the inter-domain TE LSP.

s/may also depend/also depends/
s/parameters signaled by/parameters that may be signaled by/

====

Section 3, second bullet.

Is it possible that the policies or capabilities at the boundary node
prohibit the support of the mechanism that is signaled?
If yes, you should add a note describing rejection.
If no, you should add "MUST use the mechanism requested in the signaling
message"

===

Section 3, 4th and 7th bullets

"Determine the next hop node" seems to be in conflict with "perform any
path computation".
I guess that when you say "determine the next hop node" you mean find the
next sub-object in the ERO, or determine the destination or next boundary
node.

====

Section 3.1
I would prefer you to say hierarchical LSP rather than FA-LSP.

====

Section 3.1
Please avoid using the word "appropriate".
For example...
   then a PathErr with the appropriate error code should be sent back
Please supply the actual error code that should be used. (Also use
"SHOULD".)

====

Section 3.1
Should you also describe the case where there is no ERO?

====

Section 3.2

   The propagation of Path Error
   upstream may be limited to within the domain or it may be sent all
   the way upstream to the head-end node of the inter-domain TE LSP.

This sounds as though a domain boundary is allowed to silently swallow the
PathErr message. I understand that you mean that a domain boundary may
attempt re-routing, but that is not what you have said.

====

Section 3.2

Your discussion of crankback is limited to attempting to select another
egress boundary node. This would certainly apply when a failure from a
downstream domain is reported to the ingress boundary node of an upstream
domain. However, you should also cover the case where the failure is
within the domain and the ingress boundary node attempts to re-route
within the domain.

====

Section 3.2

When a PathErr crosses a domain boundary it may be subject to policy and
aggregation of information. I think you should describe this.

====

Section 4.1 (also section 9.1)
   0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end
   node that originates the inter-domain TE LSP if it desires a
   contiguous end-to-end TE LSP (in the control & data plane). When set,
   this indicates that a boundary node MUST not perform any stitching or
   nesting on the TE LSP and the TE LSP MUST be routed as any other TE
   LSP (it must be contiguous end to end). When this bit is cleared, a
   boundary node may decide to perform stitching or nesting. A mid-point
   node not supporting contiguous TE LSP MUST send a Path Error message

a. s/MUST not/MUST NOT/
b. I have allocated bit number 4 (0x08) in the temporary registry of
LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as
a place holder until the IANA takes over this work. (I think we've
discussed this before -  the point of the temporary registry is to save
you having to change your code too often.)

====

Section 4.1 (and section 9.1)
Given that you have chosen to place you LSP Attributes bit in the optional
(transparent) version of the object, you may want to consider how you will
police its use. For example, what would happen if a domain boundary
ignored this flag?
The LSP Attributes draft suggests the use of the flag in the RRO in order
to record whether it has been acted on (if not recorded, then not acted on
and it is possible that nesting has been used). You might want to adopt
this procedure, too.

====

Section 5.1

        <-- AS-1 --->      <--- AS-2 --->        <-- AS-3 --> c

Spurious letter "c"

====

Section 5.1

You figure shows R7 connected to the egress CE, but your example says...
   - A protected inter-AS TE LSP T1 originated at R0 in AS1 and
   terminating at R6 in AS3 with following possible paths:

====

Section 5.1

Your example starts to talk about building a protected inter-AS LSP. But
it transpires that you propose using FRR to provide protection for the
resources used by a single unprotected LSP. I think you need to be careful
with your terminology.

====

Section 5.1

   - A protected inter-AS TE LSP T1 originated at R0 in AS1 and
   terminating at R6 in AS3 with following possible paths:

   LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6

   o p1 - a set of loose node hops crossing AS-2
     R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6

   o p2 - a set of strict interface hops crossing AS-2
     R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict)
     -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6

You need to be careful. What do you mean by "LSP hops"? Is this the path
of the LSP? In which case why are be bothering with the example?

On the other hand, what are p1 and p2? Are they possible paths? In which
case how can they have loose or strict hops? They must actually be
explicit routes (i.e. EROs). So why have you chosen this set of two EROs
when there are so many others possible?

====

Section 5.1

If you must use FRR in an example (although I can't see the value at all)
you need to get the example right.
B3 as quoted (ASBR1-ASBR2-ASBR3-ASBR6-ASBR7) is impossible on your
topology.
You probably mean ASBR1-ASBR2-ASBR3-ASBR6-R4-ASBR8-ASBR7


Similarly, B5 is not possible. You probably mean
ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR10-ASBR9

====

Section 5.2
   Let us consider an inter-AS TE LSP setup from R0 to R6, with example
   paths p1, p2 each.
Delete "each"

====

Section 5.2

What was the point of the discussion of the FRR bypass tunnels? They
didn't feature in the example at all, and only served to add confusion.
It would seem that you should move the discussion of FRR into section 6.

====

Section 6.1.3

   For each protected inter-domain TE LSP traversing the boundary node
   to be protected, a NNHOP backup must be selected by the PLR. This
   requires the PLR to setup a bypass tunnel terminating at the NNHOP.
   Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be
   achieved by analyzing the content of the RRO object received in the
   RSVP Resv message of both the bypass tunnel and the protected TE
   LSP(s) (see [NODE-ID]).

You need to be clear (as you are for tunneled and stitched cases) that for
inter-domain LSPs the RRO may well be masked. That is, in your example,
the RRO reaching the PLR ASBR1 will only contain hops ASBR4 and ASBR7 (R3
having been masked as confidential). The AS number may have been inserted.
So your tunnel B2 will not do the job and B3 will be needed (even though
B2 is functional, you can't use it because you don't know whether it is
functional).

Further, as you pointed out earlier in the document, local policy may
prevent the setup of TE LSPs that terminate within the domain. So B2 might
not exist.

Same comments do not apply to the use of B4 because it starts within the
upstream domain.

====

Section 6.2

This section looks to be a bit pointless. What are you trying to say?

Certainly you have not covered the need for disjoint paths (which is out
of scope) but doesn't just work without some effort.
You also haven't mentioned segment protection that applies signaling
control to the positioning of one-to-one protection tunnels.

====

Section 7
   The above mechanisms SHOULD be used for a contiguous inter-domain TE
   LSP to allow the head-end node of the inter-domain TE LSP to initiate
   make-before-break procedures.
You may want to relax this "SHOULD" in the light of [LOOSE-REOPT] being
informational, and describe the alternative procedures for reoptimization
of contiguous LSPs.

====

Notify messages.
You haven't described how Notify messages may be handled with respect to
domain boundaries.

====

Section 11.2
I don't think you need to reference RSVP-UNNUM or BUNDLING.