Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6C9120041 for ; Sun, 5 May 2019 18:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaF-TlvIjp6y for ; Sun, 5 May 2019 18:19:16 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE1212004A for ; Sun, 5 May 2019 18:19:14 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id p19so3317456qkm.10 for ; Sun, 05 May 2019 18:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kEK+tepO/nGxltqxBt65i608PKU1/hU4ZJok2NAaV3E=; b=RwbXM2Bw8XY3SwE+hX7BP8Pb3tNsttjIC8+36dBw6IQFoV2qxz7Wi7mKOZoI8X9IEc QButQrzWQ/fc8DHoadWH6143lZ2hDKNDq0oWQoVJkda6nSCDg0tvEgL/YdRWJ1x0JEf/ ay913am3bd4F8VgBt1V1q++Vo8YNbPRciEoLKhR5Zuqe60xUMqL1ld5YvjJJveS5/WIT WbA9gYm0j78oyNtGvJbAdgpI8uEKnHbTiPUAjX2qoyMLzagNZ9cIcf00jCsOna3h0+mw 69Jg1D7HtltMDyGXn3w1yA0FBzNNyc42da8sD2W8GPZSimeBNqLX/k+cwA+sm8k2m7Go zVzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kEK+tepO/nGxltqxBt65i608PKU1/hU4ZJok2NAaV3E=; b=d01bMuqsHbbxMNLxsTzWkm71/oqN6pO4WgoPRX63BqbeCgYIgNLxfVaczbMI5g15PU UhZSDaB68JCNzgmwFVwAo7oa8nMsrWmoG0InzxN1t/m87DoOqfVnFdq43VU/f5Eudx+m 9zz/p3FiIhKVGaqe8lRKyxy9CHvQh4/VzCDsgTnwaNA0UMpkF9miR3SGzfvGZYExTSLM EmeFX91pigQY/nGVRfCQlsEW2fZS9cUI3jxgNPsPANEPMJ9FSivCb3KxNmCovb24nO57 1/4PyWby2fWYIgvOgHPuzNV63MSaxzStclym+RF/upkcexN1/e7mdnvKq4W68ZPyrGoM /clg== X-Gm-Message-State: APjAAAVAk/v9cJrHCYV3fSGPNNieKHrS3+3IgXG7qAvllZXUMLLfyGHT QMFGBFLvjz2PrvCERRtlcizvLhIjgpFmsJYD7Olvhw== X-Google-Smtp-Source: APXvYqyRQYTK9pmIRT/PK8XHksee5Y9hcRcLjquyeLVbpbodbR/U/atKYADkJKDTGCr8aaMJhOR8OADmlE3Lx4XOqlw= X-Received: by 2002:a37:6c84:: with SMTP id h126mr18456311qkc.168.1557105553184; Sun, 05 May 2019 18:19:13 -0700 (PDT) MIME-Version: 1.0 References: <16253F7987E4F346823E305D08F9115AAB88504C@nkgeml514-mbx.china.huawei.com> In-Reply-To: <16253F7987E4F346823E305D08F9115AAB88504C@nkgeml514-mbx.china.huawei.com> From: Tom Herbert Date: Sun, 5 May 2019 18:19:02 -0700 Message-ID: Subject: Re: SRv6 Network Programming: ENH = 59 To: Xiejingrong Cc: Ron Bonica , SPRING WG , 6man Content-Type: multipart/alternative; boundary="000000000000602fce05882de3c4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 01:19:18 -0000 --000000000000602fce05882de3c4 Content-Type: text/plain; charset="UTF-8" On Sun, May 5, 2019, 6:15 PM Xiejingrong wrote: > Hi Tom, > > > > Number 97 is a choice but it has 2 bytes wasting. > Jingrong, To the contrary, those two bytes are critical, they maintain proper alignment of network and transport layers. Ask the SPARC engineers about how much fun it is to deal with unaligned network headers! ;-) Tom > > Jingrong > > > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Tom Herbert > *Sent:* Monday, May 06, 2019 9:11 AM > *To:* Ron Bonica > *Cc:* SPRING WG ; 6man > *Subject:* Re: SRv6 Network Programming: ENH = 59 > > > > > > On Sun, May 5, 2019, 5:47 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Folks, > > According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, > when processing the End.DX2 SID, the Next Header must be equal to 59. > Otherwise, the packet will be dropped. > > In the words of the draft, "We conveniently reuse the next-header value 59 > allocated to IPv6 No Next Header [RFC8200]. When the SID corresponds to > function End.DX2 and the Next-Header value is 59, we know that an Ethernet > frame is in the payload without any further header." > > According to Section 4.7 RFC 8200, " The value 59 in the Next Header field > of an IPv6 header or any extension header indicates that there is nothing > following that header. If the Payload Length field of the IPv6 header > indicates the presence of octets past the end of a header whose Next Header > field contains 59, those octets must be ignored and passed on unchanged if > the packet is forwarded." > > Does the WG think that it is a good idea to reuse the Next Header value > 59? Or would it be better to allocate a new Next Header value that > represents Ethernet? > > > > Tom, > > > > There's already ETHERIP number (97). Why not use that? > > > > Tom > > > > > Ron > > > Juniper Internal > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --000000000000602fce05882de3c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 5, 2019, 6:15 PM Xiejingrong <xiejingrong@huawei.com> wrote:

Hi Tom,<= /span>

=C2=A0

Number 97 is a choice = but it has 2 bytes wasting.

=
Jingrong,


To the contrary, those two bytes are critic= al, they maintain proper alignment of network and transport layers. Ask the= SPARC engineers about how much fun it is to deal with unaligned network he= aders! ;-)

Tom

=C2=A0

Jingrong=

=C2=A0

From: = ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Monday, May 06, 2019 9:11 AM
To: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org<= /a>>
Cc: SPRING WG <spring@ietf.org>; 6man <ipv6@ietf.org> Subject: Re: SRv6 Network Programming: ENH =3D 59

=C2=A0

= =C2=A0

On Sun, May 5, 2019, 5:47 PM Ro= n Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote= :

Folks,

According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, = when processing the End.DX2 SID, the Next Header must be equal to 59. Other= wise, the packet will be dropped.

In the words of the draft, "We conveniently reuse the next-header valu= e 59 allocated to IPv6 No Next Header [RFC8200].=C2=A0 When the SID corresp= onds to function End.DX2 and the Next-Header value is 59, we know that an E= thernet frame is in the payload without any further header."

According to Section 4.7 RFC 8200, " The value 59 in the Next Header f= ield of an IPv6 header or any=C2=A0 extension header indicates that there i= s nothing following that header.=C2=A0 If the Payload Length field of the I= Pv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must= be ignored and passed on unchanged if the packet is forwarded."

Does the WG think that it is a good idea to reuse the Next Header value 59?= Or would it be better to allocate a new Next Header value that represents = Ethernet?

=C2=A0

Tom,

=C2=A0

There's already ETHERIP num= ber (97). Why not use that?

=C2=A0

Tom

=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ron


Juniper Internal

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

--000000000000602fce05882de3c4--