Re: [bess] Suresh Krishnan's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Suresh Krishnan]

Hi Ali,
  The suggested changes look good to me.

Thanks
Suresh

> On Jan 22, 2019, at 4:20 AM, Ali Sajassi (sajassi)  wrote:
> 
> Suresh,
> Thanks for your review and your comments. Please refer to my replies below 
> marked with "AS>".
> 
> On 1/9/19, 8:03 PM, "Suresh Krishnan"  wrote:
> 
>Suresh Krishnan has entered the following ballot position for
>draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection
> 
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
> 
> 
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/
> 
> 
> 
>--
>COMMENT:
>--
> 
>* Section 3.3 MAC Mobility
> 
>The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, 
> for a
>lack of a better term, "not seamless" to me. While only using EVPN a MAC 
> that
>has moved will get propagated out without *initiating* any sort of BUM 
> traffic
>itself as described Section 15 of RFC7432. If I understand this document
>correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it
>will be blackholed until it initiates BUM traffic which is not the case 
> when
>the MAC moves between EVPN PEs. Did I get this right? If so, I think this
>limitation needs to be highlighted a bit more prominently.
> 
>  AS>  Section 3.3 describes two MAC move scenarios: move from EVPN PE to VPLS 
> PE (1st para) and move from VPLS PE to EVPN PE (2nd para). In the first 
> scenario, it says that if the moved MAC address doesn't initiate any BUM 
> traffic (it only initiates known unicast traffic), then there can be 
> black-holing for both EVPN and VPLS PEs. However, for the 2nd scenario, the 
> black-holing can happen only for VPLS PEs. To clarify this point further, I 
> added a sentence to each of the paragraph. 
> 1st para: Such black-holing happens for traffic destined to the moved C-MAC 
> from both EVPN and VPLS PEs.
> 2nd para: Such black-holing happens for traffic destined to the moved C-MAC 
> for only VPLS PEs but not for EVPN PEs.
> 
> Cheers,
> Ali
> 
> 

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

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

[Xiejingrong]

Hi Jeffrey,

The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and 
then switch to the (S,G) tunnel.

To quote RFC6513 section 7.1.1
   The decision to bind a particular C-flow (designated as (C-S,C-G)) to
   a particular P-tunnel, or to switch a particular C-flow to a
   particular P-tunnel, is always made by the PE that is to transmit the
   C-flow onto the P-tunnel.

   When a C-flow is switched from one P-tunnel to another, the purpose
   of running a switch-over timer is to minimize packet loss without
   introducing packet duplication.

Jingrong

-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 
Sent: Saturday, January 12, 2019 3:29 AM
To: Xiejingrong ; 
draft-ietf-bess-mvpn-expl-tr...@ietf.org
Cc: bess@ietf.org
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D 
Action: draft-ietf-bess-mvpn-expl-track-13.txt

Jingrong,

