Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

[Dikshit, Saumya]

Hi Jorge and Bess member

Can you please go provide your inputs on the use-case and solution described in 
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/

Thanks
Saumya.

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Wednesday, September 15, 2021 4:44 PM
To: Joshi, Vinayak ; Rabadan, Jorge (Nokia - US/Mountain 
View) ; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org; 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery 
and rfc

Hi Jorge and Members of Bess WG,

Please let us know your views on 
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/.
We have described the use-case this draft intends to solve, leveraging the 
existing TLVs.
Please include this as wg draft.

Thanks
Saumya.

From: Dikshit, Saumya
Sent: Friday, September 3, 2021 5:53 PM
To: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>; 
Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Jorge and others in Bess WG,

We have come out with a new draft to which proposes a DF-election-mode where in 
all the PEs intend to play the DF-role.
Please go through the document and provide your comments: 
https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/

Thanks
Saumya.


From: Joshi, Vinayak
Sent: Monday, August 23, 2021 5:22 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

+1 for standard compliance on the control plane to indicate [All Active + All 
DF].
However, I think local bias is still needed to prevent some scenarios

E.g.:
1)  Host1 sends out ARP request for the Firewall.
2)  It reaches VTEP-1 over VxLAN from Vtep_Host1. Two options at Vtep_1

a)  Proprietary Option:  VTEP 2 does not forward it over the VxLAN DCI 
tunnel to Vtep2. I.e. VTEP 1 has to match the ARP for Firewall.

b)   Vtep_1 sends it over VTEP 2 on VxLAN DCI. VTEP 2's local bias 
procedure prevents it from getting into Firewall_2.  This makes it easier to 
implement on Vtep_2. This is because Vtep_1 need not selectively block BUM over 
the VxLAN tunnel (ARP from Host1 to resolve Host2's IP has to be forwarded by 
Vtep_1 to Vtep_2).

Regards,
Vinayak



From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Thursday, August 19, 2021 11:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery 
and rfc


 If you still want to control the unicast and BUM flows to one FW or the 
 other depending on the leaf, you can still do it but that's implementation 
 specific since it relies on the route selection in vtep_host1 and 
 vtep_host2.
+1 on the implementation part. It's good to have few proprietary solutions in 
place.
On another note, the best way forward could be the standards-support/enabler 
for EVPN control-plane;
like an option to allow more than one PEs (in active-active) to process the BUM 
(arp request) traffic.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Thursday, August 19, 2021 9:40 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org;
 
draft-ietf-bess-evpn-df-election-framew...@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

I think you are saying that the FW can fail but it's interface to the leaf is 
oper-up. I don't think the network can do anything to prevent traffic to that 
interface then.

And of course, in 

[bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-geneve-02

[Bocci, Matthew (Nokia - GB)]

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

[bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Bocci, Matthew (Nokia - GB)]

Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for Geneve

Apologies for the error.

Matthew

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

Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[Wanghaibo (Rainsword)]

Hi Ketan,

I’m sorry I have missed your reply.

For SRv6 services, we may have two choice for service. Use SRv6 SID to do best 
effort, or use  to steering to a SRv6 Policy。
Also we may use both of them, but most time we are priority to use the SRv6 
Policy than fall-back to SRv6 best effort, while SRv6 Policy is down.
So I think maybe use “alternate steering mechanism” is better.  Or maybe I 
misunderstood the sentence?

Regards,
Haibo

From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, September 16, 2021 4:55 PM
To: Wanghaibo (Rainsword) ; bess@ietf.org
Cc: draft-ietf-bess-srv6-servi...@ietf.org; spr...@ietf.org; Aissaoui, Mustapha 
(Nokia - CA/Ottawa) ; Shraddha Hegde 

Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Haibo,

Since the discussion on the list was related to fallback mechanisms, we have 
those words.

How about s/fallback mechanism /alternate steering mechanism ? Or please 
suggest if you had something else in your mind.

Thanks,
Ketan

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: 16 September 2021 14:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

Hi Ketan,

   I think the overall description is OK. But is it appropriate to use the 
word “fallback mechanism”?

Regards,
Haibo

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Wednesday, September 15, 2021 11:00 AM
To: bess@ietf.org
Cc: 
draft-ietf-bess-srv6-servi...@ietf.org;
 spr...@ietf.org; Aissaoui, Mustapha (Nokia - 
CA/Ottawa) mailto:mustapha.aissa...@nokia.com>>; 
Shraddha Hegde mailto:shrad...@juniper.net>>
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hello All,

Getting back on this topic with a text update proposal for sec 5 and 6 of the 
draft.

The objective of this change is to clarify the use of the SHOULD that is used 
in this text.

OLD/CURRENT
   When providing best-effort connectivity to the egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.

NEW
   When the steering for SRv6 services is based on shortest path forwarding 
(e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to the 
egress PE, the ingress
   PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID associated with the
   related BGP route update.  Therefore, the ingress PE SHOULD perform
   resolvability check for the SRv6 Service SID before considering the
   received prefix for the BGP best path computation.  The result of an
   SRv6 Service SID reachability (e.g. when provided via IGP Flexible
   Algorithm) can be ignored if the ingress PE has a local policy that
   allows a fallback mechanism to reach the egress PE. The details of
   such fallback mechanisms is outside the scope of this document.

Please let know your feedback. The authors will look to incorporate this change 
along with any other comments as part of the AD review updates.

Thanks,
Ketan

From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Sent: 23 July 2021 22:10
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

That is great. Thank you.

Mustapha.

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, July 23, 2021 11:08 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>
Cc: spr...@ietf.org; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
bess@ietf.org; 
draft-ietf-bess-srv6-servi...@ietf.org
Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

< trimming list to mostly mailers >

Hi Mustapha,

I agree.

Also after seeing Shraddha’s latest email, the coverage and details for the 
fallback mechanisms that she seems to be looking for is quite vast and better 
tackled in a separate d

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[John E Drake]

I'm not aware of any IPR

Yours Irrespectively,

John



Juniper Business Use Only
From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Tuesday, September 28, 2021 2:02 AM
To: 'BESS' 
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

[External Email. Be cautious of content]


Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

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

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

Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

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

As co-author, I support this document for publication as standards track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: Bocci, Matthew (Nokia - GB) 
Date: Tuesday, September 28, 2021 at 11:00 AM
To: bess@ietf.org 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*
Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for Geneve

Apologies for the error.

Matthew

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

Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org 
Cc: draft-ietf-bess-evpn-gen...@ietf.org 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[UTTARO, JAMES]

Support.

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, September 28, 2021 5:04 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: draft-ietf-bess-evpn-gen...@ietf.org
Subject: Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*

As co-author, I support this document for publication as standards track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, September 28, 2021 at 11:00 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*
Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for 
Geneve

Apologies for the error.

Matthew

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

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

As co-author, I support the publication of this document as Standards Track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Tuesday, September 28, 2021 at 8:03 AM
To: 'BESS' 
Cc: bess-cha...@ietf.org 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

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

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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Mankamana Mishra (mankamis)]

Support publication of this document.

From: slitkows.i...@gmail.com 
Date: Monday, September 27, 2021 at 11:02 PM
To: 'BESS' 
Cc: bess-cha...@ietf.org 
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

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

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

Re: [bess] [**EXTERNAL**] Re: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Boutros, Sami]

I support the publication and not aware of any IPR.

Thanks,

Sami
From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Tuesday, September 28, 2021 at 8:29 AM
To: "slitkows.i...@gmail.com" , 'BESS' 
Cc: "bess-cha...@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] WG Last Call, IPR and Implementation Poll 
for draft-ietf-bess-evpn-vpws-fxc

As co-author, I support the publication of this document as Standards Track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: BESS  on behalf of slitkows.i...@gmail.com 

Date: Tuesday, September 28, 2021 at 8:03 AM
To: 'BESS' 
Cc: bess-cha...@ietf.org 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/ 
[datatracker.ietf.org]

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

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

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Boutros, Sami]

I support the publication and not aware of any IPR.

Thanks,

Sami
From: "UTTARO, JAMES" 
Date: Tuesday, September 28, 2021 at 7:29 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" 

Cc: "draft-ietf-bess-evpn-gen...@ietf.org" 

Subject: [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation 
Poll for *draft-ietf-bess-evpn-geneve-03*
Resent-From: 
Resent-To: , , 
, , 
Resent-Date: Tuesday, September 28, 2021 at 7:29 AM

Support.

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Tuesday, September 28, 2021 5:04 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: draft-ietf-bess-evpn-gen...@ietf.org
Subject: Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*

As co-author, I support this document for publication as standards track RFC.
Not aware of any relevant IPR.

Thanks.
Jorge

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, September 28, 2021 at 11:00 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*
Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for 
Geneve

Apologies for the error.

Matthew

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] [**EXTERNAL**] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Shah, Himanshu]

I support publishing of this draft.

Ciena has implemented this draft.

Thanks,
Himanshu

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Tuesday, September 28, 2021 at 2:03 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [**EXTERNAL**] [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc


Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/ 
[datatracker.ietf.org]

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

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

Re: [bess] [**EXTERNAL**] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[UTTARO, JAMES]

As co-author I support an am not aware of any IPR..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Shah, Himanshu
Sent: Tuesday, September 28, 2021 11:54 AM
To: slitkows.i...@gmail.com; 'BESS' 
Cc: bess-cha...@ietf.org
Subject: Re: [bess] [**EXTERNAL**] WG Last Call, IPR and Implementation Poll 
for draft-ietf-bess-evpn-vpws-fxc

I support publishing of this draft.

Ciena has implemented this draft.

Thanks,
Himanshu

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>
Date: Tuesday, September 28, 2021 at 2:03 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: [**EXTERNAL**] [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc


Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/ 
[datatracker.ietf.org]

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

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

Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Jeff Tantsura]

Yes/support 

Cheers,
Jeff

> On Sep 28, 2021, at 07:04, Rabadan, Jorge (Nokia - US/Mountain View) 
>  wrote:
> 
> 
> As co-author, I support this document for publication as standards track RFC.
> Not aware of any relevant IPR.
>  
> Thanks.
> Jorge
>  
> From: Bocci, Matthew (Nokia - GB) 
> Date: Tuesday, September 28, 2021 at 11:00 AM
> To: bess@ietf.org 
> Cc: draft-ietf-bess-evpn-gen...@ietf.org 
> 
> Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
> *draft-ietf-bess-evpn-geneve-03*
> 
> Folks
>  
> Please note this WG last call is for version 03 of the draft (not 02 as 
> stated in the subject line of the email)
>  
> The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
> for Geneve
>  
> Apologies for the error.
>  
> Matthew
>  
> From: BESS  on behalf of Bocci, Matthew (Nokia - GB) 
> 
> Date: Tuesday, 28 September 2021 at 09:56
> To: bess@ietf.org 
> Cc: draft-ietf-bess-evpn-gen...@ietf.org 
> 
> Subject: [bess] WG Last Call, IPR and Implementation Poll for 
> draft-ietf-bess-evpn-geneve-02
> 
> This email starts a two-week working group last call for 
> draft-ietf-bess-evpn-geneve-03 [1]
>  
> Please review the draft and send any comments to the BESS list. Also, please 
> indicate if you support publishing the draft as a Standards Track RFC.
>  
> This poll runs until the 15th October 2021
>  
> 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 are currently no IPR disclosures.
>  
> In addition, we are polling for knowledge of implementations of this draft, 
> per the BESS policy in [2].   
>  
> Thank you,
> Matthew & Stephane
>  
>  
> [1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for Geneve
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>  
>  
> ___
> 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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Luc André Burdet]

I support publication ;  Cisco / IOS-XR has implemented this draft

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: 
Date: Tuesday, September 28, 2021 at 02:02
To: 'BESS' 
Cc: 
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc


Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



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 are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

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

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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Anoop Ghanwani]

I support the publication of this draft.  I have the following comments
and suggested edits.

--

Technical comments

Section 4.1

I find this statement confusing

   While "local-bias" MUST be supported along with GENEVE encapsulation,
   the use of the Ethernet option-TLV is RECOMMENDED to follow the same
   procedures used by EVPN MPLS.


I'm not sure how it helps to carry an extra TLV when it is known
that its absence or presence results in identical behavior.

I also find the encoding confusing.  Why is the Type=0, instead of
using EVPN-OPTION with a length of 0x1 instead of 0x2?
What does Type=0 indicate?  Is this assigned by IANA?

Section 6

What is inter-AS option B?  Can we provide a reference?

Section 8

Doesn't IANA also need to allocate a codepoint for the
EVPN-OPTION type?

--

Editorial comments

Entire document

- 3 of the references listed as drafts are now RFCs.  Those should
  be fixed both in the reference section and in the text.

- There are several uses of GENEVE and Geneve in the document.
  Recommend replacing GENEVE with Geneve, including in the
  abbreviations and terminology section.

Section 1

