Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt

mohamed.boucadair@orange.com Thu, 07 January 2021 15:44 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409493A1233 for <sfc@ietfa.amsl.com>; Thu, 7 Jan 2021 07:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 rjSxmdGxEkvN for <sfc@ietfa.amsl.com>; Thu, 7 Jan 2021 07:44:08 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA543A1219 for <sfc@ietf.org>; Thu, 7 Jan 2021 07:44:08 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4DBVs260zBz7tpf; Thu, 7 Jan 2021 16:44:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610034246; bh=AvjRs/N0IT8gPxHKrco2F4oE8hj8gMZjxJImhNxPKi4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=xcNE0vos0iycpjUoWf1AQHiFBq8/xUhoY99NpTHCMQkGUN3VxXqpke31TP51DbRnH cOsvfnzb7eOUBjvgMbnVpyKH0+X/L9HyTQYNtFvUhch7lugsrt/V6Z0PM3ql7r/OUg 26i9lEvUIwHn786Y7dMlYTiD0aZpTmYxPlFAxjJc1cSgqivI8aAa+2amwQqybI4a0f wvAC64IeeYZKDv6lKa62WmGEbfbgILcW6bov59YlEAyei88pl7W79W0Gs+myW6OxC7 JL7RVFX5/DxuZx4MSrXCgnPWP3s3NtJMXrYnyF/gFon0RCtRw9uQm/9IdoVieGzmzh Ma5JbqGKL9Ndw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4DBVs2537zz5vNb; Thu, 7 Jan 2021 16:44:06 +0100 (CET)
From: mohamed.boucadair@orange.com
To: "wei.yuehua@zte.com.cn" <wei.yuehua@zte.com.cn>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt
Thread-Index: AQHW4wqD7qag88yWTk2AMJ0Z/ObcK6ocUGAQ
Date: Thu, 07 Jan 2021 15:44:06 +0000
Message-ID: <29299_1610034246_5FF72C46_29299_105_1_787AE7BB302AE849A7480A190F8B9330315B467E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: 202005211105230895521@zte.com.cn, 9e4f630b-c298-c9ca-883b-efe75a081e18@joelhalpern.com <202101051028348005635@zte.com.cn>
In-Reply-To: <202101051028348005635@zte.com.cn>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315B467EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/EzUIaqUEuaRzZfpB3IWc1ysCN_A>
Subject: Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 15:44:11 -0000

Hi Wei,

Thank you for sharing this updated version.

One quick comment: Please remove this line from Section 7 as that value is already assigned to the service identifier TLV.

| 0x00  |             Reserved             | This document |

