Re: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I fully agree Gyan and I would like the discussion to be prioritized through SPRRING WG. 

KH

------------------- Original Message -------------------From    :  "Gyan Mishra" (hayabusagsm@gmail.com)To      :  "Wang, Weibin (NSB - CN/Shanghai)" (weibin.wang@nokia-sbell.com)Cc      :  "IPv6 List" (ipv6@ietf.org)
        "Ran Pang(联通集团联通网络技术研究院本部)" (pangran@chinaunicom.cn)
Date    :  2020/05/29 금요일 오후 2:23:22Subject :  Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I believe a few variants of what you propose have been done with the SRV6 compression drafts.
Gyan
On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <<a href="mailto:weibin.wang@nokia-sbell.com">weibin.wang@nokia-sbell.com wrote:
I think it is a good idea to create a new routing type for encoding new type of SID in RH.

I also think that, as a result of IPv6 address has 16 bytes length, its space is big enough, lots of bits-string within it is redundant and unnecessary in some scenario. so considering the classic SRv6 scenario, we can only use least significance 64 bits within a fixed /64 prefix block for all SID assigning for limited domain being deployed by SRv6.
That means, only one same  /64 block is enough for all kind of SIDs assigning within limited domain, so only rightmost 64 bits representing all SIDs allocated to all prefix-SID and Adj-SIDs and Service-SIDs should be encoded within SRH with new routing type value. During packets being encapsulated with outer IPv6 and new RH forwarding through SRv6 domain, its left-most 64 bits of DA field keep intact and only right-most 64 bits will be replaced endpoint by endpoint from SRH.SL. 
The benefit:
- get half-reduced SRH length compared to classic SRv6 SRH under same number of SIDs encoded segment list;
- keep same forwarding plane with classic SRH processing; no extra processing for deducing compressed SID or normal SID coding in SRH; keeping the simple of forwarding plane is most important for all solution.
- only one /64 prefix as SID block, the complexity level of security deployment is largely reduced.
- the efforts of control plane protocol extension such as ISIS-srv6 or OSFP-srv6 have being made previously can be reserved. 
- no mapping mechanism at forwarding procedure and control plane.
- the solution is balance between SRH size and complexity of forwarding plane.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <<a href="mailto:ipv6-bounces@ietf.org" target="_blank">ipv6-bounces@ietf.org On Behalf Of Tom Herbert
Sent: 2020年5月29日 4:48
To: Greg Mirsky <<a href="mailto:gregimirsky@gmail.com" target="_blank">gregimirsky@gmail.com
Cc: IPv6 List <<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org; Ran Pang(联通集团联通网络技术研究院本部) <<a href="mailto:pangran@chinaunicom.cn" target="_blank">pangran@chinaunicom.cn
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <<a href="mailto:gregimirsky@gmail.com" target="_blank">gregimirsky@gmail.com On Thu, May 28, 2020 at 1:14 PM Tom Herbert <<a href="mailto:tom@herbertland.com" target="_blank">tom@herbertland.com On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <<a href="mailto:gregimirsky@gmail.com" target="_blank">gregimirsky@gmail.com On Thu, May 28, 2020 at 11:33 AM Tom Herbert <<a href="mailto:tom@herbertland.com" target="_blank">tom@herbertland.com On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <<a href="mailto:jmh@joelhalpern.com" target="_blank">jmh@joelhalpern.com     *From:* Bob Hinden <mailto:<a href="mailto:bob.hinden@gmail.com" target="_blank">bob.hinden@gmail..com     *To:* IPv6 List <mailto:<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org     *CC:* Bob Hinden <mailto:<a href="mailto:bob.hinden@gmail.com" target="_blank">bob.hinden@gmail.com     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr <a href="mailto:spmc@chinaunicom
 .cn" target="_blank">spmc@chinaunicom.cn <a href="mailto:hqs-spmc@chinaunicom.cn" target="_blank">hqs-spmc@chinaunicom.cn ----- IETF IPv6 working group mailing list <a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 --- IETF IPv6 working group mailing list <a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 -- IETF IPv6 working group mailing list <a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 --

--------------------------------------------------------------------
IETF IPv6 working group mailing list
<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-- 

Gyan MishraNetwork Solutions Architect M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------