From nobody Wed Oct 12 20:49:43 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072D91297E9; Wed, 12 Oct 2016 20:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-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 DA6e0P_OuqPu; Wed, 12 Oct 2016 20:49:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD591297E8; Wed, 12 Oct 2016 20:49:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYC41938; Thu, 13 Oct 2016 03:49:23 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Oct 2016 04:49:22 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 13 Oct 2016 11:49:15 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? Thread-Index: AdIlBMP6LXv/uE5HT4SrFJTX7KhsFg== Date: Thu, 13 Oct 2016 03:49:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57FF0444.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e35981dbebbe2497649d1c9b37ef0de7 Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: [Bier] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 03:49:29 -0000 Hi all, It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-B= IER (0101, for more details, please see https://tools.ietf.org/html/draft-i= etf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble spa= ce is not enough for the sustainable development of new encapsulation heade= rs which may happen to be encapsulated with an MPLS header. Furthermore, th= e remaining first nibble space available for payload indication is only 011= 1 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-= nsh-10#page-7) unless the NSH is restricted from being transported directly= over the MPLS transport (in this case the NSH is sadly not transport indep= endent anymore).=20 Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet: One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/ht= ml/draft-xu-mpls-payload-protocol-identifier-01). See the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIL | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nib= ble of the MPLS payload has been implicitly used as a protocol id (e.g., in= the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (i= mplicit) protocol id field is not extensible, we introduce a longer (explic= it) protocol id field as per the approach of ESPL.=20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom Label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MP= LS networks); 2) there is no need any more for each new encapsulation heade= r to deal with the notorious first nibble issue associated with MPLS indivi= dually. More specifically, there is no need to intentionally avoid the firs= t nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (I= Pv6). Any comments and suggestions are welcome. Best regards, Xiaohu From nobody Wed Oct 12 22:36:14 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ACE1295CB; Wed, 12 Oct 2016 22:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.onmicrosoft.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 JM5dWSxGQwej; Wed, 12 Oct 2016 22:36:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB76C129409; Wed, 12 Oct 2016 22:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n6dX2p7XdaKqUIIT35BQ6p6OPiaiouYf9eaHt/bWEkg=; b=hwF/GaHkAkh8EmoX5UHjqNnRVY+3mTjJsTHzFbsnXHYs7ld+EuYuXEK7nHwTLizew50idfYc2pGH63tGCrIZQ4p3wtSXPylHBIZ8m911Ale+nR0ZigsnnsLElW1ITbDjfJ1cNiDp+piEzUUtO1tPJMrVwCd2db2p7S95+odA9xE= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2268.eurprd03.prod.outlook.com (10.168.31.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 13 Oct 2016 05:36:02 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0669.011; Thu, 13 Oct 2016 05:36:02 +0000 From: Alexander Vainshtein To: Xuxiaohu , "mpls@ietf.org" Thread-Topic: How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? Thread-Index: AdIlBMP6LXv/uE5HT4SrFJTX7KhsFgADlfLd Date: Thu, 13 Oct 2016 05:36:02 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [25.165.214.132] x-ms-office365-filtering-correlation-id: 045870ff-5fc6-4ae9-a3e4-08d3f32ad1be x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2268; 7:OFWvxL1930kIKM1dCJEG9SNhJj/9931RCldkPcu7yxYWLIR2PLho0sI7hCjG5JYpuc+QmAkciKfv2SoHhxpD+I7leNWfkRQPWeHLKVZgjDnp1AGu7tgdGUGLE5UdiknNW5gMNvYauUiIDw8VHDsEbJ/S7dFPrWvU3uLyAjLeYgUIdHOutHHWOqg4FQKYeekhYs2hgKAsGXCE6XRqSJ1ceNMqaWoNR00V2hnRC+iQpENg5LY0txEVaew0Fzn9NLQnCqk5iLdtDm08fU4QJRknh9Y+u2DgAugLHkHpNUgfa1Z+pHE1QInKftyTbUzFvM4nNxToPRxAdC5jCFH1YnqexrlNQq01tjJfg2zB2Ps2lgk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2268; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2268; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(53754006)(199003)(2950100002)(15974865002)(106356001)(5002640100001)(586003)(5660300001)(2501003)(3846002)(102836003)(105586002)(6116002)(19617315012)(81166006)(97736004)(15975445007)(77096005)(10400500002)(2906002)(5001770100001)(189998001)(4326007)(33656002)(2900100001)(8936002)(7696004)(101416001)(3900700001)(11100500001)(6606003)(7846002)(8676002)(19580405001)(92566002)(9686002)(19580395003)(19625215002)(76576001)(68736007)(122556002)(16236675004)(3660700001)(3280700002)(7736002)(54356999)(76176999)(86362001)(87936001)(74316002)(7906003)(50986999)(19627405001)(81156014)(66066001)(14773001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2268; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 05:36:02.0418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2268 Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [Bier] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 05:36:08 -0000 --_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Xiaohu and all, I respectfully disagree with your statement "the first nibble of the MPLS p= ayload has actually been used as an implicit protocol identifier for some p= ayloads". In the case of PWs the CW (with this first nibble) may be not pre= sent at all, but even when it is present, its first nibble is only used for= disambiguation of the PW packets (so that they cannot be mistakenly treate= d as IPv4 or IPv6 packets by the ECMP mechanisms). My 2c, Sasha ________________________________ From: mpls on behalf of Xuxiaohu Sent: Thursday, October 13, 2016 6:49 AM To: mpls@ietf.org Cc: bier@ietf.org; sfc@ietf.org Subject: [mpls] How to indicate the existence of an explicit protocol field= immediately after the MPLS label stack? Hi all, It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-B= IER (0101, for more details, please see https://tools.ietf.org/html/draft-i= etf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble spa= ce is not enough for the sustainable development of new encapsulation heade= rs which may happen to be encapsulated with an MPLS header. Furthermore, th= e remaining first nibble space available for payload indication is only 011= 1 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-= nsh-10#page-7) unless the NSH is restricted from being transported directly= over the MPLS transport (in this case the NSH is sadly not transport indep= endent anymore). Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet: One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/ht= ml/draft-xu-mpls-payload-protocol-identifier-01). See the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIL | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nib= ble of the MPLS payload has been implicitly used as a protocol id (e.g., in= the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (i= mplicit) protocol id field is not extensible, we introduce a longer (explic= it) protocol id field as per the approach of ESPL. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom Label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MP= LS networks); 2) there is no need any more for each new encapsulation heade= r to deal with the notorious first nibble issue associated with MPLS indivi= dually. More specifically, there is no need to intentionally avoid the firs= t nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (I= Pv6). Any comments and suggestions are welcome. Best regards, Xiaohu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls mpls Info Page - Internet Engineering Task Force www.ietf.org For information about the MPLS working group, see http://www.ietf.org/html.= charters/mpls-charter.html. To see the collection of prior postings to the = list, visit ... --_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Xiaohu and= all,

I respectf= ully disagree with your statement "the first nibble of the MPLS payload has actually been used as an implicit pro= tocol identifier for some payloads". In the case= of PWs the CW (with this first nibble) may be not present at all, but even= when it is present, its first nibble is only used for disambiguation of the PW packets (so that they cannot be = mistakenly treated as IPv4 or IPv6 packets by the ECMP mechanisms).<= /p>


My 2c,

Sasha







From: mpls <mpls-bounc= es@ietf.org> on behalf of Xuxiaohu <xuxiaohu@huawei.com>
Sent: Thursday, October 13, 2016 6:49 AM
To: mpls@ietf.org
Cc: bier@ietf.org; sfc@ietf.org
Subject: [mpls] How to indicate the existence of an explicit protoco= l field immediately after the MPLS label stack?
 
Hi all,

It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-BIER (0101, for more details, ple= ase see https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble space is not enough for the sustainable= development of new encapsulation headers which may happen to be encapsulat= ed with an MPLS header. Furthermore, the remaining first nibble space available for payload indication is only = 0111 due to the NSH specification (htt= ps://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the NSH is restricted from being transported directly over the MPLS= transport (in this case the NSH is sadly not transport independent anymore= ).

Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet:

One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/html/draft-xu-mpls-paylo= ad-protocol-identifier-01). See the following figure:

     0        &= nbsp;          1  &n= bsp;            = ;    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
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |        &= nbsp;        PIL    =             &nb= sp;  | EXP |1|      TTL   &nbs= p;  |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |0 0 0 0|       Rese= rved          |  &nb= sp;     Protocol Type     &nbs= p;  |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |        &= nbsp;           &nbs= p;         Payload   = ;            &n= bsp;          |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nibble of the MPLS payload has been = implicitly used as a protocol id (e.g., in the case where the payload is IP= v4 or IPv6 packet), and since the 4-bit (implicit) protocol id field is not= extensible, we introduce a longer (explicit) protocol id field as per the approach of ESPL.
       0      &= nbsp;            1&n= bsp;            = ;      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
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |      &= nbsp;      Bottom Label    &nb= sp;         | EXP |1|  &n= bsp;   TTL      |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |0 1 1 1|     = ;  Reserved          |&nb= sp;       Protocol Type   &nbs= p;    |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |      &= nbsp;           &nbs= p;           Payload = ;            &n= bsp;            |        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MPLS networks); 2) there is no need = any more for each new encapsulation header to deal with the notorious first= nibble issue associated with MPLS individually. More specifically, there i= s no need to intentionally avoid the first nibble of each new encapsulation header from being 0100 (IPv4) o= r 0110 (IPv6).

