Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

"Adrian Farrel" <> Tue, 22 January 2019 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A953F13105D; Tue, 22 Jan 2019 10:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lhRQKRfw0b5J; Tue, 22 Jan 2019 10:19:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62DF01286D9; Tue, 22 Jan 2019 10:19:44 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x0MIJggx023415; Tue, 22 Jan 2019 18:19:42 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 2BFA622044; Tue, 22 Jan 2019 18:19:42 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 1641E22042; Tue, 22 Jan 2019 18:19:42 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x0MIJflZ024143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jan 2019 18:19:41 GMT
From: Adrian Farrel <>
To: "'Henderickx, Wim (Nokia - BE/Antwerp)'" <>,,
References: <>
In-Reply-To: <>
Date: Tue, 22 Jan 2019 18:19:40 -0000
Organization: Old Dog Consulting
Message-ID: <00cf01d4b27f$0ab7b7b0$20272710$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01D4B27F.0ABC2480"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMGSngX4++GO8giiogbOC3dn/GkuqNYZ3Ig
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--31.953-10.0-31-10
X-imss-scan-details: No--31.953-10.0-31-10
X-TMASE-Result: 10--31.953300-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbOYAh37ZsBDCttKJDdalq/VrKNt7ipQiY+TU uEDszCu7ugxJKBEPbQHqxqLx+EoXGunOhl8kAE665fkjIw2ui08fXzVgO0hVquOxOq7LQlGLevl vErwzcNyQ872Kcdt6jLPzJWDPXIJQAfk3D/rwI0yvPooS+PUQchmyTBaqiJvc/9oVA0v0ZVoPnf z4SmEvcuSfpKQzBLxduTPCpciewZ7LWSLUGd00k+0/o+/4D7DzzSnbR3NwN1xMSusaE6IwuK9ma oRLZKo9AdWX+YOlswkmNpzri1sedyqMIRQddN3SCFaAixm5eU9A8JZETQujwqXJ9vMysD/CYu1t e8SLOKFwbQxGhptmosMFMt6lEd044QsjLzswuv57sw7yO+Y9LHMXU68zDdlAmP1Huhu1yDLUwuv LGfOD0gwm/J+J+/QkQnHwhG8MvJp5X0FJZbmEpp1U1lojafr/f2g6KJZtxl3hbnAZMqQsq02gDB BR+dScQIndpKdk4fC6nQkqDk1cltxYxKkBD+eswTQdkTBfjnzY3zRC9wXsuEjG+/xKusQWISiZa O1t9RFEoAtBTsaC/3527pxPe/i4GZz9JOZkDC0+SjKwBmBxL5jrl5obQZYfRy6sAa90Jf7FSyQw vMOeMYcmNm03lsQovPid/JgRJ7R/qdLDwaCcF+9VsdrlGzy3Q6/DFZugyt27/NQTVI1I+cbK+pu 0ZYwRBHVm0xh58VY8LuP+bOkMWt3jF2fVcPdzDB+ErBr0bANar2Wff4KSIfufvd3T2+v30tDG1n xaYAD/+eSpHPvf+nPdcTGDah5Fe6k6FRH8ATyeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg4QViJlGwPJ1+FlDmr6T7z8eq7Js0iiXNblngrQ++TLREpj02QXPHBcQUF3hIW5n8w==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Jan 2019 18:20:03 -0000

Hey Wim,


Thanks for (not 😉 ) reading.


Yes, MPLS-SFC was certainly in mind, but we wrote the initial document only for NSH, and so the document is named for that and fully scoped for that.


I believe that draft-ietf-mpls-sfc-encapsulation is “only” an interface encapsulation of NSH. Thus if we support NSH (we do, and we describe it), and if we support identifying the interface “tunnel type” (we do because this is a standard extension for BGP and we talk about it in the draft), I think we have that document covered.


I haven’t read draft-guichard-spring-nsh-s (yet), but it might be a bit premature to include an applicability discussion of that work before it is adopted by SPRING.


BUT, I certainly have no objection to someone (you?) starting one or more applicability documents.





Oh! John just sent almost the same email!


From: BESS <> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: 22 January 2019 17:00
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane


I need to get into more details, but the current draft is written with draft-ietf-mpls-sfc-04 dataplane in mind. I believe that the draft can be useful with other dataplanes like: draft-ietf-mpls-sfc-encapsulation and draft-guichard-spring-nsh-s

So I would like the see the BGP control plane extensions here to become more generic to support multiple data-planes options. I need to go in more detail, but from high level this is my feedback here. I don’t want to stop/block this work as I believe this is a very useful proposal, but if we make it more generic it can serve a bigger purpose.


So I would like to see the following:

1.	Protocol draft
2.	Use case drafts for the different data planes.


My 2 cents.


From: BESS < <> > on behalf of Stephane Litkowski < <> >
Date: Monday, 21 January 2019 at 08:06
To: " <> " < <> >
Cc: " <> " < <> >
Subject: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane


Hello Working Group,


This email starts a three weeks Working Group Last Call on  draft-ietf-bess-nsh-bgp-control-plane [1]. 


This poll runs until *the 4th of February*.


We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.


We have several IPRs already disclosed.


If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


We are also polling for any existing implementation as per [2]. 


    Thank you,

    Stephane & Matthew







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.