Change

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving from, or sending
   to, over the Geneve tunnel with its peers.

To

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving or sending
   over the Geneve tunnel with its peers.


Section 4

Change

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that are relevant to the operation of EVPN.

To

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that is relevant to the operation of EVPN.

End

Section 4.1

Change

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM traffic type.

To

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM packet.


Change

   For GENEVE, we need a bit to for this purpose.

To

   For GENEVE, we need a bit for this purpose.


Expand first use of AC and add to abbreviations and terminology.

ecnapsulations -> encapsulations


GENVE -> Geneve

(There are 2 instances of this.)


"20- bit MPLS label" -> "20-bit MPLS label"


Add figure captions for the 2 figures showing the TLVs.

Expand first use of ES and ESI and add to abbreviations and terminology.

Change

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ESI field.

To

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ID field.


Change

   The egress NVEs that make use of ESIs in the data path because they
   have a local multi-homed ES or support [RFC8317
] SHOULD advertise
   their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV
   and in addition to the ESI-label Extended Community.

Remove "and".

On Mon, Sep 27, 2021 at 11:02 PM  wrote:

> Hi,
>
>
>
> This email starts a two-week working group last call for 
> draft-ietf-bess-evpn-vpws-fxc [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also, please 
> indicate if you support publishing the draft as a Standards Track RFC.
>
>
>
> This poll runs until the 12th October 2021.
>
>
>
> 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 are currently two IPR disclosures.
>
>
>
> In addition, we are polling for knowledge of implementations of this draft, 
> per the BESS policy in [2].
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> 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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Anoop Ghanwani]

Sorry, sent to the wrong thread.  Will resend to the correct one.

On Mon, Sep 27, 2021 at 11:02 PM  wrote:

> Hi,
>
>
>
> This email starts a two-week working group last call for 
> draft-ietf-bess-evpn-vpws-fxc [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also, please 
> indicate if you support publishing the draft as a Standards Track RFC.
>
>
>
> This poll runs until the 12th October 2021.
>
>
>
> 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 are currently two IPR disclosures.
>
>
>
> In addition, we are polling for knowledge of implementations of this draft, 
> per the BESS policy in [2].
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
> ___
> 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

Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Anoop Ghanwani]

I support the publication of this draft.  I have the following comments
and suggested edits.

--

Technical comments

Section 4.1

I find this statement confusing

   While "local-bias" MUST be supported along with GENEVE encapsulation,
   the use of the Ethernet option-TLV is RECOMMENDED to follow the same
   procedures used by EVPN MPLS.


I'm not sure how it helps to carry an extra TLV when it is known
that its absence or presence results in identical behavior.

I also find the encoding confusing.  Why is the Type=0, instead of
using EVPN-OPTION with a length of 0x1 instead of 0x2?
What does Type=0 indicate?  Is this assigned by IANA?

Section 6

What is inter-AS option B?  Can we provide a reference?

Section 8

Doesn't IANA also need to allocate a codepoint for the
EVPN-OPTION type?

--

Editorial comments

Entire document

- 3 of the references listed as drafts are now RFCs.  Those should
  be fixed both in the reference section and in the text.

- There are several uses of GENEVE and Geneve in the document.
  Recommend replacing GENEVE with Geneve, including in the
  abbreviations and terminology section.

Section 1

Change

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving from, or sending
   to, over the Geneve tunnel with its peers.

To

   This EVPN control plane extension will allow an NVE to express what
   Geneve option TLV types it is capable of receiving or sending
   over the Geneve tunnel with its peers.


Section 4

Change

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that are relevant to the operation of EVPN.

To

   This document adds an extension to the [I-D.ietf-nvo3-geneve
]
   encapsulation that is relevant to the operation of EVPN.

End

Section 4.1

Change

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM traffic type.