Any comments and suggestions are welcome.

Best regards,
Xiaohu

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
www.ietf.org
For information about the MPLS working group, see http://www.ietf.org/html.= charters/mpls-charter.html. To see the collection of prior postings to the = list, visit ...


--_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_-- From nobody Thu Oct 13 05:53:52 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07FB129767; Thu, 13 Oct 2016 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W42XirAnjof6; Thu, 13 Oct 2016 05:53:48 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 5AB0C129764; Thu, 13 Oct 2016 05:53:47 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id x79so138332751lff.0; Thu, 13 Oct 2016 05:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=GKZfT0GIALufJszPw40C9R+f2AZleu0sJpl3XBDOTvE=; b=DnZBzySuLh3F4M6ObhFbNMMY6fhGT/zH8FrMJmX1rWpIc947wjywTtTuYmzzT1gOnn Lmo/eXGV75GVB+GqkZr7Q0sraM8UUcdndrXcnI8iHpNihJKiIt3RaLCAkoDssHOQNtQ+ PFxsK2GmU1f5A5HPm6N835I2AegWTlGhsd1zxUIoxTaZ60k5PVDfQyOJhIEdImwktQrK DaLT1kjXhne8cjhO1vU9pgbP2C8JjgKT6ScT+IXQZIaNSUbMnFOHv+VAJeaIsSdawuF8 ZZALjsBFgIX0QpkRQ2tskjzFy4L/DjENuB/haIuM/Pvoho2tc2jwNe7bedKeLM4Bk5om viQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GKZfT0GIALufJszPw40C9R+f2AZleu0sJpl3XBDOTvE=; b=QDzEUeT+o/uWhwAQTJGxVnfjjyAvrMieIJ23fz38bG2J+ps7dI2Nv395oR/0QdZcMD Wu7tf2p1hZeGwanzlTLJGVEnWxoZ0bJ/sEUHoKqiLpuyJdZAomjKaO3GoQ2cYVLLvOfD yNk5MVcblHDz2c2OwNWIToLyQfwpiLaScF4nQZ4oyitxTkZrzdgPf4ihihJ4iHAweMqE FqwFiTXTekNDlhUXbotc0nNc4bWrI6I/ah5bJDGZEUvGO+BhPjHHLt5iAP1KbiqkT3HQ fJjMRZ3bETbFhOEu87/hKVEoQgBDm1MkIyXMIo6kDTScsyGMQRUhMSFM6OYGwg/uxh+1 r3Dw== X-Gm-Message-State: AA6/9RkI5xVLP+qzUZ0MEFRA+f1G60dT/A0QZEkDezS4sHr1O6Vduvu8dLG0aDVu1D40Bw== X-Received: by 10.25.7.201 with SMTP id 192mr9834694lfh.170.1476363225430; Thu, 13 Oct 2016 05:53:45 -0700 (PDT) Received: from [192.168.2.127] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id r16sm3722391lfe.38.2016.10.13.05.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 05:53:44 -0700 (PDT) To: Alexander Vainshtein , Xuxiaohu , "mpls@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> From: Stewart Bryant Message-ID: <71ee24c7-7702-093f-2595-af18f2539a60@gmail.com> Date: Thu, 13 Oct 2016 13:53:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------584D86D38972B862E24FD4FD" Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [Bier] [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:53:51 -0000 This is a multi-part message in MIME format. --------------584D86D38972B862E24FD4FD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sasha is correct, and I seem to remember a PW system that did meet an Ethernet packet with IPv4 as the first nibble and made such a mistake. You can only use the first nibble as a disambiguator for example to distinguish IPv4 and IPv6 if you have some supplementary information telling you that the packet can only be either type IPv4 or IPv6. Stewart On 13/10/2016 06:36, Alexander Vainshtein wrote: > > Xiaohu and all, > > I respectfully disagree with your statement "*/the first nibble of the > MPLS payload has actually been used as an implicit protocol identifier > for some payloads/*". In the case of PWs the CW (with this first > nibble) may be not present at all, but even when it is present, its > first nibble is only used for disambiguation of the PW packets (so > that they cannot be mistakenly treated as IPv4 or IPv6 packets by the > ECMP mechanisms). > > > My 2c, > > Sasha > > > > > > > > ------------------------------------------------------------------------ > *From:* mpls on behalf of Xuxiaohu > > *Sent:* Thursday, October 13, 2016 6:49 AM > *To:* mpls@ietf.org > *Cc:* bier@ietf.org; sfc@ietf.org > *Subject:* [mpls] How to indicate the existence of an explicit > protocol field immediately after the MPLS label stack? > Hi all, > > It's well-known that the MPLS label stack has no EXPLICIT protocol > identifier field to indicate the protocol type of the MPLS payload. > However, the first nibble of the MPLS payload has actually been used > as an implicit protocol identifier for some payloads, such as IPv4 > (0100), IPv6(0110) and MPLS-BIER (0101, for more details, please see > https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). > Unfortunately, the first nibble space is not enough for the > sustainable development of new encapsulation headers which may happen > to be encapsulated with an MPLS header. Furthermore, the remaining > first nibble space available for payload indication is only 0111 due > to the NSH specification > (https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the > NSH is restricted from being transported directly over the MPLS > transport (in this case the NSH is sadly not transport independent > anymore). > > Hence, it's seem necessary for us to consider the approach of > inserting an EXPLICIT protocol identifier field within the MPLS packet > as early as possible. The following are two possible ways of inserting > an EXPLICIT protocol identifier field within the MPLS packet: > > One is to use an SPL (or even ESPL) as described > (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-01). > See the following figure: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PIL | EXP |1| TTL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Reserved | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Another is to set the first nibble of the 4-octet entry containing the > protocol field to a dedicated value (e.g., 1111), as shown in the > following figure. In this case, there is no need to insert additional > label (s) (i.e., SPL or ESPL) anymore. The logic of the latter > approach is that the first nibble of the MPLS payload has been > implicitly used as a protocol id (e.g., in the case where the payload > is IPv4 or IPv6 packet), and since the 4-bit (implicit) protocol id > field is not extensible, we introduce a longer (explicit) protocol id > field as per the approach of ESPL. > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Bottom Label | EXP |1| TTL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 1 1 1| Reserved | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IMHO, the benefits of introducing an explicit protocol id into the > MPLS packet include but not limited to: 1) provide a sustainable way > of indicating new MPLS payload types without any need of inserting one > additional label indicating the MPLS payloads (e.g., considering how > to transport NSH over MPLS networks); 2) there is no need any more for > each new encapsulation header to deal with the notorious first nibble > issue associated with MPLS individually. More specifically, there is > no need to intentionally avoid the first nibble of each new > encapsulation header from being 0100 (IPv4) or 0110 (IPv6). > > Any comments and suggestions are welcome. > > Best regards, > Xiaohu > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > mpls Info Page - Internet Engineering Task Force > > www.ietf.org > For information about the MPLS working group, see > http://www.ietf.org/html.charters/mpls-charter.html. To see the > collection of prior postings to the list, visit ... > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------584D86D38972B862E24FD4FD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Sasha is correct, and I seem to remember a PW system that did meet an Ethernet packet with IPv4 as the first nibble and made such a mistake.


