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

[<[e-mail]>]

Hi,

The WGLC has ended.
A new revision of the draft is required based on the discussions.

Authors,

Please publish the new revision, so we can proceed to the next step.

Brgds,


From: Andrew G. Malis [mailto:[e-mail]]
Sent: Monday, January 28, 2019 15:37
To: John E Drake
Cc: Henderickx, Wim (Nokia - BE/Antwerp); LITKOWSKI Stephane OBS/OINIS; [e-mail]; [e-mail]
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

John,

Thanks, much appreciated.

And for Stephane and Matthew, seeing as I just contributed some text, I'm not aware of any IPR associated with this draft.

Cheers,
Andy


On Mon, Jan 28, 2019 at 8:07 AM John E Drake <[e-mail]<mailto:[e-mail]>> wrote:
Andy,

We’ll add it to the next revision.  Thanks for your help.

Yours Irrespectively,

John

From: Andrew G. Malis <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, January 27, 2019 11:48 AM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

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 <[e-mail]<mailto:[e-mail]>> wrote:
Andy,

That sounds right.

Yours Irrespectively,

John

From: Andrew G. Malis <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 25, 2019 6:32 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Tuesday, January 22, 2019 12:00 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Stephane Litkowski <[e-mail]<mailto:[e-mail]>>
Date: Monday, 21 January 2019 at 08:06
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
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=>

_________________________________________________________________________________________________________________________

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.