To

   [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses
   ingress replication to flood unknown unicast traffic to the egress
   NVEs, the ingress NVE needs to indicate to the egress NVE that the
   Encapsulated packet is a BUM packet.


Change

   For GENEVE, we need a bit to for this purpose.

To

   For GENEVE, we need a bit for this purpose.


Expand first use of AC and add to abbreviations and terminology.

ecnapsulations -> encapsulations


GENVE -> Geneve

(There are 2 instances of this.)


"20- bit MPLS label" -> "20-bit MPLS label"


Add figure captions for the 2 figures showing the TLVs.

Expand first use of ES and ESI and add to abbreviations and terminology.

Change

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ESI field.

To

   The ESI-label value is encoded in the high-order 20 bits
   of the Source-ID field.


Change

   The egress NVEs that make use of ESIs in the data path because they
   have a local multi-homed ES or support [RFC8317
] SHOULD advertise
   their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV
   and in addition to the ESI-label Extended Community.

Remove "and".


On Tue, Sep 28, 2021 at 8:47 AM Boutros, Sami  wrote:

> I support the publication and not aware of any IPR.
>
>
>
> Thanks,
>
>
>
> Sami
>
> *From: *"UTTARO, JAMES" 
> *Date: *Tuesday, September 28, 2021 at 7:29 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "Bocci, Matthew (Nokia - GB)" , "bess@ietf.org" <
> bess@ietf.org>
> *Cc: *"draft-ietf-bess-evpn-gen...@ietf.org" <
> draft-ietf-bess-evpn-gen...@ietf.org>
> *Subject: *[**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and
> Implementation Poll for *draft-ietf-bess-evpn-geneve-03*
> *Resent-From: *
> *Resent-To: *, , <
> sbout...@ciena.com>, , 
> *Resent-Date: *Tuesday, September 28, 2021 at 7:29 AM
>
>
>
> *Support.*
>
>
>
> *Thanks,*
>
> *  Jim Uttaro*
>
>
>
> *From:* BESS  *On Behalf Of * Rabadan, Jorge
> (Nokia - US/Mountain View)
> *Sent:* Tuesday, September 28, 2021 5:04 AM
> *To:* Bocci, Matthew (Nokia - GB) ; bess@ietf.org
> *Cc:* draft-ietf-bess-evpn-gen...@ietf.org
> *Subject:* Re: [bess] CORRECTION WG Last Call, IPR and Implementation
> Poll for *draft-ietf-bess-evpn-geneve-03*
>
>
>
> As co-author, I support this document for publication as standards track
> RFC.
>
> Not aware of any relevant IPR.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Bocci, Matthew (Nokia - GB) 
> *Date: *Tuesday, September 28, 2021 at 11:00 AM
> *To: *bess@ietf.org 
> *Cc: *draft-ietf-bess-evpn-gen...@ietf.org <
> draft-ietf-bess-evpn-gen...@ietf.org>
> *Subject: *CORRECTION WG Last Call, IPR and Implementation Poll

Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[John E Drake]

Support

Yours Irrespectively,

John



Juniper Business Use Only
From: Bocci, Matthew (Nokia - GB) 
Sent: Tuesday, September 28, 2021 5:00 AM
To: bess@ietf.org
Cc: draft-ietf-bess-evpn-gen...@ietf.org
Subject: CORRECTION WG Last Call, IPR and Implementation Poll for 
*draft-ietf-bess-evpn-geneve-03*

[External Email. Be cautious of content]

Folks

Please note this WG last call is for version 03 of the draft (not 02 as stated 
in the subject line of the email)

The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control plane 
for 
Geneve

Apologies for the error.

Matthew

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, 28 September 2021 at 09:56
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: 
draft-ietf-bess-evpn-gen...@ietf.org
 
mailto:draft-ietf-bess-evpn-gen...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-geneve-02
This email starts a two-week working group last call for 
draft-ietf-bess-evpn-geneve-03 [1]

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.

This poll runs until the 15th October 2021

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 are currently no IPR disclosures.

In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].

Thank you,
Matthew & Stephane


[1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for 
Geneve
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] CORRECTION WG Last Call, IPR and Implementation Poll for *draft-ietf-bess-evpn-geneve-03*

[Sam Aldrin]

Support the publication.

Not aware of ipr related to this document.

Sam

On Tue, Sep 28, 2021, 12:59 PM John E Drake  wrote:

> Support
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Bocci, Matthew (Nokia - GB) 
> *Sent:* Tuesday, September 28, 2021 5:00 AM
> *To:* bess@ietf.org
> *Cc:* draft-ietf-bess-evpn-gen...@ietf.org
> *Subject:* CORRECTION WG Last Call, IPR and Implementation Poll for
> *draft-ietf-bess-evpn-geneve-03*
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Folks
>
>
>
> Please note this WG last call is for version 03 of the draft (not 02 as
> stated in the subject line of the email)
>
>
>
> The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control
> plane for Geneve
> 
>
>
>
> Apologies for the error.
>
>
>
> Matthew
>
>
>
> *From: *BESS  on behalf of Bocci, Matthew (Nokia -
> GB) 
> *Date: *Tuesday, 28 September 2021 at 09:56
> *To: *bess@ietf.org 
> *Cc: *draft-ietf-bess-evpn-gen...@ietf.org <
> draft-ietf-bess-evpn-gen...@ietf.org>
> *Subject: *[bess] WG Last Call, IPR and Implementation Poll for
> draft-ietf-bess-evpn-geneve-02
>
> This email starts a two-week working group last call for 
> draft-ietf-bess-evpn-geneve-03
> [1]
>
>
>
> Please review the draft and send any comments to the BESS list. Also,
> please indicate if you support publishing the draft as a Standards Track
> RFC.
>
>
>
> This poll runs until the 15th October 2021
>
>
>
> 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 are currently no IPR disclosures.
>
>
>
> In addition, we are polling for knowledge of implementations of this
> draft, per the BESS policy in [2].
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
>
>
> [1]  draft-ietf-bess-evpn-geneve-02 - EVPN control plane for Geneve
> 
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Joshi, Vinayak]