You can only use the first nibble as a disambiguator for example to distinguish IPv4 and IPv6 if you have some supplementary information telling you that the packet can only be either type IPv4 or IPv6.


Stewart



On 13/10/2016 06:36, Alexander Vainshtein wrote:

Xiaohu and all,

I respectfully disagree with your statement "the first nibble of the MPLS payload has actually been used as an implicit protocol identifier for some payloads". In the case of PWs the CW (with this first nibble) may be not present at all, but even when it is present, its first nibble is only used for disambiguation of the PW packets (so that they cannot be mistakenly treated as IPv4 or IPv6 packets by the ECMP mechanisms).


My 2c,

Sasha







From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu <xuxiaohu@huawei.com>
Sent: Thursday, October 13, 2016 6:49 AM
To: mpls@ietf.org
Cc: bier@ietf.org; sfc@ietf.org
Subject: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack?
 
Hi all,

It's well-known that the MPLS label stack has no EXPLICIT protocol identifier field to indicate the protocol type of the MPLS payload. However, the first nibble of the MPLS payload has actually been used as an implicit protocol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-BIER (0101, for more details, please see https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble space is not enough for the sustainable development of new encapsulation headers which may happen to be encapsulated with an MPLS header. Furthermore, the remaining first nibble space available for payload indication is only 0111 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the NSH is restricted from being transported directly over the MPLS transport (in this case the NSH is sadly not transport independent anymore).

