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

[Tom Herbert <[e-mail]>]

On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Tom,
> I agree that "and ignored on receipt" in the definition of the Flags field makes the future use of the field more restrictive. But I believe that can be mitigated, as I've mentioned earlier, via control and/or management plane extensions. Not that we have not faced a similar situation before and dealt with the challenge in a reasonable way.

Or just create a new routing type that is universally unambiguous,
doesn't require external information just to understand the header
format, and carries not risk of breaking backwards compatibility. Like
Joel said, being compatible with SRH routing type for compressed SIDs
isn't a requirement and I can think of any reason why it should be. A
new routing type is also an opportunity to revisit all the fields in
the header, for instance we can reevaluate whether Flags, Tags, and
TLVs are really needed in a routing header.

Tom

>
> Regards,
> Greg
>
> On Thu, May 28, 2020 at 1:14 PM Tom Herbert <[e-mail]> wrote:
>>
>> On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <[e-mail]> wrote:
>> >
>> > Hi Tom,
>> > you've noted that "The format of SRH is very specific that SIDs are 128 bits". True, that is the view, the current view based on the definition of SRv6 and SRH in  RFCs 8402 and 8754. But both may be updated at some point. Thus we can avoid the introduction of RH per SID length. Would you agree that it is a viable option?
>>
>> Greg,
>>
>> Unfortunately it's not an option. There is no field in SRH that could
>> robustly be used as a code point to indicate an alternate header
>> format or different length of SIDs. Neither is there any way to
>> retroactively add that this since RFC8754 is already out the door and
>> in deployment. This is analogous to someone wanting to create a
>> compressed version of the IPv6 header to use 64-bits instead of 128
>> bit addresses-- there is no way to do that without getting a new IP
>> version number. The difference in the analogy, is that the IP version
>> number space is only4 bits, but the routing type space is 8 bits. So
>> allocating new routing types for compressed SIDs really isn't much
>> issue since there are plenty of values available (247 routing type
>> values are unassigned whereas only 5 IP version numbers are
>> unassigned).
>>
>> Tom
>>
>> >
>> > Regards,
>> > Greg
>> >
>> > On Thu, May 28, 2020 at 11:33 AM Tom Herbert <[e-mail]> wrote:
>> >>
>> >>
>> >>
>> >> On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <[e-mail]> 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:[e-mail]>
>> >>> >     *Date:* 2020-05-16 06:13
>> >>> >     *To:* IPv6 List <mailto:[e-mail]>
>> >>> >     *CC:* Bob Hinden <mailto:[e-mail]>
>> >>> >     *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-
>> >>> > [e-mail]，即可以退订此邮件。我们将立即将您的信息从我们的发送
>> >>> > 目录中删除。 If you have received this email in error please notify us
>> >>> > immediately by e-mail. Please reply to [e-mail] ,you can
>> >>> > unsubscribe from this mail. We will immediately remove your information
>> >>> > from send catalogue of our.
>> >>> >
>> >>> > --------------------------------------------------------------------
>> >>> > IETF IPv6 working group mailing list
>> >>> > [e-mail]
>> >>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >>> > --------------------------------------------------------------------
>> >>> >
>> >>>
>> >>> --------------------------------------------------------------------
>> >>> IETF IPv6 working group mailing list
>> >>> [e-mail]
>> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >>> --------------------------------------------------------------------
>> >>
>> >> --------------------------------------------------------------------
>> >> IETF IPv6 working group mailing list
>> >> [e-mail]
>> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >> --------------------------------------------------------------------