Re: [bess] (Action required from Author)Re: Time to gather WG document status update

2019-01-28 Thread Jeffrey (Zhaohui) Zhang
Somehow I did not get this reminder and the original email. Or maybe I just 
somehow delete them by accident.

Anyway sorry for the late response. Some update for the following:


  1.  draft-ietf-bess-evpn-irb-mcast

We recently submitted a new revision to revive the expired revision and also 
made a small textual change. We believe we’re ready to move to the next step 
(quality review and WGLC).


  1.  draft-ietf-bess-mvpn-evpn-aggregation-label

We’re ready to move to the next step (quality review and WGLC). There was a 
long discussion with Jingrong at the poll for IANA early allocation. I hope I 
did address the concerns (not just for the early allocation).


  1.  draft-ietf-bess-mvpn-msdp-sa-interoperation

We are ready for WGLC. There were good discussions at PIM WG when it was first 
brought up then it has been quiet in both WGs, even with a prod. That should 
not be viewed as lack of interest. It’s a simple and necessary feature missed 
in the original RFC6514.


  1.  draft-ietf-bess-mvpn-fast-failover

I reviewed as shepherd and provided comments. The authors have responded some 
time ago but I have not got a chance to follow up. I’ll get onto it soon.

Thanks.
Jeffrey




From: "Mankamana Mishra (mankamis)" 
mailto:manka...@cisco.com>>
Date: Monday, January 21, 2019 at 8:46 PM
To: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>, 
"draft-ietf-bess-evpn-inter-subnet-forwarding.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-inter-subnet-forwarding.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-irb-mcast.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-irb-mcast.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-na-flags.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-na-flags.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-per-mcast-flow-df-election.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-per-mcast-flow-df-election.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-pref-df.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-pref-df.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-vpls-seamless-integ.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-vpls-seamless-integ.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-virtual-eth-segment.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-virtual-eth-segment.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-yang.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-yang.auth...@ietf.org>>,
 
"draft-ietf-bess-l2vpn-yang.auth...@ietf.org"
 
mailto:draft-ietf-bess-l2vpn-yang.auth...@ietf.org>>,
 
"draft-ietf-bess-l3vpn-yang.auth...@ietf.org"
 
mailto:draft-ietf-bess-l3vpn-yang.auth...@ietf.org>>,
 
"draft-ietf-bess-mvpn-evpn-aggregation-label.auth...@ietf.org"
 
mailto:draft-ietf-bess-mvpn-evpn-aggregation-label.auth...@ietf.org>>,
 
"draft-ietf-bess-mvpn-fast-failover.auth...@ietf.org"
 
mailto:draft-ietf-bess-mvpn-fast-failover.auth...@ietf.org>>,
 
"draft-ietf-bess-service-chaining.auth...@ietf.org"
 
mailto:draft-ietf-bess-service-chaining.auth...@ietf.org>>,
 
"draft-ietf-bess-nsh-bgp-control-plane.auth...@ietf.org"
 
mailto:draft-ietf-bess-nsh-bgp-control-plane.auth...@ietf.org>>,
 
"draft-ietf-bess-datacenter-gateway.auth...@ietf.org"
 
mailto:draft-ietf-bess-datacenter-gateway.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-fast-df-recovery.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-fast-df-recovery.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org>>,
 
"draft-ietf-bess-evpn-vpws-fxc.auth...@ietf.org"
 
mailto:draft-ietf-bess-evpn-vpws-fxc.auth...@ietf.org>>,
 
"draft-ietf-bess-mvpn-msdp-sa-interoperation.auth...@ietf.org"
 
mailto:draft-i

[bess] I-D Action: draft-ietf-bess-mvpn-msdp-sa-interoperation-02.txt

2019-01-28 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : MVPN and MSDP SA Interoperation
Authors : Zhaohui Zhang
  Lenny Giuliano
Filename: draft-ietf-bess-mvpn-msdp-sa-interoperation-02.txt
Pages   : 6
Date: 2019-01-28

Abstract:
   This document specifies the procedures for interoperation between
   MVPN Source Active routes and customer MSDP Source Active routes,
   which is useful for MVPN provider networks offering services to
   customers with an existing MSDP infrastructure.  Without the
   procedures described in this document, VPN-specific MSDP sessions are
   required among the PEs that are customer MSDP peers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-msdp-sa-interoperation-02
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-msdp-sa-interoperation-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-msdp-sa-interoperation-02


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/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


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

2019-01-28 Thread Andrew G. Malis
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  wrote:

> Andy,
>
>
>
> We’ll add it to the next revision.  Thanks for your help.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Andrew G. Malis 
> *Sent:* Sunday, January 27, 2019 11:48 AM
> *To:* John E Drake 
> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) ;
> 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,
>
>
>
> 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  wrote:
>
> Andy,
>
>
>
> That sounds right.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Andrew G. Malis 
> *Sent:* Friday, January 25, 2019 6:32 PM
> *To:* John E Drake 
> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) ;
> 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  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  *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  on behalf of Stephane Litkowski <
> stephane.litkow...@orange.com>
> *Date: *Monday, 21 January 2019 at 08:06
> *To: *"bess@ietf.org" 
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *[bess] WGLC, IPR and implementa

Re: [bess] Poll to progress draft-ietf-bess-evpn-bum-procedure-updates without implementation

2019-01-28 Thread stephane.litkowski
Hi WG,

We haven't received any concern about progressing this document without an 
implementation.
We will proceed accordingly.

Brgds,


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, January 22, 2019 07:19
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: [bess] Poll to progress draft-ietf-bess-evpn-bum-procedure-updates 
without implementation

Hi,

We have now cleared the IPR poll for this draft and it is ready to progress.. 
We do not have implementations yet (some are in roadmap).
Based on our implementation policy, we should not progress the draft. However 
we have "draft-ietf-bess-evpn-optimized-ir" which has a normative reference to 
draft-ietf-bess-evpn-bum-procedure-updates. draft-ietf-bess-evpn-optimized-ir 
is already submitted to IESG.

We, chairs, would like to know if the WG agrees to progress 
draft-ietf-bess-evpn-bum-procedure-updates without an implementation to help 
the publication of draft-ietf-bess-evpn-optimized-ir.

Feel free to raise any concern.

This poll runs until January 28th.

Brgds,

Stephane



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, January 08, 2019 14:29
To: LITKOWSKI Stephane OBS/OINIS; bess@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates

Hi WG,

This poll is now ended but we are missing some replies for the IPR poll.
We also haven't heard about an implementation. If there is an implementation, 
please let us know.

We will move forward after clearing this.

Brgds,

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, December 17, 2018 13:50
To: bess@ietf.org
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-bum-procedure-updates


Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-bum-procedure-updates [1]. The poll period is longer than 
usual due to the coming vacation period.



This poll runs until *the 7th of January*.



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.



There is currently no IPR 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-evpn-bum-procedure-updates/



[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


_



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.

_



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 b

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

2019-01-28 Thread John E Drake
Andy,

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

Yours Irrespectively,

John

From: Andrew G. Malis 
Sent: Sunday, January 27, 2019 11:48 AM
To: John E Drake 
Cc: Henderickx, Wim (Nokia - BE/Antwerp) ; 
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,

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 
mailto:jdr...@juniper.net>> wrote:
Andy,

That sounds right.

Yours Irrespectively,

John

From: Andrew G. Malis mailto:agma...@gmail.com>>
Sent: Friday, January 25, 2019 6:32 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) 
mailto: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 
mailto: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 mailto: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 mailto:bess-boun...@ietf.org>> on behalf of 
Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>
Date: Monday, 21 January 2019 at 08:06
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto: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