Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 27 May 2020 15:39 UTC

Return-Path: <jmh@joelhalpern.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 6D6403A03FF for <sfc@ietfa.amsl.com>; Wed, 27 May 2020 08:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 uajxhy4bsZxK for <sfc@ietfa.amsl.com>; Wed, 27 May 2020 08:39:38 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1ECD63A0F46 for <sfc@ietf.org>; Wed, 27 May 2020 08:39:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49XFPk05Yjz6GD7v; Wed, 27 May 2020 08:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590593978; bh=pM4Obm/QmqfK80ZbJUYOHowm7guVU46v79eKmewMT9s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nAi/i5FqVk4cubhKPIZy7/hhkhJCYAyaSYS49lYmdXyUTQ0fOzhMcDAsqcCC0vhos 7pg4qaRlA0K9Z7psj479AbczsHyCmtlPrbLdPVrfVnx2a2zNO5B6sC1hR8/57xGjsz brlHj5z+EbOUolJA2RUM0OL9+DFFCEyIzjSMr0G4=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 49XFPj2Tt6z6G8nc; Wed, 27 May 2020 08:39:37 -0700 (PDT)
To: "Carlos Pignataro (cpignata)" <cpignata=40cisco.com@dmarc.ietf.org>
Cc: "sfc@ietf.org" <sfc@ietf.org>
References: <202005211105230895521@zte.com.cn> <C638D5AE-DBCE-4210-B8E3-3D95147A7043@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <9e4f630b-c298-c9ca-883b-efe75a081e18@joelhalpern.com>
Date: Wed, 27 May 2020 11:39:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <C638D5AE-DBCE-4210-B8E3-3D95147A7043@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/SsG54QfL-LsTOGIFEciAlbCnJ8A>
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.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: Wed, 27 May 2020 15:39:41 -0000

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>のメール:
>>
>> 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>
>>
>>
>> 原始邮件
>> *发件人:*internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> 
>> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>> *收件人:*i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> 
>> <i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>;
>> *抄送人:*sfc@ietf.org <mailto:sfc@ietf.org> <sfc@ietf.org 
>> <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
>> 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
> https://www.ietf.org/mailman/listinfo/sfc
>