Ron:

I still feel that all SID (including adj SID as well as Node SID) is node-local 
significance in your SRv6+ draft May be a problem, even if you has explained it 
previously.

From my understanding, the Node SID (for loopback@) must be global significance 
in SR-enabled domain, so that every Node within SRv6 domain can find the least 
cost path to the other Node which advertising its Node segment in IGP 
extension, every Node has its Node-segment and adj-segments for itself, these 
SIDs must be assigned by Node itself, not by other Nodes within SR-enabled 
domain.

From example described in section "5.1 Range" in your draft, I deduced, within 
SR domain, each node must assign independently a unique SID or more for other 
every Node from its perspective, for example, for Node 100, Node 1 can assign 
Node SID#11 to the Node 100, and Node 3 can assign Node SID#13 to Node 100, it 
means that Node 1 is segment ingress node for SID 11 whose instruction 
correspond to going to Node 100 via least cost path, Node 3 is segment ingress 
node for SID 13 to Node 100, following this way, How the ingress PE node 
calculate the E2E SR path within domain, because the ingress PE must know all 
different Segment SIDs assigned by every Node from its perspective, that is to 
say, in your case, one Node must receive 4999*4999 Node SIDs, 4999 for each 
Node, in order to achieve this goal, every Node must advertise all other Nodes' 
Node segments assigned by itself from its perspective, but it may be not 
possible, because each node has to advertise lots of SIDs in IGP extension, it 
is complex.

Although a good SIDs assigning way described in section "5.3 Assigning SIDs to 
Node segments", but meaning of this way in fact is not same as your essential 
meaning of your section 5.1.  in fact you have used the global significance of 
SID, and each Node assign SID to itself and in further advertising it in IGP 
extension. 


--------------------------------------
Thank you !


WANG Weibin  

-----Original Message-----
From: spring <[email protected]> On Behalf Of Ron Bonica
Sent: 2019年8月28日 23:38
To: SPRING WG <[email protected]>; IPv6 List <[email protected]>
Subject: [spring] FW: New Version Notification for 
draft-bonica-spring-srv6-plus-05.txt

FYI


Juniper Public

-----Original Message-----
From: [email protected] <[email protected]> 
Sent: Wednesday, August 28, 2019 11:31 AM
To: Ron Bonica <[email protected]>; Shraddha Hegde <[email protected]>; 
Andrew Alston <[email protected]>; Gang Chen <[email protected]>; 
Joel Halpern <[email protected]>; Andrew Alston 
<[email protected]>; Daniam Henriques 
<[email protected]>; Jen Linkova <[email protected]>; Yuji 
Kamite <[email protected]>
Subject: New Version Notification for draft-bonica-spring-srv6-plus-05.txt


A new version of I-D, draft-bonica-spring-srv6-plus-05.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:           draft-bonica-spring-srv6-plus
Revision:       05
Title:          IPv6 Support for Segment Routing: SRv6+
Document date:  2019-08-28
Group:          Individual Submission
Pages:          23
 

Abstract:
   This document describes SRv6+. SRv6+ is a Segment Routing (SR)
   solution that leverages IPv6.  It supports a wide variety of use-
   cases while remaining in strict compliance with IPv6 specifications.
   SRv6+ is optimized for ASIC-based forwarding devices that operate at
   high data rates.

                                                                                
  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to