Hi Dhruv,
Thanks for your reply! My clarification is as follows tagged with Quan>>.
Best Regards,
Quan
原始邮件
发件人：DhruvDhody <[email protected]>
收件人：熊泉00091065;
抄送人：[email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
日 期 ：2019年07月19日 22:19
主 题 ：Re: Quick Review of SR Inter-domain and association
Hi Quan,
First of all thanks for your reply to the list...
On Wed, Jul 17, 2019 at 8:43 AM <[email protected]> wrote:
Hi Dhruv,
Thanks for your review and suggestions! It is very appreciated!
My clarification is as follows tagged with Quan>>.
Best Regards,
Quan
<<Hi Authors,
<<I did a quick review of the I-Ds, but some key questions came up, it
<<would be nice if they could be clarified before hand.
--
(1) Association:
It is important to describe where this association exist and what role
does that play, to me the importance of the association is at the
Parent PCE only and thus the existing Stateful H-PCE [1] procedures
should be enough IMHO.
See figure 2 in your I-D, ASSOC 1 LSPs are distributed between all the
other child PCEs and thus not at clear why a child PCE need to be
aware of the association when it does not know any other LSP (outside
of its domain, that are part of the same association group).
Quan>>I agree with you and thanks for your suggestion. The Stitching LSP
association is created and maintained at parent PCE. The Stitching LSP
association is used in inter-Area scenario. The association is useful when the
LSPs from multiple domains are aready created and the parent PCE may
associate them into a group and achieve the end-to-end LSP. I will update
and clarify the use case and the detailed operation as following shown.
Dhruv: The key question is why does the child PCE (PCE-1,2,3) needs to be aware
of this association once it is created at the parent PCE? In other words what
do you expect the child PCE to do when it receives a PCUpd message with the
association information? Answering this question would help to clarify the need.
Quan>> Once the association is created, the parent PCE sends PCInitailte/PCUpd
message to child PCEs. Then the child PCEs will configure this
association to the ingress nodes and related LSPs in each domain. For
example, when the LSP-1 reaches node X along SR path , the node X will find the
association which the LSP-1 belongs and forward the packets to the LSP-2
which belongs to the same association.
(2) Path Segment:
I saw the spring I-D [2] as well, and was thrown by the use of path
segment as a way to stitch. My gut feeling was isn't that more like a
binding segment? Also for stitching label in PCE, please check
Olivier's I-D [3].
So, some clarity on what exactly you would like to achieve and the
reason behind the use of association and path segment is required.
Quan>>I have compared my draft with [3] before. I think my draft focus on
the SR inter-domain scenario and provide end-to-end solution with path
segment. The path segment is the path identifier and it can be used to
correlate SR paths. When the path segment is used to correlate two
inter-domain LSPs, it is used as a stitching label and the path segment
in SR networks can be viewed as an instantiation or specific application
for the stitching label which proposed in draft[3]. The path segment used
as a stitching label in inter-AS scenario as following shown.
Dhruv: I understand what you want to achieve, but I am not able to grasp why
use Path segment for it. Anyways the use of path segment in this way should get
consensuses in SPRING WG first.
Quan>> Yes, we have proposed another use case draft in Spring WG. This draft in
PCE WG is the solution for it. We hope to get consensuses in Spring and Pce WGs
at the same time. We use path segment to provide the SR end-to-end
bidirectional path. The Path Segment is used to correlate the inter-domain
paths and foward and reverse unidirectional paths in SR label stack.
Safe Travels!
Thanks!
Dhruv
I hope you would focus on these aspects during your presentation.
Discussion on the list would be even better.
Thanks,
Dhruv
[1] https://tools.ietf.org/html/draft-ietf-pce-stateful-hpce-11
[2]
https://tools.ietf.org/id/draft-xiong-spring-path-segment-sr-inter-domain-00.txt
[3] https://tools.ietf.org/html/draft-dugeon-pce-stateful-interdomain-02
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
