[spring] questions about draft-filsfils-spring-net-pgm-extension-srv6-usid-02

"Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com> Mon, 14 October 2019 08:50 UTC

Return-Path: <weibin.wang@nokia-sbell.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C0120137 for <spring@ietfa.amsl.com>; Mon, 14 Oct 2019 01:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 iNMsKfwSAkC8 for <spring@ietfa.amsl.com>; Mon, 14 Oct 2019 01:50:01 -0700 (PDT)
Received: from cnshjsmin03.nokia-sbell.com (cnshjsmin03.app.nokia-sbell.com [116.246.26.71]) (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 2E241120130 for <spring@ietf.org>; Mon, 14 Oct 2019 01:50:00 -0700 (PDT)
X-AuditID: ac189297-d29ff70000006f83-0e-5da436b3fc2f
Received: from CNSHPPEXCH1606.nsn-intra.net (Unknown_Domain [135.251.51.106]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by cnshjsmin03.nokia-sbell.com (Symantec Messaging Gateway) with SMTP id 16.CB.28547.3B634AD5; Mon, 14 Oct 2019 16:49:55 +0800 (HKT)
Received: from CNSHPPEXCH1605.nsn-intra.net (135.251.51.105) by CNSHPPEXCH1606.nsn-intra.net (135.251.51.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 14 Oct 2019 16:49:55 +0800
Received: from CNSHPPEXCH1605.nsn-intra.net ([135.251.51.105]) by CNSHPPEXCH1605.nsn-intra.net ([135.251.51.105]) with mapi id 15.01.1713.007; Mon, 14 Oct 2019 16:49:55 +0800
From: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>
To: SPRING WG List <spring@ietf.org>
Thread-Topic: questions about draft-filsfils-spring-net-pgm-extension-srv6-usid-02
Thread-Index: AdWCY7gbbUSIYRV3TD21EeP4rJcGCg==
Date: Mon, 14 Oct 2019 08:49:55 +0000
Message-ID: <9536ccca50ac4c6eb43acafed5efa83f@nokia-sbell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.251.51.115]
Content-Type: multipart/alternative; boundary="_000_9536ccca50ac4c6eb43acafed5efa83fnokiasbellcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsXS/ts4S3ez2ZJYg4cfTCyOX/jN6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLuTt7MU3LSv+PxoGVMD42azLkZODgkBE4m1ny4xdzFycQgJ HGKSuD7jOBOE85dR4uLtd2wQziZGiZs37rKDtLAJuElM2raLDcQWEVCRWPTxEmsXIweHsICv xIdb3CCmiECIRPfZaIgKPYkjZ9exgtgsAqoSLy7dBOpk5+AVsJN47wgSZRQQk/h+ag0TiM0s IC5x68l8JojTBCSW7DnPDGGLSrx8/A9sj4SAkkTfBqjyVImtS7aAncUrIChxcuYTlgmMQrOQ TJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilE6Oa84I6s4NzPPwFgvLz87 M1G3OCk1J0cvOT93EyMwMtZITJq+g/HYAe9DjAIcjEo8vCeSF8cKsSaWFVfmHmKU4GBWEuFl mLAgVog3JbGyKrUoP76oNCe1+BCjNAeLkjhvy+SFsUIC6YklqdmpqQWpRTBZJg5OqQZGxtkG Jf0yuh+rZ0zXk5G8X5Oi+DfRVMhxt5us94njm5cFX5DlmXmHnXO724S1dmcWtnsw3wju/XH7 fVYPv/C28EnP61bZPuBsP3No4/QU/qAWoZkW6ryrNhZm3Nu86sY/d4YvyqWB067eS7YrDBU4 JX/xYs09teUd+/d1MNZNWfx5wY5AviA1JZbijERDLeai4kQAmV3Q8IgCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ydpd1Dpkba7m9H_i6ALRNrAnqgo>
Subject: [spring] questions about draft-filsfils-spring-net-pgm-extension-srv6-usid-02
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 08:50:06 -0000

Hi folks:

I have read through the micro-SID draft, and a confusion arise in my mind, the example in this draft only illustrate how the uSID carrier operate using Node-SRv6-SID, not including SRv6 SID representing Adj-SID. that is to say the uSID carrier only encoding Node-SRv6-SID in this draft, Is this right from my understanding to this draft?
As of one Node can have lots of IPv6 interfaces, so we must have lots of SRv6 SIDs representing these interfaces respectively, as a result lots of SRv6 SIDs May be reserved for this purpose. I don't see the author clearly organize these Adj-SIDs; I think we can further divide uSID, for example, if 2 bytes represent uSID, the first byte May identify Node itself, and the 2nd byte identify interface link (Adj-SID), so following the example in this draft, 2001:db8/16 representing uSID block, every prefix 2001:db8:xx00/24 can be allocated to a Node, and 2001:db8:xxyy::/32 can be assigned to SRv6 SIDs representing Node-SID or Adj-SID within the Node. So the Node only advertise 2001:db8:xx00::/24 prefix by IGP or BGP SR-extension, need not advertise lots of /32 for SIDs instantiated within this Node , the other Node within SRv6 domain can have lots of /24 routes which can route packets to target Node, it's table lookup is still according to longest-prefix-match.
Another question about SRv6 SID significant-scope, I think TE function is one main application of SRv6, topology SRv6 SIDs including Node-prefix-SID and Adj-SID have local significant within SRv6 domain controlled by one organization (operator), the SIDs only assist the operator to control and steering traffic within its controlled domain, these SRv6 SIDs need not have meaningful outside the domain, so these type of SRv6 SIDs must be not leaked outside of SRv6 domain, doing that is also helpful for security against DDOS. But the service SRv6 SIDs such as End.DT4 or DT6 etc. advertised by MP-BGP extension is not same with above topology SIDs, because the VPN service identified by END.DT4/6 My be across several ASes controlled by different operators, So service SIDs such as END.DT4/6 May be global significant within open-internet-wide.


--------------------------------------
Cheers !


WANG Weibin