RE: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi Tom,

With respect to that draft I have a few questions:

1. Doesn't G-SRv6 require a different routing type? I don't see how
G-SRv6 compatible could be compatible with RFC8754 which clearly
defines SIDs to be 128 bits.
[Zhibo] No, we don't require a different routing type, because we don't modify the format of SRH. Segment Left points to a 128 bit SID, and it may contain multiple G-SIDs. The appearance of G-SID is indicated by COC Flavor.

2. Where would the work for G-SRv6 be done? Since work for SRH was
done in 6man, I tend to think G-SRv6 should also be in 6man.
[Zhibo] Well, we think the architecture should be done in SPRING, because we need to define a new flavor of SIDs. Regarding the dataplane extension, it should be done in 6man.

3. Given that Flags, Tag, and TLVs are not critical and unused in the
common case, and with no TLVs Last Entry is unnecessary, can't these
fields simply be omitted in the compressed format to reduce overhead?

[Zhibo] Of cause you can do that. Like CRH.  But we think Flags, Tag and TLVs are important since it provides flexibilities and programmability. We can use these fields to support many per-path of per-segment use cases. The value of them worth to get 32 bits.

When considering overhead reducing, it is VERY IMPORTANT to not sacrifice features. 

Reducing overhead by deleting features  seems not clever.

RH was defined in 6man. 

Thanks
Zhibo Hu

-----Original Message-----
From: Tom Herbert [mailto:tom@herbertland.com] 
Sent: Monday, May 25, 2020 10:35 PM
To: Huzhibo <huzhibo@huawei.com>
Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
Subject: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

On Mon, May 25, 2020 at 7:09 AM Huzhibo <huzhibo@huawei.com> wrote:
>
> Hi 6man,
> I do not support the adoption.
>
>
> I don't know what is the requirement of the CRH. If CRH is used for 
> steering SR-MPLS traffic over IP network, then RFC8663 has provided a 
> really good solution. If CRH is aiming to address the overhead problem 
> of SRv6, then it is recommended to define a mechanism under SRv6 
> framework, instead of inventing a huge set of control plane and data 
> plane solutions. Also, we think G-SRv6 for compression has solved the 
> overhead problem of SRv6.[1]
>
> Best regards,
> Zhibo Hu
>
> [1]https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cm
> pr-01
>
Hi Zhibo,

With respect to that draft I have a few questions:

1. Doesn't G-SRv6 require a different routing type? I don't see how
G-SRv6 compatible could be compatible with RFC8754 which clearly defines SIDs to be 128 bits.
2. Where would the work for G-SRv6 be done? Since work for SRH was done in 6man, I tend to think G-SRv6 should also be in 6man.
3. Given that Flags, Tag, and TLVs are not critical and unused in the common case, and with no TLVs Last Entry is unnecessary, can't these fields simply be omitted in the compressed format to reduce overhead?

Tom

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
> Sent: Saturday, May 16, 2020 6:14 AM
> To: IPv6 List <ipv6@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>
> Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
> This message starts a two-week 6MAN call on adopting:
>
>  Title:          The IPv6 Compact Routing Header (CRH)
>  Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
>  File Name:      draft-bonica-6man-comp-rtg-hdr-21
>  Document date:  2020-05-14
>
>  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
>
> as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.
>
> Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.
>
> This adoption call will end on 29 May 2020.
>
> The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.
>
> Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
> to work on this.
>
> Regards,
> Bob and Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------