Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

[Arthi Ayyangar <arthi@juniper.net>]

Hi Dimitri,

Thanks for your comments. Please see my replies inline.

> - section 3: why a TE link is to be associated to an LSP segment since
> at the end the segment exists only within the context of the end-to-end
> that triggers it, i.e. re-use of a segment is anyway not possible once
> created (unreserved bandwidth set to 0) so why other nodes would need to
> know about its existence ? other sections in this document do also refer
> to this but (see for inst. section 5.2) if the network sees the LSP
> segment as a TE link in their TE databases what does "computation of a
> path over this TE link." exactly means ?
---------> An LSP segment may be created either by configuration or due
to arrival of an e2e LSP setup request itself. Similar to an FA, an LSP
segment may or may not be advertised as a TE link. But, if pre-created, it
could be advertised, in which case other nodes may compute a path over it.
Why would you want to or not want to advertise an FA ? The same reasons
and restrictions apply to the LSP segment as well.

> - section 4: mentions "Although not adjacent in routing, the end nodes
> of the LSP segment will have a signaling adjacency and will exchange
> RSVP messages directly between each other." it would be interesting that
> you define what you mean by signaling adj. because imho such an adj. is
> based on the permanent exchange of hello msg
-------> This terminology (signaling adjacency) itself is borrowed from
the hierarchy document. The sentence following it, simply tries to
explain what it really means in the context of this doc. I am okay with
removing the "signaling adjacency", if it doesn't make sense.

> - section 4: the main difference between signaling an LSP over an LSP
> segment instead of over an FA-LSP is that no Labels are allocated and
> exchanged for the e2e LSP over the LSP segment hop -> therefore there is
> a specific configuration/usage of the label_request object when
> signaling the end-to-end LSP (as well as the upstream label for bi-dir
> LSP) to be detailed here
----> Okay.

> - section 5.1: mentions "Similar to setup, tearing down the LSP segment
> may also be decided either via local configuration or due to the fact
> that there is no longer an e2e LSP stitched to the LSP segment." it
> would be interesting to detail the deletion sequence when initiated from
> the end-to-end LSP head-/tail-end and stitching head-/tail-end
-------> Okay.

thanks,
-arthi