> It is determined by the sender site PE whether to steer the flow of (C-S, 
> C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE 
> should work correctly in any case.

Why would the sender PE send into (*, *) when there is a match for (S,G)?

Jeffrey

> -Original Message-
> From: Xiejingrong [mailto:xiejingr...@huawei.com]
> Sent: Thursday, January 10, 2019 11:10 PM
> To: draft-ietf-bess-mvpn-expl-tr...@ietf.org
> Cc: bess@ietf.org
> Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action:
> draft-ietf-bess-mvpn-expl-track-13.txt
> 
> Hi,
> 
> I have a question regarding RFC6625 and this draft, since this draft 
> is based on the RFC6625.
> 
> In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data
> Reception":
> It defined the rules for Finding the matched S-PMSI A-D route for a 
> (C-S,C-G) state on a receiver site PE.
> It seems to me that, the receiver site PE will respond only to the 
> *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 'reception 
> state' only for the 'Matched' S-PMSI A-D route.
> But it is not true for an inclusive-selective relation between S-PMSI 
> A-D (*,*) and S-PMSI A-D(S,G).
> Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site 
> PE with a
> (C-S,C-G) state should keep its join state on both the S-PMSI A-D 
> (*,*) and S- PMSI A-D(S,G), and setup the 'reception state' on both 
> the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel.
> It is determined by the sender site PE whether to steer the flow of 
> (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the 
> receiver site PE should work correctly in any case.
> 
> My question:
> Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception'
> include *one or many* S-PMSI A-D routes ?
> Is it a problem that can affect this draft ?
> 
> Thanks
> Jingrong.
> 
> 
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet- 
> dra...@ietf.org
> Sent: Thursday, November 29, 2018 12:27 AM
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
> 
> 
> 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   : Explicit Tracking with Wild Card Routes in 
> Multicast VPN
> Authors : Andrew Dolganow
>   Jayant Kotalwar
>   Eric C. Rosen
>   Zhaohui Zhang
>   Filename: draft-ietf-bess-mvpn-expl-track-13.txt
>   Pages   : 21
>   Date: 2018-11-28
> 
> Abstract:
>The Multicast VPN (MVPN) specifications provide procedures to allow a
>multicast ingress node to invoke "explicit tracking" for a multicast
>flow or set of flows, thus learning the egress nodes for that flow or
>set of flows.  However, the specifications are not completely clear
>about how the explicit tracking procedures work in certain scenarios.
>This document provides the necessary clarifications.  It also
>specifies a new, optimized explicit tracking procedure.  This new
>procedure allows an ingress node, by sending a single message, to
>request explicit tracking of each of a set of flows, where the set of
>flows is specified using a wildcard mechanism.  This document updates
>RFCs 6514, 6625, 7524, 7582, and 7900.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-
> 2Dtrack_=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&
> m=DmUVKSwroxeVL5S2E2OSMZu0ifKhOhxZJJr8dR2HXmU=sbKFeLnAFP-
> zpT69P-oClnR4lbitbdaZYjOsDepCjxo=
> 
> There are also htmlized versions available at:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dmvpn-2Dexpl-2Dtrack-
> 

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

[Adrian Farrel]

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.

 

Ciao,

Adrian

 

Oh! John just sent almost the same email!

 

From: BESS  On Behalf Of Henderickx, Wim (Nokia - 
BE/Antwerp)
Sent: 22 January 2019 17:00
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 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/

 

[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.
___
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

[John E Drake]

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 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 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/



[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.

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

[Henderickx, Wim (Nokia - BE/Antwerp)]

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: "bess@ietf.org" 
Cc: "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/



[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.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Ben Campbell]

That all sounds good, thanks!

Ben.

> On Jan 22, 2019, at 2:59 AM, Ali Sajassi (sajassi)  wrote:
> 
> Ben,
> Thanks for your review and your comments. Please refer to my replies below 
> marked with "AS>".
> 
> On 1/9/19, 1:28 PM, "Ben Campbell"  > wrote:
> 
>Ben Campbell has entered the following ballot position for
>draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection
> 
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
> 
> 
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/
> 
> 
> 
>--
>COMMENT:
>--
> 
>Thanks for the work on this.
> 
>I support Alissa's discuss.
> 
>§2:
>- The 2119/8174 keywords in this section are not used according to the RFC
>2119/RFC 8174 definitions. The RFCs talk about requirements on 
> implementations
>to achieve interoperability. This speaks of requirements for the standards
>process. If the working group prefers to keep the use of keywords in this
>section, please add some additional text to the 2119/8174 boilerplate to
>explain the usage. (My other comments on the section assume that the 
> normative
>keywords will remain.)
> 
>- Req 2:  "The solution MUST require no changes..."
>I suggest "MUST NOT require changes"
> 
> AS> Changed it to: "must not require any changes to ..."
> 
>- Req 5: This doesn't seem to state a solution requirement; rather, it
>describes an action that VPN instances may take. Is the solution 
> requirement to
>allow this behavior?
> 
> AS>   moved the 2nd part of the paragraph to the solution description under 
> sections 3.2 and 4.2.
> 
> Regards,
> Ali



signature.asc
Description: Message signed with OpenPGP
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Mankamana, Matthew, Stephane,

Update about two drafts:

draft-ietf-bess-evpn-na-flags

  *   This is a very simple draft defining an extended community to propagate 
the IPv6 ND information along with MAC/IP routes in EVPN.
  *   It is used (and referred) in draft-ietf-bess-evpn-proxy-arp-nd, which is 
in WG Last Call status for a while now.
  *   The draft has been stable for a long time now. We believe it’s ready.

draft-ietf-bess-evpn-pref-df

  *   The draft has been recently refreshed and some changes have been made in 
order to align it with the DF Election Framework draft.
  *   Other than that, we believe it’s ready. The draft has multiple 
implementations and it’s deployed out there.

Thank you.
Jorge & authors


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

Cc: "bess-cha...@ietf.org" 
Subject: (Action required from Author)Re: Time to gather WG document status 
update
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Monday, January 21, 2019 at 8:46 PM

Hi WG
So far I have not heard from any one. It would be really great to get input 
from authors.  We would like to make progress before next meeting Prauge. If 
there is any thing which is blocking progress of any document , it might be 
good to work on it and get things resolved.

Thanks
Mankamana


From: "stephane.litkow...@orange.com" 
Date: Tuesday, January 8, 2019 at 5:42 AM
To: "draft-ietf-bess-evpn-inter-subnet-forwarding.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-irb-mcast.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-na-flags.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-per-mcast-flow-df-election.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-pref-df.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-vpls-seamless-integ.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-virtual-eth-segment.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-yang.auth...@ietf.org" 
, 
"draft-ietf-bess-l2vpn-yang.auth...@ietf.org" 
, 
"draft-ietf-bess-l3vpn-yang.auth...@ietf.org" 
, 
"draft-ietf-bess-mvpn-evpn-aggregation-label.auth...@ietf.org" 
, 
"draft-ietf-bess-mvpn-fast-failover.auth...@ietf.org" 
, 
"draft-ietf-bess-service-chaining.auth...@ietf.org" 
, 
"draft-ietf-bess-nsh-bgp-control-plane.auth...@ietf.org" 
, 
"draft-ietf-bess-datacenter-gateway.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-fast-df-recovery.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org" 
, 
"draft-ietf-bess-evpn-vpws-fxc.auth...@ietf.org" 
, 
"draft-ietf-bess-mvpn-msdp-sa-interoperation.auth...@ietf.org" 
, "bess@ietf.org" 

Cc: "Mankamana Mishra (mankamis)" , "bess-cha...@ietf.org" 

Subject: Time to gather WG document status update

Hi WG,

I wish you all an happy new year and all the best for 2019 !
We should now all be back to work and we, chairs, are expecting from WG 
document authors to get a status update of your document progress and the 
associated ETA towards the next step. Don’t hesitate to raise the blocking 
points if there is any of if you need help on anything.

Thanks to provide this update before end of next week to our secretary 
Mankamana (manka...@cisco.com).

Best Regards,

[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

Re: [bess] REMINDER: Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

[Bocci, Matthew (Nokia - GB)]

WG

This draft directly addresses a working group milestone for an MVPN YANG model, 
has been developed over a significant period of time and I have not seen any 
objection to adoption.

I am therefore closing this poll for adoption with the conclusion that there is 
consensus to adopt this draft as a working group document.

Authors: please upload a new revision of the draft changing only the name of 
the draft to draft-ietf-bess-mvpn-yang-00.

Regards

Matthew


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Wednesday, 19 December 2018 at 05:48
To: "bess@ietf.org" 
Cc: "draft-liu-bess-mvpn-y...@ietf.org" 
Subject: [bess] REMINDER: Wg Adoption and IPR poll for 
draft-liu-bess-mvpn-yang-07

Folks

I’ve only seen responses from the draft authors so far. Generally, we would 
like to see evidence that a few more people have read the draft and agree it is 
a good starting point.

I am therefore extending this WG adoption poll.

If you have not already reviewed the draft, please can you do so and indicate 
to the list if you support adoption.

This poll will now close on Monday 7th January 2019.

Season’s greetings.

Matthew

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, 3 December 2018 at 14:52
To: "bess@ietf.org" 
Cc: "draft-liu-bess-mvpn-y...@ietf.org" 
Subject: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07

This email begins a two-week poll for adoption of 
draft-liu-bess-mvpn-yang-07.txt

Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently there is one IPR declaration against this document.

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.

This poll for adoption closes on Monday 17th December 2018.

Regards,
Matthew


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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Dear chairs and WG,

I strongly believe we should progress 
draft-ietf-bess-evpn-bum-procedure-updates for the following reasons:


  *   The draft defines a number of fundamental routes that are critical for 
the deployment of multicast technologies in EVPN, especially the S-PMSI A-D and 
Leaf-AD routes.



  *   Those two routes have equivalent routes and procedures for the VPLS 
(RFC7117) and MVPN (RFC6513/6514) families. There are implementations for both 
families, draft-ietf-bess-evpn-bum-procedure-updates is just extending their 
use to EVPN. So the procedures should be proven, and it’s only a question of 
time before they get implemented and deployed.



  *   These routes are not only used in draft-ietf-bess-evpn-optimized-ir but 
in other WG documents.

Thank you.
Jorge


From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, January 22, 2019 at 7:19 AM
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, 

[bess] I-D Action: draft-ietf-bess-evpn-vpls-seamless-integ-06.txt

[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   : (PBB-)EVPN Seamless Integration with (PBB-)VPLS
Authors : Ali Sajassi
  Samer Salam
  Nick Del Regno
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-vpls-seamless-integ-06.txt
Pages   : 16
Date: 2019-01-22

Abstract:
   This document specifies mechanisms for backward compatibility of
   Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-
   EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider
   Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides
   mechanisms for seamless integration of these two technologies in the
   same MPLS/IP network on a per-VPN-instance basis. Implementation of
   this document enables service providers to introduce EVPN/PBB-EVPN
   PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This
   document specifies control-plane and forwarding behavior needed for
   auto-discovery of a VPN instance, multicast and unicast operation, as
   well as MAC-mobility operation in order to enable seamless
   integration between EVPN and VPLS PEs as well as between PBB-VPLS and
   PBB-EVPN PEs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-vpls-seamless-integ-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-vpls-seamless-integ-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpls-seamless-integ-06


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] Suresh Krishnan's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Ali Sajassi (sajassi)]

Suresh,
Thanks for your review and your comments. Please refer to my replies below 
marked with "AS>".

On 1/9/19, 8:03 PM, "Suresh Krishnan"  wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/



--
COMMENT:
--

* Section 3.3 MAC Mobility

The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, for 
a
lack of a better term, "not seamless" to me. While only using EVPN a MAC 
that
has moved will get propagated out without *initiating* any sort of BUM 
traffic
itself as described Section 15 of RFC7432. If I understand this document
correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it
will be blackholed until it initiates BUM traffic which is not the case when
the MAC moves between EVPN PEs. Did I get this right? If so, I think this
limitation needs to be highlighted a bit more prominently.

  AS>  Section 3.3 describes two MAC move scenarios: move from EVPN PE to VPLS 
PE (1st para) and move from VPLS PE to EVPN PE (2nd para). In the first 
scenario, it says that if the moved MAC address doesn't initiate any BUM 
traffic (it only initiates known unicast traffic), then there can be 
black-holing for both EVPN and VPLS PEs. However, for the 2nd scenario, the 
black-holing can happen only for VPLS PEs. To clarify this point further, I 
added a sentence to each of the paragraph. 
1st para: Such black-holing happens for traffic destined to the moved C-MAC 
from both EVPN and VPLS PEs.
2nd para: Such black-holing happens for traffic destined to the moved C-MAC for 
only VPLS PEs but not for EVPN PEs.

Cheers,
Ali


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

Re: [bess] Ben Campbell's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Ali Sajassi (sajassi)]

Ben,
Thanks for your review and your comments. Please refer to my replies below 
marked with "AS>".

On 1/9/19, 1:28 PM, "Ben Campbell"  wrote:

Ben Campbell has entered the following ballot position for
draft-ietf-bess-evpn-vpls-seamless-integ-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/



--
COMMENT:
--

Thanks for the work on this.

I support Alissa's discuss.

§2:
- The 2119/8174 keywords in this section are not used according to the RFC
2119/RFC 8174 definitions. The RFCs talk about requirements on 
implementations
to achieve interoperability. This speaks of requirements for the standards
process. If the working group prefers to keep the use of keywords in this
section, please add some additional text to the 2119/8174 boilerplate to
explain the usage. (My other comments on the section assume that the 
normative
keywords will remain.)

- Req 2:  "The solution MUST require no changes..."
I suggest "MUST NOT require changes"

AS> Changed it to: "must not require any changes to ..."

- Req 5: This doesn't seem to state a solution requirement; rather, it
describes an action that VPN instances may take. Is the solution 
requirement to
allow this behavior?

AS>   moved the 2nd part of the paragraph to the solution description under 
sections 3.2 and 4.2.

Regards,
Ali


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

Re: [bess] Deborah Brungard's Yes on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

[Ali Sajassi (sajassi)]

Deborah,

Thanks for your review and feedback. You are spot on. If the document was 
talking about only VPLS/PBB-VPLS or EVPN/PBB-EVPN, then BCP would be 
appropriate but this document specifies the mechanism needed for an 
EVPN/PBB-EVPN PEs to simultaneously interoperate with both EVPN/PBB-EVPN and 
VPLS/PBB-VPLS PEs. It specifies the control-plane and forwarding behavior for 
unicast, multicast, discovery of VPN members, and MAC mobility in context of 
such a mix mode. 

Regards,
Ali

On 1/9/19, 1:05 PM, "Deborah Brungard"  wrote:

Deborah Brungard has entered the following ballot position for
draft-ietf-bess-evpn-vpls-seamless-integ-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/



--
COMMENT:
--

I agree with the current status as PS. While it does not define new
codepoints or protocol extensions, it defines new mechanisms
which need to be supported by all (PBB-)EVPN nodes. The mechanisms
are not supported by operational configuration, they are new
mechanisms which need to be supported by the node itself.

A BCP/Informational status would be appropriate if this document
was only defining the procedures related to the VPLS or PBB-VPLS
PEs. For those nodes, there is no change, as all the new mechanisms
supporting seamless integration need to be supported on the EVPN nodes.




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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05

[Ali Sajassi (sajassi)]

Peter,

Thanks for your review and your comments. Please refer to my replies below 
marked with "AS>".

On 12/19/18, 8:15 AM, "Pete Resnick"  wrote:

Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-vpls-seamless-integ-0
Reviewer: Pete Resnick
Review Date: 2018-12-19
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with some nits, but one process issue/query.

Major issues: None

Minor issues:

This document is intended for Proposed Standard. It doesn't have protocol as
much as operational configuration information for integration. RFC 2026 
section
5 says:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.
   [...]
   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.

That sounds like what this document is doing. It also sounds like this 
document
is unlike to advance to Internet Standard, as there's not the kind of 
iterative
implementation that protocols go through. It's not a big deal either way, 
but
this does seem better suited to a BCP.

AS> I added couple of sentences to the abstract and introduction explaining why 
this draft should be "standard". 

Nits/editorial comments:

Abstract: s/draft/document/g

AS> done

Introduction: "Many Service Providers (SPs) who...". You don't use "SP"
anywhere else in the document, and other places where you use the phrase it
isn't capitalized. Suggest just saying "Many service providers who..."

AS> done

§1, Definitions:

   (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this
   abbreviation is used when the text applies to both technologies.

It says EVPN in the second sentence. I don't understand. Did you mean VPLS?

AS> The intention was to say "just like EVPN, ... " However, this is creating 
some confusion. So, I changed it to:
" (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. This document uses this 
abbreviation when a given description applies to both technologies."

§2: The 4 "MUST"s and 1 "MAY" aren't requirements on the implementation;
they're the requirements this document will satisfy. Seems like they 
shouldn't
be capitalized.

AS> already corrected. Alvaro had the same comment.

§3.2, second bullet, 3.4.1, last paragraph, §4.2, second bullet, and §4.4.1,
last paragraph: Why are the "must"s not capitalized?

AS> already corrected. Thanks for noting them.

Cheers,
Ali


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