Hence, it's seem necessary for us to consider the approach of inserting an EXPLICIT protocol identifier field within the MPLS packet as early as possible. The following are two possible ways of inserting an EXPLICIT protocol identifier field within the MPLS packet:

One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-01). See the following figure:

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 PIL                   | EXP |1|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0|       Reserved          |        Protocol Type        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Payload                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Another is to set the first nibble of the 4-octet entry containing the protocol field to a dedicated value (e.g., 1111), as shown in the following figure. In this case, there is no need to insert additional label (s) (i.e., SPL or ESPL) anymore. The logic of the latter approach is that the first nibble of the MPLS payload has been implicitly used as a protocol id (e.g., in the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (implicit) protocol id field is not extensible, we introduce a longer (explicit) protocol id field as per the approach of ESPL.
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Bottom Label              | EXP |1|      TTL      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 1 1 1|       Reserved          |        Protocol Type        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              Payload                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IMHO, the benefits of introducing an explicit protocol id into the MPLS packet include but not limited to: 1) provide a sustainable way of indicating new MPLS payload types without any need of inserting one additional label indicating the MPLS payloads (e.g., considering how to transport NSH over MPLS networks); 2) there is no need any more for each new encapsulation header to deal with the notorious first nibble issue associated with MPLS individually. More specifically, there is no need to intentionally avoid the first nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (IPv6).

