John, So, in order to support draft-ietf-mpls-sfc-encapsulation, looking at draft-ietf-idr-tunnel-encaps, you would use the value 10 from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, and also from your draft use the SFP Traversal With MPLS Label Stack TLV and the SPI/SI Representation sub-TLV with bit 0 set and bit 1 cleared? I just want to make sure I correctly read the details.
Thanks, Andy On Tue, Jan 22, 2019 at 1:15 PM John E Drake <jdr...@juniper.net> wrote: > Wim, > > > > The subject draft was designed w/ NSH in mind. We added an MPLS > representation of the NSH later, which is the subject of the first draft > you referenced, below. > > > > The way the subject draft is written, the representation of the NSH and > the type of transport tunnel can change on a hop-by-hop basis at the > discretion of the selected next-hop SFF. This is through the use of the > encapsulation attribute, which gives us a very open-ended framework in > which to work. > > > > I think the latter two drafts you referenced, below, are actually > supported already but what needs to be written down is exactly what an SFF > needs to advertise in the encapsulation attribute in order to support > them. > > > > I would be happy to work on this w/ anyone else who is interested. > > > > Yours Irrespectively, > > > > John > > > > *From:* BESS <bess-boun...@ietf.org> *On Behalf Of * Henderickx, Wim > (Nokia - BE/Antwerp) > *Sent:* Tuesday, January 22, 2019 12:00 PM > *To:* stephane.litkow...@orange.com; email@example.com > *Cc:* bess-cha...@ietf.org > *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 <bess-boun...@ietf.org> on behalf of Stephane Litkowski < > stephane.litkow...@orange.com> > *Date: *Monday, 21 January 2019 at 08:06 > *To: *"firstname.lastname@example.org" <email@example.com> > *Cc: *"bess-cha...@ietf.org" <bess-cha...@ietf.org> > *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 . > > > > 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 . > > > > Thank you, > > Stephane & Matthew > > > >  > https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dnsh-2Dbgp-2Dcontrol-2Dplane_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NmtJTnm15eI5V8pM4BEFevbruNYPMxijWj6csDXLze8&s=TfgMeOz6kzVSiGyw-h1RMGo9QIYi6K9bz8AcyCd3BNI&e=> > > > >  > https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bess_cG3X1tTqb-5FvPC4rg56SEdkjqDpw&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=NmtJTnm15eI5V8pM4BEFevbruNYPMxijWj6csDXLze8&s=hHwZCKH4zzsnENDFhTn86H9rP-vyWW-Wux-hC7pP6BE&e=> > > > > > > _________________________________________________________________________________________________________________________ > > > > 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. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess