John,

Thanks for confirming, that makes me very comfortable with the readability
of your draft, seeing as I was able to get it right the first time. :-)

I'd like to request the addition of the following text (or similar, feel
free to edit for readability and/or correctness), after which I'll be happy
to support publication of the draft.


7.8 Support for MPLS-Encapsulated NSH Packets

[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC packets
using the NSH over an MPLS transport network. Signaling MPLS encapsulation
of SFC packets using the NSH is also supported by this document by using
the "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10
(representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], and
also using the "SFP Traversal With MPLS Label Stack TLV" and the "SPI/SI
Representation sub-TLV" with bit 0 set and bit 1 cleared.


BTW, draft-ietf-mpls-sfc-encapsulation has already been submitted to the
IESG for publication, so adding the reference won't add any delay to this
draft.

Thanks again,
Andy


On Sun, Jan 27, 2019 at 10:19 AM John E Drake <jdr...@juniper.net> wrote:

> Andy,
>
>
>
> That sounds right.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Andrew G. Malis <agma...@gmail.com>
> *Sent:* Friday, January 25, 2019 6:32 PM
> *To:* John E Drake <jdr...@juniper.net>
> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderi...@nokia.com>;
> stephane.litkow...@orange.com; bess@ietf.org; bess-cha...@ietf.org
> *Subject:* Re: [bess] WGLC, IPR and implementation poll for
> draft-ietf-bess-nsh-bgp-control-plane
>
>
>
> 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; bess@ietf.org
> *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: *"bess@ietf.org" <bess@ietf.org>
> *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 [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
>
>
>
>     [1]
> 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=>
>
>
>
>     [2]
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=oYcwBjL--0blSjAlaEP-SVq5qXfHoCzSMppCMhCT2p0&s=tAznFgXAw8OBCrtIIFACFKoe5t9xToGpzusDMDV2oH0&e=>
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to