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

[Srihari Sangli <[e-mail]>]

Leveraging the IPv6 headers to achieve a functionality - I won't treat this as complicated. There is a reason Destination Options header was introduced in base IPv6 architecture. The proposal leverages just that. CRH is a generic routing header.

I don't agree with your assessment that its complicated. Thanks.

srihari…


On 26/05/20, 10:22 AM, "ipv6 on behalf of 刘毅松" <[e-mail] on behalf of [e-mail]> wrote:

    [External Email. Be cautious of content]


    Hi 6man WG,

    I do not support the adoption.

    For CRH based solution, the VPN context is encoded in a Destination Option
    header located after the CRH. At the egress PE, the packet arrives with both
    CRH and Destination Option headers. The egress PE will need to process TLVs
    in DOH, which is not hardware efficient. The same applies to Ingress PE that
    need to encapsulate topological instructions in CRH and service instructions
    in DOH.

    I think there is no need for defining a new data-plane (CRH) apparently more
    complicated.

    I hope the WG could consider this point in the adoption call.

    Thanks
    Yisong

    -----邮件原件-----
    发件人: ipv6 <[e-mail]> 代表 Bob Hinden
    发送时间: 2020年5月16日 06:14
    收件人: IPv6 List <[e-mail]>
    抄送: Bob Hinden <[e-mail]>
    主题: 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!T3DQGGwlj2rBGOCC0VGYHrukx9elCyFBoc8HzNdgm98N20dLsTIQ13hRzOUyUB8$

    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
    [e-mail]
    Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!T3DQGGwlj2rBGOCC0VGYHrukx9elCyFBoc8HzNdgm98N20dLsTIQ13hRFttl0SA$
    --------------------------------------------------------------------


Juniper Business Use Only