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

["Chengli (Cheng Li)" <[e-mail]>]

Yes, agree with that. Personally, I think most of the issues will be addressed if we start from SPRING.

Thanks,
Cheng


From: ipv6 [mailto:[e-mail]] On Behalf Of ???/??
Sent: Friday, May 29, 2020 1:45 PM
To: Wang Weibin (NSB - CN/Shanghai) <[e-mail]>; Gyan Mishra <[e-mail]>
Cc: IPv6 List <[e-mail]>; Ran Pang(联通集团联通网络技术研究院本部) <[e-mail]>
Subject: 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" (hayabu sagsm@gm ail.com)

To : "Wang, Weibin (NSB - CN/Shanghai)" ([e-mail]<mailto:[e-mail]>)

Cc : "IPv6 List" ([e-mail]<mailto:[e-mail]>)
        "Ran Pang(联通集团联通网络技术研究院本部)" ([e-mail]<mailto:[e-mail]>)

Date : 2020/05/29 금요일 오후 2:23:22

Subject : 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 d rafts.

Gyan

On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <[e-mail]<mailto:[e-mail]>> 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<http://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-srv 6 or OSF P-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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Tom Herbert
Sent: 2020年5月29日 4:48
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: IPv6 List <[e-mail]<mailto:[e-mail]>>; Ran Pang(联通集团联通网络技术研究院本部) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <[e-mail]<mailto:[e-mail]> > wro te:
>
> 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]<mailto:[e-mail]>> wrote:
>>
>> On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <[e-mail]<mailto:[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 t his sinc e 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]<mailto:[e-mail]>> wrote:
>> >>
>> >>
>> >>
>> >> On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <[e-mail]<mailto:[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 chang e withou t 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 compati ble with SRH.
>> >>> >
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Ran
>> >>> >
>> >>> >
>> >>> >     *From:* Bob Hinden <mailto:bob.hinden@gmail..com<mailto:[e-mail]>>
>> >>> >     *Date:* 2020-05-16 06:13
>> >>> >     *To:* IPv6 List <mailto:[e-mail]<mailto:[e-mail]>>
>> >>> >     *CC:* Bob Hinden <mailto:[e-mail]<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<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 th e list.< br>>> >>> >     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]<mailto:[e-mail]>，即可以退订此邮件。我们将立即将您的信息从我们的发送
>> >>> > 目录中删除。 If you have received this email in error please notify >&g t; >>> > us immediately by e-mail. Please reply to
>> >>> > [e-mail]<mailto:[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]<mailto:[e-mail]>
>> >>> > Administrative Requests:
>> >>> > https://www.ietf.org/mailman/listinfo/ipv6
>> >>> > ---------------------------------------------------------------
>> >>> > -----
>> >>> >
>> >>>
>> >>> -----------------------------------------------------------------
>> >>> --- IETF IPv6 working group mailing list [e-mail]<mailto:[e-mail]>
>> >>> Administrative Requests:
>> >>> https://www.ietf.org/mailman/listinfo/ipv6
>> >>> -----------------------------------------------------------------
>> >>> ---
>> >>
>> >> ------------------------------------------------------------------
>> >> -- IETF IPv6 working group mailing list [e-mail]<mailto:[e-mail]>
>> >> Administrative Requests:
>> >> https://www.ietf.org/mailman/listinfo/ipv6
>> >> ; ------------------------------------------------------------------
>> >> --

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------