Any comments and suggestions are welcome.

Best regards,
Xiaohu

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
For information about the MPLS working group, see http://www.ietf.org/html.charters/mpls-charter.html. To see the collection of prior postings to the list, visit ...
 




_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--------------584D86D38972B862E24FD4FD-- From nobody Fri Oct 14 14:51:20 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068F11295CE; Fri, 14 Oct 2016 14:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LJzZrxXEEAAe; Fri, 14 Oct 2016 14:51:17 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 E67F11294E9; Fri, 14 Oct 2016 14:51:16 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id d132so152423912oib.2; Fri, 14 Oct 2016 14:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nfQ4SEcyzzTKF9C/cnIgaViIW0MgWGyJMWGB8g0lBOc=; b=iel0jBX8B2L8kx6kuuEHwcKU1LoZFSYX8VV40MvCE/LCM7uhg+9RinEBoYiIsRADwP Dzs8p2fj8QnkwbSkeT10Px+leHBiDP7kztoiJPBsJK6sstnOwIqaM01EfUgbit+IXVHP c31fr+5ELfObxJeLtRVuS/zvJxWvpPG2F43g7AY4DhZFf7s995TwBtR7kmmPwk1cZXGf aFYrO4wW04GE6LZwBSqhukSwR/tSqpM/gPwghWn2EAWUYMcXbY18gsO6WkjR+Xu4zCeC 0U5+qfZWFY1q1XJLLNPBmOWzwJSIzelZ2gyWae9QKVT9TgPeiEbV6hufjPE6lwO670W1 eG0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nfQ4SEcyzzTKF9C/cnIgaViIW0MgWGyJMWGB8g0lBOc=; b=mj5WMqHLugY6YannCwukMES9z71HhrnA03vwJ6SwR8wHJxnrnlsOlZSx2T/0bKfXo9 T2INlCnFlKqpUsQHaBYLNQvcn5TAp5k5AJqK6c7vTUZcfRGEPw50yOQ0wkgFpnC+ktTc xVNIWFdeTptwo50B0sdZdlZYnmeJSAOaovZN7I0zjXPRxm9D3ficfq6I/0OQHzWcDMCc Vfaw3Y/TWJ9nk2HUkKWbq2J+MsG2pWR/KoSiBMQaIVqVF5sA4u2/0tfqRuEe94xHT/VK FhqJiNg0YDTZtONzeyMAV8k8H7Fm51uMeKWDNdvVlckc5rC3UcwYXKfPeO2ar4Cnj61v hgyQ== X-Gm-Message-State: AA6/9Rnguri5XKmKMChTW0+R+M1FT/GkZ6F3Ewa1xXkzAVqysI6XjUzV3m3TZPW2j1QfPKmO9txjumd414jQtA== X-Received: by 10.157.56.179 with SMTP id p48mr6595591otc.22.1476481876092; Fri, 14 Oct 2016 14:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.49.116 with HTTP; Fri, 14 Oct 2016 14:51:15 -0700 (PDT) In-Reply-To: <147647894042.18668.13940123723027422984.idtracker@ietfa.amsl.com> References: <147647894042.18668.13940123723027422984.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 14 Oct 2016 14:51:15 -0700 Message-ID: To: "rtgwg@ietf.org" , "nvo3@ietf.org" , sfc@ietf.org, bier@ietf.org Content-Type: multipart/alternative; boundary=001a11c05284bdeb89053eda39a8 Archived-At: Subject: [Bier] Fwd: New Version Notification for draft-ooamdt-rtgwg-ooam-header-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 21:51:19 -0000 --001a11c05284bdeb89053eda39a8 Content-Type: text/plain; charset=UTF-8 Dear All, the Common OAM Header draft been updated. Greatly appreciate your comments, questions and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Fri, Oct 14, 2016 at 2:02 PM Subject: New Version Notification for draft-ooamdt-rtgwg-ooam-header-01.txt To: Mach Chen , Li Yizhou , Nagendra Kumar , Ignas Bagdonas , David Mozes , Gregory Mirsky , Erik Nordmark , David Dolson , Deepak Kumar A new version of I-D, draft-ooamdt-rtgwg-ooam-header-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ooamdt-rtgwg-ooam-header Revision: 01 Title: OAM Header for use in Overlay Networks Document date: 2016-10-13 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ooamdt-rtgwg- ooam-header-01.txt Status: https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam- header/ Htmlized: https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam- header-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ooamdt-rtgwg-ooam- header-01 Abstract: This document introduces Overlay OAM Header to be used in overlay networks to de-multiplex Overlay OAM protocols. My email address have changed since the last version. Appreciate your help. Regards, Greg 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. The IETF Secretariat --001a11c05284bdeb89053eda39a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
the Common OAM Header draft been updated. Gr= eatly appreciate your comments, questions and suggestions.

