[spring] Proposed text for discussion//RE: About the upper layer header processing in RFC8754(SRH)

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Mon, 15 June 2020 15:00 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD33A0DE8; Mon, 15 Jun 2020 08:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dbyyAkxmm3dp; Mon, 15 Jun 2020 08:00:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFC23A0E02; Mon, 15 Jun 2020 08:00:17 -0700 (PDT)
Received: from lhreml711-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 606C32DBB846518D28AC; Mon, 15 Jun 2020 16:00:15 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml711-chm.china.huawei.com (10.201.108.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 15 Jun 2020 16:00:14 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 15 Jun 2020 23:00:12 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 15 Jun 2020 23:00:12 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Aijun Wang <wangaj3@chinatelecom.cn>, "ipv6@ietf.org" <ipv6@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Proposed text for discussion//RE: About the upper layer header processing in RFC8754(SRH)
Thread-Index: AdZDJgR+FkGiV2l6QFymNyWDfWPKTA==
Date: Mon, 15 Jun 2020 15:00:11 +0000
Message-ID: <e3daff55ef464297a0d9db3e8770d3d4@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.209.178]
Content-Type: multipart/alternative; boundary="_000_e3daff55ef464297a0d9db3e8770d3d4huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/c3r5Gm_g2zGx2y5gEDlinHnYJVs>
Subject: [spring] Proposed text for discussion//RE: About the upper layer header processing in RFC8754(SRH)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 15:00:22 -0000

Hi, WGs,
****Following is the Proposed text for updating Section 4.3.1.2 of RFC8754. ****

   The next header in the packet in S03 of section 4.3.1.1 of the
  document could be an IPv6 extension header or an IPv6 Upper-layer
   header.  Herein named Following-header for short in this section.

   If the Following-header is a designated upper-layer header(DULH) of
   the SRv6 SID, the packet should be forwarded according to the
   Designated-Forwarding Method (DFM) of the SRv6 SID.  The designated
   upper-layer header of an SRv6 SID should be specified by each type of
   SRv6 SID.  An SRv6 SID MAY has zero, one, or more than one designated
   upper-layer headers.  For example:

   1) an SRv6 SID may expect IPv4 header as its designated upper-layer
   header.

   2) an SRv6 SID may expect either IPv6 header or IPv4 header as its
   designated upper-layer header.

   3) an SRv6 SID may expect Ethernet header as its designated upper-
   layer header.

   4) an SRv6 SID may not expect any header as its designated upper-
   layer header.

   The Designated-Forwarding method of the SRv6 SID should be specified
   by each type of SRv6 SID if the designated upper-layer header of the
   SRv6 SID is not NULL.

   If the Following-header is not the designated upper-layer header of
   the SRv6 SID, and the Following-header is allowed by local
   configuration (e.g.  ICMPv6), then process the upper-layer header.

   If the Following-header is not the designated upper-layer header of
   the SRv6 SID, and the Following-header is not allowed by local
   configuration (e.g.  Default), then the packet should be discarded,
   and an ICMPv6 error message should be sent to the Source Address of
   the packet.  The ICMPv6 error message has an Error code (4) "SR
   Upper-layer Header Error", pointer set to the offset of the upper-
   layer header.

   The following pseudocode illustrates the above process:

      IF (Following-header is the DULH of the SRv6 SID) {
        Execute the Designated-Forwarding Method of the SRv6 SID.
      }
      ELSE IF (Following-header is allowed by local configuration) {
        Process the Upper-layer header.
      }
      ELSE {
        Send an ICMP parameter problem message to the Source Address and
        discard the packet.  Error code (4) "SR Upper-layer
        Header Error", pointer set to the offset of the upper-layer
        header.
      }

**** End of the proposed text ****

Your thoughts?

Thanks
Jingrong

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, June 15, 2020 10:29 AM
To: Aijun Wang <wangaj3@chinatelecom.cn>; ipv6@ietf.org; spring@ietf.org
Subject: RE: About the upper layer header processing in RFC8754(SRH)

Hi Aijun,
Very good catch!
I think the 4.3.1.2 need to be updated !
I would like to propose some text (maybe later today) for RFC8754 4.3.1.2, as well as some other text in SRv6-PGM section 4.1 (and some related sections) I have observed  about the Upper-layer processing for further discussion.

Thanks
Jingrong


From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, June 15, 2020 10:14 AM
To: ipv6@ietf.org<mailto:ipv6@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>
Subject: About the upper layer header processing in RFC8754(SRH)

Hi, Folks:
RFC8754(SRH) section 4.3.1.2(https://tools..ietf.org/html/rfc8754#section-4.3.1.2<https://tools.ietf.org/html/rfc8754#section-4.3.1.2>) describes the process of upper layer header as the followings:
IF (Upper-layer Header is IPv4 or IPv6) and
       local configuration permits {
     Perform IPv6 decapsulation
     Resubmit the decapsulated packet to the IPv4 or IPv6 module
   }
   ELSE {
   ......
}
And in network programming draft section 9.1(https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-15#section-9.1), one new Ethernet Next Header Type(143) is proposed.

Although the detail process of this new next header are described in the network program draft,  does it need to update the section 4.3.1.2 of RFC8754 to reflect the process of new header type(143)?

Best Regards

Aijun Wang
China Telecom