Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Fri, 10 April 2020 15:49 UTC
Return-Path: <cpignata@cisco.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 55C513A017E for <sfc@ietfa.amsl.com>; Fri, 10 Apr 2020 08:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mZ1Ru+rE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RbygpiRB
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 YtvI1vKCAkZK for <sfc@ietfa.amsl.com>; Fri, 10 Apr 2020 08:49:12 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DF13A0147 for <sfc@ietf.org>; Fri, 10 Apr 2020 08:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67579; q=dns/txt; s=iport; t=1586533752; x=1587743352; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zX/PUE5gvwAVNLl1bDUrfAp4CiSPqMTzpBgKt3IobqA=; b=mZ1Ru+rEVI4NkmMbgRzh0KK016htkfhGApmAORuWoWQQFPkqWPutFkz0 eW59kWneYosy7UNnxcC0BJXHimqmUQeH64l+DMlgnPEEbFtXCpf449dCE u6fLWzNBNxIbZmLAB5E7cjB9fK7yjNVDDbA0fS5Z5gOX1xa2Ja/ZZp+9L 0=;
IronPort-PHdr: 9a23:Ds9drhbHjrXnQJ4+obFg0qD/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8Kavhdy01Gs1eXXdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQBACPlJBe/51dJa1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gSUvJCwFbFggBAsqCoQSg0YDimqCOphGgUKBEANQBAoBAQEMAQEYAQoKAgQBAYEvAYMUAheBeSQ4EwIDAQELAQEFAQEBAgEFBG2FVgELhXECAQMBARARHQEBJQcLAQ8CAQYCEiYBBgMCAgIlCxQDDgIEDgUigwQBgX5NAy4BDpQDkGcCgTmIYnWBMoJ/AQEFgTYCDkFBgnAYgg4DBoE4jDQagUE/gREnDBCCTT6CZwEBAgEBGIEUARIBBxkYFoJlMoIskRWGCIpDjnJ7CoI/h1Ylj0wdglCIQ5ELhGCKaYkuj1qDOwIEAgQFAg4BAQWBaSJncHAVGiEqAYI+PhIYDZEiCQMFEoNQhRSFQXQCgSeNXgEwXwEB
X-IronPort-AV: E=Sophos;i="5.72,367,1580774400"; d="scan'208,217";a="476814461"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Apr 2020 15:49:11 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 03AFnAGQ031870 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Apr 2020 15:49:10 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Apr 2020 10:49:10 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Apr 2020 10:49:10 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 10 Apr 2020 11:49:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XNLQ3ffawBPxvc+svwUw2MZOj2FNnFpviAG087H2vzvKAE8YKXua/aAzBNMbDniY3nDO6N/GW86mRFvEk6vLKbjYd790nc3UqH8GwJk6CGwxR6y3rr7Anop/rD9/YKygNGS8mKe9kCkWJXef3m9XVYD5X4LU3J7wqzVk6rY6L3ars1uE+WSCn2dlen6kpXaBVEsOKE+kKJG4GzeR0yX4HP7yhKfJOuMuw9BxmaS6E35AIUt5u7A75D5bEsPQ9Hqmn1F1mdDJ9QtNiZbjHECCVEyAAhZ8bwekiC0OD6CIaqd+NNiUKfgDLneBcW26OilW/uzgIJPvzwdpAy1PxB/QAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zX/PUE5gvwAVNLl1bDUrfAp4CiSPqMTzpBgKt3IobqA=; b=hYb0AIAiLg+2TE4tnok3lSUOwCQPYv92jJ/+lo8Q/0KiyislU+IBo6G+TuEKnO3ui0+732LZLb0QSOm6ieFXISC4w8pzc6A5VuBDiwWPongSOma10GmyfCCszHnTH2PKiz4jL8WfBBj5aF6ku9J6A1dwMZw78RYKTL+ltDdmEcS57Tvh2xxZ+hZ74DL4mx7I49eNCdDv5p43ojLQzhmiW33IExj37veDHXGYTroCmt4D6FdBbpHGb0Etq89yR5ez7rcj5LiWh46GKTSg7XEhD8X1HTuqylEzrJUZxa4c0swsGO0yTh1FTRdVxhH9egF2OOqDRe7MBa8jC+7jBhY15g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zX/PUE5gvwAVNLl1bDUrfAp4CiSPqMTzpBgKt3IobqA=; b=RbygpiRBr53MdhPim+14hojNlyHa7Vcb3KFV4a5kNozjK6dSbNOJuGFA96MphwhOQpd+JRHWF2kBb203QRqSC4aux+Mfnf9ycFFEWH9y7y4yE69u5qv0lya5LocAiJxP4TkPuz/GfjxsH6bz3ioIwzw9CX2P8NRWdi0OAHRTYec=
Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3666.namprd11.prod.outlook.com (2603:10b6:408:8c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Fri, 10 Apr 2020 15:49:08 +0000
Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74%7]) with mapi id 15.20.2878.018; Fri, 10 Apr 2020 15:49:08 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "wei.yuehua@zte.com.cn" <wei.yuehua@zte.com.cn>
CC: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs
Thread-Index: AQHWD0+RoXgAdJ3KdUKRBoMAgof5Fg==
Date: Fri, 10 Apr 2020 15:49:07 +0000
Message-ID: <7750B74D-0539-4034-987B-5262E24BBE80@cisco.com>
References: <D26A88B6-BE99-4BEA-9739-9DEADAB4D196@cisco.com,> <639BDC8B-13B0-48CF-B4C1-ACB834DEC4A5@cisco.com> <202004101047428213142@zte.com.cn>
In-Reply-To: <202004101047428213142@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [108.203.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 61aee630-ba01-4125-148d-08d7dd66b480
x-ms-traffictypediagnostic: BN8PR11MB3666:
x-microsoft-antispam-prvs: <BN8PR11MB3666C31E29E2CD03840B37A4C7DE0@BN8PR11MB3666.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0369E8196C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(6506007)(76116006)(66556008)(86362001)(8936002)(966005)(8676002)(6916009)(316002)(64756008)(478600001)(81156014)(36756003)(71200400001)(33656002)(66446008)(66476007)(186003)(2616005)(5660300002)(26005)(6486002)(4326008)(6512007)(66946007)(2906002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Mlg/lmDPinc/RbK5btdqN5eX8QCx5AocTlCTvkfZH9RuPNwxs49cYHYWUt+9zvEGtos4li5TED0K8h5J10wFfG9y8s9qJNBeR4qzlnt9smH7PIOmyBL60IsZL8k5Wdz2p4gG4o/t2iaCCEucqK4Ifz0aMau22S29ReWsa+JWM+Njvg5vOHMYiAj3CCRCmY6B+7zmhcvN8x93siTow4MzkYqodkF1zijIdV59pSMQC2Z4h5TzjDVpO97zrmTSoBv7j0h6KNK9g7HL0k4Zw0hNaUE4Vyas3deMvN4FhLzzmV4vIMFRhkC8SKECYIMyJY5i9Nl9tc06mS+4lvy/DDYZpg/T8vbmQ+7Mz7uMT6XJAhmc7iuc7HWbDK3bkcsa/br5Vs48TvCRDhTsp6nXObvHF7dp3pRTKvE9EkJox1LV1QwgY8sMSPOXOpgUNdlg58UDVeTY0eeC0InCPsB+5WPioUYrD/bIaQa/tStHDdIB5qLZ2stuz4bTzyVAupIzvvN3J2L9EZWXqexiQbSs87O5Bg==
x-ms-exchange-antispam-messagedata: GEeZQNWyNxVDCoIxfUeazJh2mQ1hCaooTWU2K+GZ9c6r/FOSw3TK8RJb1W4lRymeB2/MXw5ZYPN93NkjAEP8KXgTR9s4nO2IYeQPAqpo+SBZYd+K463xeEAF3ygX27HFnLN5dzvXt6qF/kncx/NizA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_7750B74D05394034987B5262E24BBE80ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 61aee630-ba01-4125-148d-08d7dd66b480
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2020 15:49:07.9210 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TESLYw+GL+FPMaZ7HJqXkWpfwYJcRrd6/09NjAPkA01dC5kzBfc1CGZURP8cURV+smDPs2EF2/ijM0c4g6vF9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3666
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/7XuJjbNdFrx14DGyvcXb6c0WhTo>
Subject: Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs
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: Fri, 10 Apr 2020 15:49:15 -0000
Hi! Yes, it was deleted at https://tools.ietf.org/rfcdiff?url2=draft-quinn-sfc-nsh-tlv-03.txt In fact, in that revision, Subscriber/user Information / Host ID also was removed and those move forward as draft-sarikaya-sfc-hostid-serviceheader-00.txt then into draft-ietf-sfc-serviceid-header. The question I still have is: what is “ Content Type”? Without a proper definition, should it be removed/ Thanks, Carlos. 2020/04/09 午後10:47、wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn>のメール: Hi Carlos, SFCers, After backtracking the past version of this draft, I found that Application ID was deleted since draft-quinn-sfc-nsh-tlv-03 Best Regards, 魏月华 Corona Wei M: +86 13851460269 E: wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn> 原始邮件 发件人:CarlosPignataro(cpignata) <cpignata=40cisco.com@dmarc.ietf.org<mailto:cpignata=40cisco.com@dmarc.ietf.org>> 收件人:魏月华00019655; 抄送人:sfc@ietf.org<mailto:sfc@ietf.org> <sfc@ietf.org<mailto:sfc@ietf.org>>; 日 期 :2020年04月09日 00:44 主 题 :Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc Thank you for the response to those 3 items. In regards to your question #3, the challenge is that the current section is underspecified. Without syntax, semantics, and registry, interoperability sounds not possible. https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-02#section-4.3 I was suggesting that penno-sfc-appid is a potentially complete superset of this functionality. Are there other proposals on how the “Cotent Type” should look like? Thanks, Carlos. 2020/04/07 午後10:43、wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn>のメール: Hi Carlos, SFCers, 1, Thank you for the work to make alignment of this draft to RFC8300! 2, I agree with you and Greg that it would make sense to split 4.4. Ingress Network Information into two elements, one for Node ID, one for Interface. 3, About 4.3. Content Type If it refers to an Application ID: <https://tools.ietf.org/html/draft-penno-sfc-appid-05> <https://tools.ietf.org/html/draft-penno-sfc-appid-05> https://tools.ietf.org/html/draft-penno-sfc-appid-05 . draft-penno-sfc-appid-05 <https://tools.ietf.org/html/draft-penno-sfc-appid-05> is an indivisual draft and it Expires: February 16, 2017 Shall we keep 4.3 or delete it? Thank you ! Best Regards, 魏月华 Corona Wei M: +86 13851460269 E: wei.yuehua@zte.com.cn<mailto:wei.yuehua@zte.com.cn> 发件人:CarlosPignataro(cpignata) <cpignata=40cisco.com@dmarc.ietf.org<mailto:cpignata=40cisco.com@dmarc.ietf.org>> 收件人:魏月华00019655;sfc@ietf.org<mailto:sfc@ietf.org> <sfc@ietf.org<mailto:sfc@ietf.org>>; 日 期 :2020年03月31日 12:04 主 题 :[sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service Header TLVs _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc Hi, Wei, SFCers, I hope this email finds you well! I thought it would be useful to send not only specific comments but also text proposals on this draft https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/?include_text=1 Here they go: Network Service Header TLVs draft-ietf-sfc-nsh-tlv-02 The title is a bit of a misnomer. It’s not NSH TLVs. This should be titled “Network Service Header Metadata Type 2 Variable-Length Context Headers” Abstract This draft describes Network Service Header (NSH) MD-Type 2 metadata TLVs that can be used within a service function path. —> "This draft describes Network Service Header (NSH) Metadata (MD) Type 2 variable-length context headers that can be used within a service function path (SFP).” 1. Introduction Network Service Header (NSH) [RFC8300] is the Service Function Chaining (SFC) encapsulation protocol used to create Service Function Chains. This reads redundant. Instead: Network Service Header (NSH) [RFC8300] is the Service Function Chaining (SFC) encapsulation protocol required to support the SFC architecture. As such, NSH provides two key elements: 1. Service Function Path identification 2. Metadata This is inconsistent with RC 8300, which says: The NSH is composed of the following elements: 1. Service Function Path identification. 2. Indication of location within a Service Function Path. 3. Optional, per-packet metadata (fixed-length or variable). [RFC8300] further defines two metadata formats (MD Types): 1 and 2. MD Type 1 defines fixed length, 16 bytes-long metadata, whereas MD Type 2 defines a variable-length TLV format for metadata. This draft defines some common TLVs for use with NSH MD Type 2. s/bytes/octets/ Also, strictly, MD Type 2 does not use “TLVs”. It uses “MD Class, MD Type, Length, Value”. As such I recommend removing all mentions of TLV. “ variable-length TLV format” —> “ variable-length metadata format" 2.1. Terminology Add: "This document uses the terminology defined in the SFC Architecture [RFC 7665] and the Network Service Header [RFC 8300]”. 3. NSH Type 2 Format This is “NSH MD Type 2” 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TTL missing, should be: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Metadata Class (MD Class): Defines the scope of the Type field to provide a hierarchical namespace. Type - Indicates the explicit type of metadata being carried. The value is one from the Network Service Header (NSH) TLV Type [...] Please remove this as it is from RFC 8300. 4. NSH Type 2 TLVs Should be “NSH MD Type 2 Context Headers” 4.1. Forwarding Context This TLV carries a network-centric forwarding context, used for segregation and forwarding scope. Forwarding context can take several forms depending on the network environment. Commonly used data includes VXLAN/VXLAN- GPE VNID, VRF identification or VLAN. Extraneous space in VXLAN- GPE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class = 0x0000 | Type = 0x01 |U| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CT | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tenant ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First, I recommend for now change all the Types to TBAs. For example 0x01 to TBA1. Note this would otherwise collide with other documents being advanced. I was thinking about this format, and the proposal from Greg Mirsky to do away from CT and instead use the length. I thought that was a good idea. However, on second thoughts, and in looking at the values defined: 0x0 - 24 bits-long VXLAN/LISP virtual network identifier (VNI) 0x1 - 32 bits-long MPLS VPN label 0x2 - VLAN * An MPLS Label is actually 20 bits. * A VLAN identifier (VID) is 12 bits. Neither of those can be expressed as a Length in octets. So, we need a CT Field. However, change to: 0x0 - 24-bits VXLAN/LISP virtual network identifier (VNI) 0x1 - 20-bits MPLS VPN label 0x2 - 12-bit VLAN identifier 4.3. Content Type Provides explicit information about the content being carried, for example, type of video or content value for billing purposes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class = 0x0000 | Type = 0x03 |U| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Content Type This does not seem to be adequately defined. What is Content Type: 0xCAFECACA? In fact I wonder if what wants to be defined here is an Application ID: https://tools.ietf.org/html/draft-penno-sfc-appid-05 4.4. Ingress Network Information This data identifies the ingress network node, and, if required, ingress interface. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class = 0x0000 | Type = 0x04 |U| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Interface/Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Ingress Network Information As per previous comment from Greg Mirsky, I agree it would make sense to split this into two elements, one from Node ID, one for Interface. 7. IANA Considerations IANA is requested to create a new "Network Service Header (NSH) TLV Type" registry according to Table 1. These are not “TLV Types”. They are "Network Service Header (NSH) MD Type 2 context header metadata types” for example. This document defines the following new values (Table 2) in the Network Service Header (NSH) TLV Type registry: This should have “TBAs”. And these need subsections: * Context Type (CT) * Tenant Type (TT) * Group Type (GT) * URI Type Here’s some text: 7.1. Context Type IANA is requested to create and maintain the “ Forwarding Context Variable Length Context Header, Context Type” registry, with the following initial allocation: 0x0 - 24-bits VXLAN/LISP virtual network identifier (VNI) 0x1 - 20-bits MPLS VPN label 0x2 - 12-bit VLAN identifier 0x3-0xE - Unassigned 0xF - Reserved 7.2. Tenant Identifier IANA is requested to create and maintain the “ Tenant Identifier Variable Length Context Header, Tenant Type” registry, with the following initial allocation: * 0x0 - 32 bits-long Tenant ID * 0x1 - 64 bits-long Tenant ID 7.3. Group Type IANA is requested to create and maintain the "Source and/or Destination Groups Context Header, Group Type” registry, with the following initial allocation: * 0x0 - Reserved * 0x1 - Group Based Policy (GBP) end point group (EPG) * 0x2-0xE - Unassigned * 0xF - Reserved Thanks! Carlos.
- [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Service… Carlos Pignataro (cpignata)
- Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Ser… wei.yuehua
- Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Ser… Carlos Pignataro (cpignata)
- Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Ser… wei.yuehua
- Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Ser… Carlos Pignataro (cpignata)
- Re: [sfc] draft-ietf-sfc-nsh-tlv-02 - Network Ser… mohamed.boucadair