I still do think that more text is needed to understand the usage of the various attributes.

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de wei.yuehua@zte.com.cn
Envoyé : mardi 5 janvier 2021 03:29
À : sfc@ietf.org
Objet : [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt


Dear chairs and SFCers,

I uploaded ver04 of “Network Service Header Metadata Type 2 Variable-Length Context Headers” draft.

I updated the draft according to the comments received from the SFC mailing list.



Your comments are always welcome and helpful.



And I would like to ask the WG for the consideration of the WGLC.

Thank you!

------

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining WG of the IETF.

        Title           : Network Service Header Metadata Type 2 Variable-Length Context Headers
        Authors         : Yuehua (Corona) Wei
                          Uri Elzur
                          Sumandra Majee
                          Carlos Pignataro
    Filename        : draft-ietf-sfc-nsh-tlv-04.txt
    Pages           : 13
    Date            : 2021-01-04

Abstract:
   This draft describes Network Service Header (NSH) Metadata (MD) Type
   2 variable-length context headers that can be used within a service
   function path.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-04
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc





Yuehua Wei

Best Regards,

M: +86 13851460269 E: wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn>


原始邮件
发件人:JoelM.Halpern
收件人:Carlos Pignataro (cpignata);
抄送人:sfc@ietf.org<mailto:sfc@ietf.org>;
日 期 :2020年05月27日 23:40
主 题 :Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt
Thank you for your extensive work on this Carlos.

Working group...   Does anyone else have comments?  This is another
milestone we need to get done.

Yours,
Joel

On 5/27/2020 10:33 AM, Carlos Pignataro (cpignata) wrote:
> Dear Wei,
>
> Thanks for addressing the vast majority of my comments from two full
> reviews, and incorporating all my textual suggestions.
>
> Some still remain:
>
> 1.  s/byte/octet/g —> there are still 4 instances of “byte”.
>
> 2. Content Type
>
> 4.3.  Content Type
>
> I’d recommend removing this one. It does not seem to be adequately defined.
>
> 3. Note ID
>
>                       Figure 6: Ingress Network Node ID
>
> Why is the length fixed to 8? I understand a 32-bit number can be a most
> common Node ID, but what if a 128-bit number wants to be used?
>
> I’d allow either of two lengths.
>
> 4. Flow ID
>
> 4.6.  Flow ID
>
>     Flow ID provides a representation of the flow.  Akin, but not
>     identical to the usage described in [RFC6437].
>
>
> This still needs to be more appropriately defined. I would replace:
>
>     Flow ID provides a representation of the flow.  Akin, but not
>     identical to the usage described in [RFC6437].
>
> With at least
>
>     The Flow ID provides a field in the NSH MD Type 2 to label
>     packets belonging to the same flow.  Absence of this field, or
>     a value of zero denotes that packets have not been labeled.
>
>
>
> 5. IANA
>
>     This document defines the following new values (Table 1)in the
>     Network Service Header (NSH) metadata context Type registry:
>
>
> There’s a space missing in the first line.
>
> More importantly though, I would add two Experimentation values in Table
> 1. I would also reserve the value of 0x00.
>
>
> 6. IANA Citation.
>
> I think the URI for IANA should be without the file part:
> https://www.iana.org/assignments/nsh/#optional-variable-length-metadata-types
>
>
> Lastly, here is some of the text proposed for some section descriptions:
>
> Forwarding Context
>
>     The forwarding context used for segregation and forwarding scope can
>     Take several forms depending on the network environment. For example,
> VXLAN/VXLAN-GPE VNID, VRF identification, and VLAN. This context
> header carries this network-based forwarding context.
>
> Tenant Identifier
>
>     Tenant identification is often used for segregation within a multi-
>     tenant environment.  Orchestration system-generated tenant IDs are an
>     example of such data. This context header carries both the format and
>     value of the Tenant identifier.
>
> Content Type
>
> // Remove
> // I believe this needs further thinking on the namespace fo Content
> Types, could even be draft-penno-sfc-appid-05
>
> Ingress Network Node Information
>
>     This context header identifies the ingress network node.
>
> Ingress Network Interface Information
>
>     This context header identifies the ingress network interface.
>
> Flow ID
>
>     The Flow ID provides a field in the NSH MD Type 2 to label
>     packets belonging to the same flow.  Absence of this field, or
>     a value of zero denotes that packets have not been labeled.
>
>
> Thanks!
>
> Carlos.
>
>
>> 2020/05/20 午後11:05、wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn>
>> <mailto:wei.yuehua@zte.com.cn>のメール:
>>
>> Hi folks,
>>
>> I just uploaded a new version of NSH metadata 2 variable-length
>> context headers.
>>
>> The updates resolved the comments received from the mailing list.
>>
>> One important technical modification is splitting of the Ingress
>> Network context header to two context headers (in 4.4 and 4.5) which
>> is proposed by Carlos, Med and Greg.
>>
>> Please keep reviewing and give your comments.
>>
>> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>
>>
>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03..txt
>> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>
>>
>>
>> In addition,  I would as the  WG to consider changing the length
>> of Tenant Identifier context header ( in 4.2) to "var", so that TT and
>> IANA sub-registry are not needed.
>>
>>
>> Thank you for your kind support.
>>
>>
>> *Best Regards,*
>> *魏月华 Corona Wei*
>>
>> *ZTE Corporation*
>>
>> M: +86 13851460269 E: wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn> <mailto:wei.yuehua@zte.com.cn>
>>
>>
>> 原始邮件
>> *发件人:*internet-drafts@ietf.org<mailto:*internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org>
>> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org<mailto:internet-drafts@ietf.org %3cmailto:internet-drafts@ietf.org>>>
>> *收件人:*i-d-announce@ietf.org<mailto:*i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org>
>> <i-d-announce@ietf.org <mailto:i-d-announce@ietf.org<mailto:i-d-announce@ietf.org %3cmailto:i-d-announce@ietf.org>>>;
>> *抄送人:*sfc@ietf.org<mailto:*sfc@ietf.org> <mailto:sfc@ietf.org> <sfc@ietf.org
<mailto:sfc@ietf.org %0b>>> <mailto:sfc@ietf.org>>;
>> *日 期 :*2020年05月21日 08:40
>> *主 题 :**[sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt*
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Service Function Chaining WG of the IETF.
>>
>>         Title           : Network Service Header Metadata Type 2 Variable-Length Context Headers
>>         Authors         : Yuehua (Corona) Wei
>>                           Uri Elzur
>>                           Sumandra Majee
>>     Filename        : draft-ietf-sfc-nsh-tlv-03.txt
>>     Pages           : 12
>>     Date            : 2020-05-20
>>
>> Abstract:
>>    This draft describes Network Service Header (NSH) Metadata (MD) Type
>>    2 variable-length context headers that can be used within a service
>>    function path.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org<mailto:sfc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>> _______________________________________________
>> sfc mailing list
>> sfc@ietf.org<mailto:sfc@ietf.org> <mailto:sfc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sfc
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc
>

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.