Jorge,

Thanks, that should help. No need to change the text.

Regards,
Vinayak

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Tuesday, September 28, 2021 11:25 AM
To: Joshi, Vinayak ; The IESG ; 
draft-ietf-bess-evpn-proxy-arp...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Bocci, Matthew (Nokia - GB) ; 
jeanmichel.com...@orange.com; Eric Vyncke (evyncke) 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Vinayak,

In the document the reply sub-function section says that the PE SHOULD reply to 
DAD NS messages, but it is not a MUST. So if your implementation has a config 
knob to not reply DAD NS messages as an exception, it could still be compliant 
with the document.

Thanks.
Jorge

From: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>
Date: Tuesday, September 28, 2021 at 4:21 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>, The IESG 
mailto:i...@ietf.org>>, 
draft-ietf-bess-evpn-proxy-arp...@ietf.org
 
mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
jeanmichel.com...@orange.com 
mailto:jeanmichel.com...@orange.com>>, Eric 
Vyncke (evyncke) mailto:evyn...@cisco.com>>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hi Jorge,

Thank you for a detailed response.

As you said this is a corner case - hence may be it can be left to 
implementation. That is, a PE can have a config knob to treat DAD NS as an 
exception and not respond to it.

Regards,
Vinayak

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Monday, September 27, 2021 9:44 PM
To: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>; The 
IESG mailto:i...@ietf.org>>; 
draft-ietf-bess-evpn-proxy-arp...@ietf.org;
 bess-cha...@ietf.org; 
bess@ietf.org; Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
jeanmichel.com...@orange.com; Eric Vyncke 
(evyncke) mailto:evyn...@cisco.com>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Vinayak,

Others can comment too, but these are my comments:

-One of the main benefits of proxy-arp/nd is the reduction of flooding, and 
DAD is multicast traffic and it may be significant in an EVPN BD. So proxy-ND 
replying to DAD NS messages is still important IMO.
-Although I guess the use-case you describe may be possible, one may wonder 
why the DHCPv6 server allocation strategy would allocate IP1 to MAC2, when it 
had just received a release for the IP from MAC1. And even without proxy-ND, it 
will take some time for the remote hosts to update their caches anyway, so it 
is not that the communication is uninterrupted if proxy-nd did not reply to DAD 
NS.
-Also, the mechanisms in the document will update the proxy-ND entries as 
soon as possible, either due to CE1 acquiring a different IP and being learned 
or via the proxy-nd maintenance sub-function.
-You mention GARPs for IPv4, there may also be unsolicited NA messages 
issued by CE1 in some cases, which would speed things up as well.

Due to the above, I would keep the current text in the document in regards to 
the reply to DAD NS messages. It would be good if others comment too, but to me 
it sounds like a corner case and in any case, the tables will be updated anyway.

Maybe we can add some text in the security section if it helps?

Thanks.
Jorge


From: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>
Date: Monday, September 27, 2021 at 12:34 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>, The IESG 
mailto:i...@ietf.org>>, 
draft-ietf-bess-evpn-proxy-arp...@ietf.org
 
mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
jeanmichel.com...@orange.com 
mailto:jeanmichel.com...@orange.com>>, Eric 
Vyncke (evyncke) mailto:evyn...@cisco.com>>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hi Jorge,

