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

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Mon, 14 Oct 2019 08:49:55 +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

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Tue, 15 Oct 2019 00:36:59 +0000

Sorry, the prefix length is wrong,  2001:db8:xx00::/40 advertised by Node, then 2001:db8:xxyy::/48 representing Node-SID and Adj-SIDs are instantiated within Node’s scope.

WANG Weibin

From: Wang, Weibin (NSB - CN/Shanghai)
Sent: 2019年10月14日 16:50
To: SPRING WG List <[email-masked]>
Subject: questions about draft-filsfils-spring-net-pgm-extension-srv6-usid-02

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.

WANG Weibin