Regards,
Greg

-= --------- Forwarded message ----------
From: <i= nternet-drafts@ietf.org>
Date: Fri, Oct 14, 2016 at 2:02 P= M
Subject: New Version Notification for draft-ooamdt-rtgwg-ooam-header-0= 1.txt
To: Mach Chen <mach.che= n@huawei.com>, Li Yizhou <= liyizhou@huawei.com>, Nagendra Kumar <naikumar@cisco.com>, Ignas Bagdonas <ibagdona@gmail.com>, David Mozes <davidm@mellanox.com>, Gregory Mirsky &l= t;gregimirsky@gmail.com>, E= rik Nordmark <nordmark@acm.org&g= t;, David Dolson <ddolson@sandvi= ne.com>, Deepak Kumar <dekum= ar@cisco.com>



A new version of I-D, draft-ooamdt-rtgwg-ooam-header-01.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ooamdt-rtgwg-ooam-heade= r
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAM Header for use in Overlay Netw= orks
Document date:=C2=A0 2016-10-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ooamdt-= rtgwg-ooam-header-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam-hea= der/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-01 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ooamdt-rtgwg-= ooam-header-01

Abstract:
=C2=A0 =C2=A0This document introduces Overlay OAM Header to be used in over= lay
=C2=A0 =C2=A0networks to de-multiplex Overlay OAM protocols.


My email address have changed since the last version. Appreciate your help.=

Regards,
Greg

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

The IETF Secretariat