A question related to DAD performed by CEs in the context of Proxy-ND.


1)  Say is IP1 allocation to MAC1 on a CE is released by the CE 1 (DHCP 
release) and IP1 is assigned to MAC2 (CE2) by DHCP server immediately (common 
in DCs).

2)  Now CE2

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hi Vinayak,

Note that I disagree with that. The PE SHOULD MAC-unicast the DAD to the owner 
and let the owner reply.
The proxy response should be the exception, e.g. , when the device is a 
sleeping IoT device. A proxy response prevents the owner to reply with options 
that are not defined yet be may be in the future - e.g., to pass a proof of 
ownership.
Also if the PE missed a movement it will protect a node that 's not there 
anymore, maybe against itself.

You may consider the art of ND proxies such as RFC 8929. There's more to it 
than meet the eye.

Keep safe;

Pascal


From: BESS  On Behalf Of Joshi, Vinayak
Sent: mercredi 29 septembre 2021 4:46
To: Rabadan, Jorge (Nokia - US/Mountain View) ; The 
IESG ; draft-ietf-bess-evpn-proxy-arp...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org; Bocci, Matthew (Nokia - GB) 
; jeanmichel.com...@orange.com; Eric Vyncke (evyncke) 

Subject: Re: [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

Jorge,

Thanks, that should help. No need to change the text.

Regards,
Vinayak

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Tuesday, September 28, 2021 11:25 AM
To: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>; The 
IESG mailto:i...@ietf.org>>; 
draft-ietf-bess-evpn-proxy-arp...@ietf.org;
 bess-cha...@ietf.org; 
bess@ietf.org; Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
jeanmichel.com...@orange.com; Eric Vyncke 
(evyncke) mailto:evyn...@cisco.com>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Vinayak,

In the document the reply sub-function section says that the PE SHOULD reply to 
DAD NS messages, but it is not a MUST. So if your implementation has a config 
knob to not reply DAD NS messages as an exception, it could still be compliant 
with the document.

Thanks.
Jorge

From: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>
Date: Tuesday, September 28, 2021 at 4:21 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>, The IESG 
mailto:i...@ietf.org>>, 
draft-ietf-bess-evpn-proxy-arp...@ietf.org
 
mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>,
 bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>, 
bess@ietf.org mailto:bess@ietf.org>>, 
Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>, 
jeanmichel.com...@orange.com 
mailto:jeanmichel.com...@orange.com>>, Eric 
Vyncke (evyncke) mailto:evyn...@cisco.com>>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)
Hi Jorge,

Thank you for a detailed response.

As you said this is a corner case - hence may be it can be left to 
implementation. That is, a PE can have a config knob to treat DAD NS as an 
exception and not respond to it.

Regards,
Vinayak

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Monday, September 27, 2021 9:44 PM
To: Joshi, Vinayak mailto:vinayak.jo...@hpe.com>>; The 
IESG mailto:i...@ietf.org>>; 
draft-ietf-bess-evpn-proxy-arp...@ietf.org;
 bess-cha...@ietf.org; 
bess@ietf.org; Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>; 
jeanmichel.com...@orange.com; Eric Vyncke 
(evyncke) mailto:evyn...@cisco.com>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: 
(with DISCUSS and COMMENT)

Hi Vinayak,

Others can comment too, but these are my comments:

-One of the main benefits of proxy-arp/nd is the reduction of flooding, and 
DAD is multicast traffic and it may be significant in an EVPN BD. So proxy-ND 
replying to DAD NS messages is still important IMO.
-Although I guess the use-case you describe may be possible, one may wonder 
why the DHCPv6 server allocation strategy would allocate IP1 to MAC2, when it 
had just received a release for the IP from MAC1. And even without proxy-ND, it 
will take some time for the remote hosts to update their caches anyway, so it 
is not that the communication is uninterrupted if proxy-nd did not reply to DAD 
NS.
-Also, the mechanisms in the document will update the proxy-ND entries as 
soon as possible, either due to CE1 acquiring a different IP and being learned 
or via the proxy-nd maintenance sub-function.
-You mention GARPs for IPv4, there may also be unsolicited NA messages 
issued by CE1 in some cases, which would speed things up as well.

Due to the above, I would keep the current text in the document in regards to 
the reply to DAD NS messages. It would be good if others comment too, but to me 
it so