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

On Mon, May 25, 2020, 7:41 PM Huzhibo <huzhibo@huawei.com> wrote:

> 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.
>

Zhibo,

Thanks for the clarification, but it's still not clear to me exactly how
this works. Can you provide an example of what a SRH with G-SIDs looks
like? For instance, suppose there are one or two SIDs that can be
compressed to 16 bits-- this could be sent in an 8 byte CRH (4 bytes for
header and 4 bytes for two SIDs 2*2). Similarly, in a 16 byte CRH we can
encode 3, 4, 5, or 6 16 bit SIDs. Can you describe the analogous format and
header sizes for these scenarios in G-SRv6?

Also, how does segments left work if it only points to a 128 bit SID that
SID may itself be composed of multiple G-SIDs?

>
> 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.
>

It's not so much removing features as it is compressing out fields that are
not commonly used. I suspect the vast majority of SRH implementations send
zeros in these fields which make them a good candidate for compression.

Tom

>
>
> 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
> > --------------------------------------------------------------------
>