[Pce] 答复: Quick Review of SR Inter-domain and association

<xiong.quan@zte.com.cn> Wed, 17 July 2019 03:13 UTC

Return-Path: <xiong.quan@zte.com.cn>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43B1200DB; Tue, 16 Jul 2019 20:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eKBQy79039I; Tue, 16 Jul 2019 20:13:47 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02D8120058; Tue, 16 Jul 2019 20:13:46 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id BD17D8B1C40DF3BD1398; Wed, 17 Jul 2019 11:13:44 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id AD8F089C27019F369017; Wed, 17 Jul 2019 11:13:44 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id x6H3DNnG083810; Wed, 17 Jul 2019 11:13:23 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Wed, 17 Jul 2019 11:13:23 +0800 (CST)
Date: Wed, 17 Jul 2019 11:13:23 +0800
X-Zmail-TransId: 2afa5d2e9253ccf44aab
X-Mailer: Zmail v1.0
Message-ID: <201907171113236375501@zte.com.cn>
In-Reply-To: <CAB75xn6enth=ECq3QobYXWLqrQSBx+bT_5=65ErtgMbhfk5WEQ@mail.gmail.com>
References: CAB75xn6enth=ECq3QobYXWLqrQSBx+bT_5=65ErtgMbhfk5WEQ@mail.gmail.com
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: dhruv.ietf@gmail.com
Cc: draft-xiong-pce-stateful-pce-sr-inter-domain@ietf.org, draft-hu-pce-stitching-lsp-association@ietf.org, pce@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x6H3DNnG083810
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/k7XwL5G3m0fGGKWWIGMagxFSAt0>
Subject: [Pce] 答复: Quick Review of SR Inter-domain and association
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2019 03:13:50 -0000

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.










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







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