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

On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Several people, including at least one I-D, have asserted that there is
> some abstract requirement for compatibility with SRvc6's SRH.  There is
> no such requirement.  That is not a criterion the 6man group needs to
> consider.  In my personal opinion, it is not even a constraint on what
> SPRING chooses to do.
>

Joel,

It's not even clear what compatibility with SRH means. The format of SRH is
very specific that SIDs are 128 bits, and the protocol has no sufficient
extensibility mechanism that allows that to change without breaking
backwards compatibility. As far as I can tell, changing or compressing SIDs
requires a new routing type regardless of the compression method or who
specifies it.

Tom

> Yours,
> Joel
>
> On 5/28/2020 3:38 AM, Ran Pang(联通集团联通网络技术研究院本部) wrote:
> > Hi WG,
> >
> > It seems like CRH is not compatible with SRv6 and SRH. We need to
> > discuss how CRH cooperates with uSID, G-SRv6 or other SRv6 header
> > compression solutions before adoption, or whether CRH will cause
> > difficulties in the deployment of G-SRv6 and other solutions. At
> > present, we tend to choose solutions compatible with SRH.
> >
> >
> > Thanks,
> >
> > Ran
> >
> >
> >     *From:* Bob Hinden <mailto:bob.hinden@gmail.com>
> >     *Date:* 2020-05-16 06:13
> >     *To:* IPv6 List <mailto:ipv6@ietf.org>
> >     *CC:* Bob Hinden <mailto: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
> >
> > 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 hqs-
> > spmc@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送
> > 目录中删除。 If you have received this email in error please notify us
> > immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can
> > unsubscribe from this mail. We will immediately remove your information
> > from send catalogue of our.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>