Hi Shuping; Thanks for your response, It is expected that there are SRv6 trials with SRH encapsulated in china which are * REAL* SRv6 network programming cases.
Cheers! Wang Weibin 191-4559-6869 From: Pengshuping (Peng Shuping) <pengshup...@huawei.com> Sent: Monday, March 9, 2020 4:24 PM To: Wang, Weibin (NSB - CN/Shanghai) <weibin.w...@nokia-sbell.com> Cc: SPRING WG <spring@ietf.org> Subject: RE: [spring] SRv6 PSP use case--benifit of SRv6 Hi Weibin, Please find in-line starting with [Answer]. From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com] Sent: Friday, March 6, 2020 1:15 PM To: Pengshuping (Peng Shuping) <pengshup...@huawei.com<mailto:pengshup...@huawei.com>>; Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org<mailto:ketant=40cisco....@dmarc.ietf.org>>; Mark Smith <markzzzsm...@gmail.com<mailto:markzzzsm...@gmail.com>>; Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: RE: [spring] SRv6 PSP use case--benifit of SRv6 Hi authors： Thanks for sharing the SRv6 deployment cases in china; Can I express my views? From the contents of the section 2 and section 3 in your draft perspective: 1) Because the design of SRv6 is an incremental deployment over existing IPv6 network, it will not affect the existing IPv6 deployment and the existing IPv6 address allocation method. Therefore, the easiest way to allocate an IPv6 address for an SRv6 deployment is to take a / 40 or / 48 address block directly from the IPv6 address blocks allocated from RIR. In ordinary IPv6 address allocation method, even each broadband user may also be assign a / 64 prefix, and an organization needs to assign prefixes such as / 48, / 56, or /60, etc. Therefore, / 48 for SRv6 deployment is not a waste of addresses. [Answer] Just / 48 may not be enough. Please see more below. 2) In section 3, it is not given how many bits each node needs to identify the node itself (i.e. N of B: N), which is a part of the locator. It is generally considered that 2 bytes are reasonable; [Answer] 2 bytes could be used. 3) For FUNC.Length and Argu.Length, I think its length is a multiple of byte is better, it is more conducive to the read operation of the router. [Answer] For Ipv6 address planning, generally 4bits is used as a nibble. With 8bits/Byte would also be ok, just it may cause address waste. 4) Therefore, my point is that for a backbone network or a metropolitan area network, the / 48 address block is a reasonable deployment for SRv6, then / 64 is used as the locator for each node, and the next 4 bytes are used as func .length, and 2 bytes as Argu.length, the last 2 bytes are filled with 0; of course, as service SID is becoming mature, another /48 may be allocated for it for purpose of supporting SR service programming within SRv6 domain. [Answer] It may not be enough to use / 48 address block for a SRv6 network and then / 64 for each node. It is because between the network locator and the device locator there would be many other identifiers that requires space allocation, such as device identifier, slice identifier as well as locator type identifier, etc.. It would be a bit long for using 4 bytes as func.length and 2 bytes as Argu.length. 5) I believe, The benefits of SRv6-BE in section 2 are not brought by SRv6 itself, it is only side effect of SRv6. If we use MPLS over UDP tunnel in IPv4 environment, we can also achieve the same benefit of simple cross-domain VPN service deployment, which is the same as SRv6-BE, of course, it does not have TE capability. [Answer] Yes, for this particular aspect, the benefit would be the same. However, please don't forget other advantages brought by SRv6 only instead of MPLS plus some additional add-ons. SRv6 can provide BE with route aggregatability as well as TE with simply the IPv6 as the data plane. Cheers! Wang Weibin Best regards, Shuping From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Pengshuping (Peng Shuping) Sent: Friday, March 6, 2020 12:08 AM To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org<mailto:ketant=40cisco....@dmarc.ietf.org>>; Mark Smith <markzzzsm...@gmail.com<mailto:markzzzsm...@gmail.com>>; Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] SRv6 PSP use case Hi all, We just updated our draft on the SRv6 Deployment Consideration. One of the new updates in the draft is to add some of the PSP use cases, which is inspired by the discussions over the mailing list. Your comments on the draft are very welcomed as well as more PSP use cases. Thank you! The posted draft can be found here, https://tools.ietf.org/html/draft-tian-spring-srv6-deployment-consideration-01. Best regards, Shuping
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