--001a11c05284bdeb89053eda39a8-- From nobody Fri Oct 21 16:21:08 2016 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE191294F2; Fri, 21 Oct 2016 16:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709206547.28214.5558881311129450309.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:05 -0700 Archived-At: Cc: bier@ietf.org Subject: [Bier] bier - Requested session has been scheduled for IETF 97 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:05 -0000 Dear Alia Atlas, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bier Session 1 (2:00:00) Monday, Afternoon Session II 1550-1750 Room Name: Studio 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Bit Indexed Explicit Replication Area Name: Routing Area Session Requester: Alia Atlas Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: pim rtgwg detnet homenet Special Requests: Need to sanity check the conflicts with the chairs... --------------------------------------------------------- From nobody Wed Oct 26 14:29:48 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F31295AC for ; Wed, 26 Oct 2016 14:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PV9z9mHVtwi9 for ; Wed, 26 Oct 2016 14:29:45 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 BC2711293F4 for ; Wed, 26 Oct 2016 14:29:45 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q7so10598973qtq.1 for ; Wed, 26 Oct 2016 14:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to; bh=ybCKJNRG8JGkk/9oVOmTdbrz7S4fgVFgNDkCE/bTDfA=; b=Ir1Aewf/FR711pwjUfRgjx39xjsiMTrjvnwYfuIhR8i2p9ztml2oA3z65ACwAdd3hq t41snczy+kPMzBcgsMchqthiYBUnwah/JFhjVWqq8hc+HMwMrVLWcWN3dP28rrc8Nde5 KEQxRx4gaoIVbzO+RlfLGHo9ZI7GzKs+1Md3j0nXMpJTXjlyipMFlqrvh9Rb66CsSp9Q ABsCKD2MCN1kaW09Usp94h7ioDpXN1LqCr2Dj0+9d5f6e+fcdnprSMuYxQ1PIFPr4iYQ Y+WcIOg1vjbXvikhQkWO8wkOxVv1KG0hDSXmEJXMDdItpiL7UG+bi0/YT262QBXNQtXW 7puA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=ybCKJNRG8JGkk/9oVOmTdbrz7S4fgVFgNDkCE/bTDfA=; b=mkOOV6y2IzZeGqdP+rHXWRAAYB58byqlkAMmiIe3mN1ZDlMhm8SWhcMTIOFO1rea/O sL6Qo6iu3DJ65S021WrGwJ4Do7K/JZzUFPHvRjVZtpBSwDkn8pJcmFPTD0EcAIeVPOPf Trg6RlG1pqvWEMOP1TrCB9zV8OBtdwjnsQAXIf3WKwmTkp1iX0g3m1VEkMRzYlQuvJzN uWBmWSiMFslxUi9PCndV8xyDRKlxfiUF+ngg8QaFvgH1Ox6ytU02uTdE0Qa0xhX7dmbO Fwg5Bmplm+ljjrvtyfA3hdVtQ4FWPJfJDwiM5vTVZma+D2qYYqrAEcnYwuiUtoMEXtm9 wNFQ== X-Gm-Message-State: ABUngvczPiNAx4IQmHOpqp8kSSfKB7EoEGLdkaG3a10XJyDwoCFkIXblWjg4xSw3bhxkItjPss0KW2RhG88/0w== X-Received: by 10.200.48.104 with SMTP id g37mr3693481qte.6.1477517384725; Wed, 26 Oct 2016 14:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.53.130 with HTTP; Wed, 26 Oct 2016 14:29:44 -0700 (PDT) From: Greg Shepherd Date: Wed, 26 Oct 2016 14:29:44 -0700 Message-ID: To: "bier@ietf.org" Content-Type: multipart/alternative; boundary=001a1141e26cddbd0f053fcb52cd Archived-At: Subject: [Bier] BIER WG - Call for agenda items, Seoul, South Korea X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gjshep@gmail.com List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 21:29:47 -0000 --001a1141e26cddbd0f053fcb52cd Content-Type: text/plain; charset=UTF-8 *IETF 97, Seoul, South Korea (UTC +9)November 13-18, 2016 * Please send your request for BIER WG agenda items. Include name, draft link and/or title, and the amount of time you would like. Cheers, Greg (chairs) --001a1141e26cddbd0f053fcb52cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IETF 97, Seoul, South Korea (UTC +9)
Nove= mber 13-18, 2016

Please send your reque= st for BIER WG agenda items. Include name, draft link and/or title, and the= amount of time you would like.

