[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

hi arthi, see in-line for some clarifications

Arthi Ayyangar wrote:

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 ?

i understand the point on pre-created <-> advertised but this knowledge may be useful for nodes part of the same area (not for nodes external to this area) so in case a node for inst. advertises three terminating links with PSC-2 (one of these being the LSP segment) then a another node (part of the same area) receiving an incoming multi-area PSC-2 LSP request may start making use of this segment to join the next border, therefore advertisement of the LSP segment may create a multi-hop condition, but now once used relevance of the existence of the segment is not a useful information (for the area) as there is no possibility to make re-use of it except when the end-to-end LSP is torn down

a more technical point is related to the definition of an FA LSP which per LSP-Hierarchy mandates crossing LSP region border: the head-end and tail-end switching capability represent the SC of the resulting TE link while intermediate node terminates the SC corr. to the switching type of the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2 capable network with first and last link being [PSC-1,PSC-2] and [PSC-2,PSC-1], resp.), while in the LSP segment case we would have now the creation of a [PSC-1,PSC-1] link with first and last link being [PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border crossing anymore - so here the question is about definition and detailing the triggers

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.

well, in the LSP Hierarchy case, if one wants to maintain resilience against channel or software failures for the nested LSPs one needs to maintain a signaling adjacency (by exchanging hello messages by which the restart and recovery time will be exchanged between the tail and the head-end of the FA-LSP), in the present case, such construction could also be possible as the penultimate hop for inst. does not know about the details concerning the end-to-end LSP since the Path message was (during setup phase) sent directly to the LSP segment tail-end

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

i am ok for the rest

much thanks,
- dimitri.

thanks,
-arthi



.