Cheers,
= Greg (chairs)
--001a1141e26cddbd0f053fcb52cd-- From nobody Fri Oct 28 06:58:30 2016 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9A6126B6D; Fri, 28 Oct 2016 06:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147766310523.25003.8113093888674102669.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 06:58:25 -0700 Archived-At: Cc: bier@ietf.org Subject: [Bier] I-D Action: draft-ietf-bier-architecture-05.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:58:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication of the IETF. Title : Multicast using Bit Index Explicit Replication Authors : IJsbrand Wijnands Eric C. Rosen Andrew Dolganow Tony Przygienda Sam K Aldrin Filename : draft-ietf-bier-architecture-05.txt Pages : 36 Date : 2016-10-28 Abstract: This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bier-architecture-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-architecture-05 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/ From nobody Mon Oct 31 20:02:26 2016 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B89129ACC; Mon, 31 Oct 2016 20:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TcrWaw9uw88R; Mon, 31 Oct 2016 20:02:22 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 C234A129B45; Mon, 31 Oct 2016 20:02:19 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id i127so266018618oia.2; Mon, 31 Oct 2016 20:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=PizQ1wZj6YOQ7DhosVogHMzRbx+yTgM5yMBlZqD0sqI=; b=ol1Jt/mirRMtYESPjRacu7Kjyf+p/0PNuuki+lQmOR4d0fKdhZVJCkRUCaUEECmNS/ As0foqQbP+oR8a9fbdP8VlwFGK1MOguB18DzStarDgOvFzHCEnxmtrP9yRuWaAJw5x9d EVvwZEbLLKnGOGYfaTXFRokpXlGqVB4W+p5axVEHKN7CuPezapLRK0mQSNvlVTVACpKj ZC+53rqpmAgHHbXuXFoVuVKZ/yu63UDvBNH7zqaBXDtF1Xf2/kAf3oiJvL5IQTmDVFhK Iw7ptcVOFW6KY8s/6YrzMoYjomSAzoVdfZfR7nUzqhtKeJpgykEqEBMMQY4jgf7yMH7H PhrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PizQ1wZj6YOQ7DhosVogHMzRbx+yTgM5yMBlZqD0sqI=; b=Lzuq9OOBhQs1oZ165HEmfZzHH4MQ1OTO1Ew6iBDR9LDDdA6aW1usJJ/rrD1VdzuLAL Wt7OjqdIc8BrDca/LuiDTXhg+fOZ7a+iac27e68515rbKpVf3tRkDAjQnEFGC4s9vM7P 3yfEPRTM2FDuliY7c9c/tpF++4xEX8bJqqaN7sx63mjUhPOVID3JKSOnlE/okqF3rOpy f697PugP6cgjv9yX/o3CmDVAmR2DqmAgobziVwd6yC1yDg0hGe5v6Cki0gGjcOufF485 vOaSFBbLsl23ShAE+q2LQxG/NY0Rsb6vpU9unvJdkdPHBx+qljnllUrjtSSGMZws26NX RuhQ== X-Gm-Message-State: ABUngveHs7ty4v9oP2+1BTNcmuRbVdeS2Bd4WbOgS9eeSSW3McfrXnjHK/T9Oe/7YrzJ7nG2HKI2hIgSkj0jSA== X-Received: by 10.157.14.228 with SMTP id 91mr21817832otj.133.1477969338462; Mon, 31 Oct 2016 20:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.49.116 with HTTP; Mon, 31 Oct 2016 20:02:18 -0700 (PDT) From: Greg Mirsky Date: Mon, 31 Oct 2016 20:02:18 -0700 Message-ID: To: bier-chairs@ietf.org, bier@ietf.org Content-Type: multipart/alternative; boundary=001a113719106879870540348d0b Archived-At: Subject: [Bier] Slot request X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 03:02:24 -0000 --001a113719106879870540348d0b Content-Type: text/plain; charset=UTF-8 Dear WG Chairs, et. al, authors of draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv have updated these draft and would appreciate a presentation slot: - OAM Header for use in Overlay Networks draft-ooamdt-rtgwg-ooam-header Greg Mirsky 10 min - On-demand Continuity Check (CC) and Connectivity Verification (CV) for Overlay Networks draft-ooamdt-rtgwg-demand-cc-cv Greg Mirsky 10 min It would be great if both presentations can be scheduled in one session as one block. Regards, Greg --001a113719106879870540348d0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear WG Chairs, et. al,
authors of=C2=A0draft-ooamdt-rtgwg-ooam-header and=C2=A0draft-ooamdt-rtgwg-demand-cc-cv have up= dated these draft and would appreciate a presentation slot:
    <= li>OAM Header for use in Over= lay Networks =C2=A0=C2=A0draft-ooamdt-rtgwg-ooam-header =C2=A0 Greg Mirsky =C2=A0 =C2=A010 = min
  • On-de= mand Continuity Check (CC) and Connectivity Verification (CV) for Overlay N= etworks =C2=A0=C2=A0d= raft-ooamdt-rtgwg-demand-cc-cv =C2=A0 Greg Mirsky =C2=A0 =C2=A0 10 min=
It would be great if b= oth presentations can be scheduled in one session as one block.

Rega= rds,
Greg
--001a113719106879870540348d0b--