Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

[UTTARO, JAMES]

I am unaware of any IPR..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Wen Lin
Sent: Monday, June 12, 2023 1:10 PM
To: Mankamana Mishra (mankamis) ; 
slitkows.i...@gmail.com; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

Support as a co-author. I am unaware of any IPRs.

Thanks,
Wen



Juniper Business Use Only
From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Mankamana Mishra (mankamis) 
mailto:mankamis=40cisco@dmarc.ietf.org>>
Date: Thursday, May 25, 2023 at 11:31 AM
To: slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>, 
bess@ietf.org mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>
Subject: Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless
[External Email. Be cautious of content]

Support the adoption .

From: slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
Date: Wednesday, May 24, 2023 at 1:02 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>
Subject: WG adoption for draft-brissette-bess-evpn-vpws-seamless
Hello,


This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-vpws-seamless-07 [1].
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 will not progress 
without answers from all the authors and contributors.
Currently, there is currently no IPR disclosure 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 June 7th.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Ali Sajassi (sajassi)
Sent: Wednesday, July 13, 2022 3:02 PM
To: Bocci, Matthew (Nokia - GB) ; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

I support publication of this document and I am not aware of any IPR that 
hasn't been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Monday, January 31, 2022 at 5:58 AM
To: 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org
 
mailto:draft-ietf-bess-evpn-fast-df-recov...@ietf.org>>,
 bess@ietf.org mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election
[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] [Idr] FW: Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Sunnyvale)
Sent: Wednesday, July 6, 2022 10:56 AM
To: bess@ietf.org; Susan Hares 
Subject: Re: [bess] [Idr] FW: Review of 
draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Hi Sue,

Sorry, it took us longer than we wanted.

We appreciate your comments. We put some work onto the draft with some back and 
forth discussions among the authors and other WG members. Based on that, we 
published version 7.
With version 7 in mind, please see my responses in-line with [jorge2].

If this new version and my responses below do not clear your concerns, it is 
probably better to schedule a meeting among authors, BESS chairs and yourself. 
We can do it face to face in Philadelphia.

Thank you,
Jorge


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Monday, March 21, 2022 at 1:28 PM
To: bess@ietf.org mailto:bess@ietf.org>>
Subject: Re: [bess] [Idr] FW: Review of 
draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Jorge:



Thank you for your patience in my response.  I am sorry I missed this email on 
bess@ietf.org.



[individual contributor hat on]



My inline responses are marked [sue].



High-level:



1) Draft content:

1-a) This draft modifies RFC4271 - this should be in the header.

I believe without this in the header,

Not enough people paid attention in IDR.

[jorge2] ok, added in the abstract and introduction.



1-b) Why did you not break out just the DPATH attribute description

into a separate document?



A draft which modifies RFC4271 and DPATH could be broken

out and separately reviewed in IDR.   I think this would help clarify your

mechanisms versus the VPN procedures.

[jorge2] D-PATH was needed in the context of the use cases defined in this 
document. Without explaining the use cases and procedures, D-PATH did not make 
sense. Or in other words, D-PATH cannot be specified without the procedures 
explained in the rest of the document. Also, after a few years since its 
inception, multiple vendors have implemented it and follow the procedures in 
this draft, which is the reference for implementors. I don't think we should 
put it in a different document for those two reasons.

[Jim U>] +1.. D-PATH is required to facilitate the interworking between 2547 
and EVPN and ensure that routing loops are prevented at the service level. I am 
unsure if D-PATH is being used for other FOUs.



2) this proposal lacks a clear section on error handling.



The error handling exist on malformed D-PATH attribute, but does not deal with

Syntax error (e.g. if ISF_SAF_TYPE = 2), or interworking

(What happens if RFC9012 attribute is in a route.   Does it just get tossed?)

[jorge2] we added a new (hopefully clear) section about error handling. It 
should cover all cases. The two examples you give are covered, i.e., unknown 
ISF_SAFI_TYPE or reception of RFC9012 attribute (addressed by the normative 
references to the other RFCs). This document does not impose new rules except 
for the ones related to D-PATH. Any gaps in the other specs should be covered 
in updates for those specifications. By the way, I'm personally happy to 
participate in those updates if the BESS/IDR think it is needed.



3) The changes to RFC4271 do not give ample proof for "no loops case"
or scale.

[jorge2] the section about d-path and the security considerations sections 
describe how D-PATH can be used to prevent control plane loops in the described 
use-cases. Only the described use-cases are exposed to this new type of 
"loops". As mentioned, the solution is implemented and working in real live 
networks. Please check out the new version, and if you want us to provide more 
information or text, please be more specific on what else is needed to address 
your concern.

More comments below with [jorge2].



For these reasons, as an individual contributor I believe this

Draft needs work before publishing.



Sue








My apologies for the delay.



Thank you very much for your review!

We've just published rev 06 which addresses some of your comments.



Please see below in-line with [jorge].



Thanks.

Jorge





From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Susan Hares

Sent: Tuesday, July 27, 2021 12:19 PM

To: bess@ietf.org

Cc: 'idr-chairs'; bess-cha...@ietf.org

Subject: [bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt



Bess chairs reminded me that IDR WG was requested at IETF 110 to review 
draft-ietf-bess-evpn-ipvpn-interworking-05.txt. Since we did not receive 
reviews from the IDR WG, the IDR chairs have taken on the task of reviewing 
this document.



Full review is at:

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Lizhenbin
Sent: Friday, February 11, 2022 7:13 AM
To: slitkows.ietf ; bess ; 
draft-ietf-bess-evpn-mh-split-horizon 

Cc: bess-chairs 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-mh-split-horizon

Hi All,
I support the publication.


Best Regards,
Zhenbin (Robin)





李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com
发件人：slitkows.ietf mailto:slitkows.i...@gmail.com>>
收件人：bess 
mailto:bess@ietf.org>>;draft-ietf-bess-evpn-mh-split-horizon 
mailto:draft-ietf-bess-evpn-mh-split-hori...@ietf.org>>
抄 送：bess-chairs mailto:bess-cha...@ietf.org>>
时 间：2022-01-26 17:50:33
主 题：[bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-mh-split-horizon


Hello Working Group,



This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-mh-split-horizon [1].



This poll runs until *the 9th of Feb*.



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 no IPR currently 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-mh-split-horizon/

[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

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

[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

[bess] draft-mohanty-bess-ebgp-dmz-03

[UTTARO, JAMES]

Support


Thanks,
Jim Uttaro


From: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Tuesday, September 7, 2021 at 5:42 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: 
"draft-mohanty-bess-ebgp-...@ietf.org"
 
mailto:draft-mohanty-bess-ebgp-...@ietf.org>>
Subject: WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:aks...@arista.com>>, 
mailto:ajk...@arista.com>>, 
mailto:satya...@cisco.com>>, 
mailto:avay...@google.com>>
Resent-Date: Tuesday, September 7, 2021 at 5:42 AM

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].

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 will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures 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 September 21st 2021.

Regards,
Matthew and Stephane


[1] 
https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/



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

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

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring  On Behalf Of Aissaoui, Mustapha (Nokia - 
CA/Ottawa)
Sent: Tuesday, July 20, 2021 1:14 PM
To: Srihari Sangli ; Shraddha Hegde 
; Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Hi Srihari,
I am not able to find the text about fallback in the version 07 of the draft. I 
may have misunderstood but I thought Shraddha was proposing new text to cover 
fallback in the draft.

The draft refers to “SRv6 service with best-effort connectivity” and to “SRv6 
service in conjunction with an underlay SLA”. I would propose to change these 
to “SRv6 service using shortest path in base or a flex-algo topology” and “SRv6 
service using SRv6 policy” respectively.

As for fallback, it is really an implementation option and vendors may 
implement different things based on their customer requirements. I am not sure 
it should be discussed in this draft.
[Jim U>] Fallback should be addressed as it needs to be consistent.

Regards,
Mustapha.

From: Srihari Sangli mailto:ssan...@juniper.net>>
Sent: Tuesday, July 20, 2021 10:55 AM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Shraddha 
Hegde 
mailto:shraddha=40juniper@dmarc.ietf.org>>;
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)

Mustapha,

I think Shraddha is pointing about the paragraph “When providing best-effort 
connectivity…” where it specifically talks about fallback to best-effort and if 
so, perform the resolvability check on the service-SID. Going by what you are 
saying that its general behavior of SRv6 policy, there is no need to over 
specify that it SHOULD check for resolvability and need for SRH.

srihari…


On 20/07/21, 7:24 PM spring on behalf of Aissaoui, Mustapha (Nokia - CA/Ottawa) 
from spring-boun...@ietf.org on behalf of 
mustapha.aissa...@nokia.com said >

[External Email. Be cautious of content]

Hi Shraddha,
An implementation can allow any fallback strategy, including multiple levels of 
fallback, but the backup path you are describing is simply the general behavior 
of a SRv6 policy. The End SID is part of the SRv6 policy segment list and is 
the top SID. So, the service SID will indeed be pushed into a SRH and the End 
SID is looked up by the ingress PE to forward the packet. It does not matter if 
the End SID is from base topology of from a flex-algo topology.

Regards,
Mustapha.

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





“When providing best-effort connectivity or flex-algo 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.

“

“In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths when a flex-algo path isn’t available. The fallback behavior

SHOULD be governed by local policies.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case.”





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don’t intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) 
to decide to 

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

[UTTARO, JAMES]

Comments In-Line..

Thanks,
  Jim Uttaro

From: spring  On Behalf Of Shraddha Hegde
Sent: Tuesday, July 20, 2021 5:56 AM
To: Robert Raszuk 
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: [spring] SRv6 BGP based Overlay Services 
(draft-ietf-bess-srv6-services-07)



Good to know the intention is to support fallback for Srv6.



The way current text is written, it implies service SID is always in the 
destination address.

And hence service SID should be resolvable. This is not the case when a service 
SID

Corresponding to flex-algo wants to fallback on best effort services. The 
destination address cannot carry

Service SID for fallback cases and hence it need not be resolved.



I suggest that the authors add below text in bold to the draft.





"When providing best-effort connectivity or flex-algo 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.

"

"In some cases a service prefix intending to use flex-algo paths may want 
fallback on

best effort paths when a flex-algo path isn't available. The fallback behavior

SHOULD be governed by local policies.

[Jim U>] It would be helpful to provide an example of local policies and how 
would/should said local policies be applied across a heterogeneous network.

The destination address SHOULD contain the best-effort locator based END SID

of the egress PE and the SRH SHOULD contain the service SID. Service SID

resolvability SHOULD NOT be checked on the ingress for this case."





Rgds

Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 12:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: spr...@ietf.org; bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

> that authors don't intend to support any form of tunnelling for SRv6
> because it is not optimal. Is that the right read?

Quite the opposite. It is the local operator's choice (not the draft authors) 
to decide to fall back to best effort or to drop.

Thx,
R.



On Tue, Jul 20, 2021 at 8:15 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Robert,

What do you mean by SR? is it SR-MPLS or SRv6.
My question is about draft-ietf-bess-srv6-services and applies only to SRv6.

Let me repeat the question.
Do the authors intend to support the case of fallback from SRv6 flex-algo to 
SRv6 best effort transport for SRv6
Services or not?

>From your vague answer it appears that authors don't intend to support any 
>form of tunnelling for SRv6
because it is not optimal. Is that the right read?

Rgds
Shraddha



Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, July 20, 2021 11:17 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; Rabadan, 
Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; Rajesh M 
mailto:mraj...@juniper.net>>; Rajesh M 
mailto:40juniper@dmarc.ietf.org>>; 
Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
gdawra.i...@gmail.com; Clarence Filsfils 
(cfilsfil) mailto:cfils...@cisco.com>>; 
bruno.decra...@orange.com; 
spr...@ietf.org; b...@ans.net; 
Srihari Sangli mailto:ssan...@juniper.net>>; 
bess@ietf.org
Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07)

[External Email. Be cautious of content]

Shraddha,

In an SR network fallback to best effort will also result in encapsulated 
forwarding using SR. It may not be as optimal service wise as using flex-algo, 
but this is form of tunneling. Hence I don't think your comment applies.

Note that operator may also choose to use IP tunneling for best effort 
forwarding if SR best effort forwarding is not supported or enabled.

Best,
R.




On Tue, Jul 20, 2021 at 7:20 AM Shraddha Hegde 
mailto:shrad...@juniper.net>> wrote:
Hi Authors,

There is a possibility of a usecase that wants to use flex-algo paths if 
available and if flex-algo paths
Are not available use best effort paths.


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

The current text says for best effort 

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[UTTARO, JAMES]

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk 
Cc: Jeff Tantsura ; Arie Vayner ; 
bess@ietf.org; Satya Mohanty (satyamoh) 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet uniform 50/50 load balancing at 
the L2 VNI overlay layer, which translates into underlay load balancing of 
flows and thus no polarization.

Across the DC space speaking from an operators perspective as under the floor 
fiber is not at a premium compare to 100G facilities costs the net addition of 
bandwidth can be done fairly quickly so you are ahead of the congestion curve 
and can be proactive versus reactively upgrading bandwidth piecemeal here and 
there ad hoc.

There still maybe cases that still arise as even if you have the fiber 
infrastructure available, it’s not easy to upgrade and flash every link 
simultaneously in the DC in one or multiple maintenance windows, so you could 
still be left with some uneven bandwidth across the DC that could utilize this 
feature.

DC comes into play for PE-CE “wan links”as well  use case for unequal cost load 
balancing use of the cumulative link bandwidth community regenerated.


I think the use case where both the iBGP P core P-P links  or eBGP PE - PE 
inter-as are all wan links where link upgrades tend to not get done in unison 
uniformly, and in those cases both iBGP link bandwidth community can be heavily 
utilized as well as eBGP cumulative regenerated link bandwidth community for 
unequal cost  load balancing.  Across the core as well it is hard to flash all 
links even under floor fiber to the same bandwidth all at once you are left 
with the requirement for unequal coat load balancing.

As operators upgrade their DC as well as core infrastructure to IPv6 forwarding 
plane in the move towards SRv6, they can now take advantage of flow label 
entropy stateless uniform load balancing and elimination of polarization.  
However, the wan link upgrades of core and DC PE-CE still exists and thus may 
be done piecemeal, so then both of the drafts are an extremely helpful tool for 
operators that much need the unequal cost load balancing capability.

I support both drafts.

Have most vendors implemented this to support both 2 byte and 4 byte AS 
extended community.  The drafts state 2 byte AS support.

Thanks

Gyan

On Tue, May 25, 2021 at 7:00 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP. It 
does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just ask 
for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's bw 
across few EBGP hops in the DC. Today there is no way to do so unless you want 
to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather poorly 
for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in another 
draft.
Gyan  - please note, while pretty much every vendor has implemented the 
community and relevant data-plane constructs, initial draft defines the 
community as non transititive, some vendors have followed that while some other 
have implemented it a transitive (to support obvious use case - eBGP in DC).


Cheers,
Jeff
On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>, wrote:

Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
  and subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the link bandwidth extended community 

Re: [bess] WG adoption and IPR poll for draft-brissette-bess-evpn-l2gw-proto

[UTTARO, JAMES]

Support the adoption.

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Aparna Pattekar (apjoshi)
Sent: Friday, April 09, 2021 4:17 PM
To: slitkows.i...@gmail.com
Cc: bess@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-brissette-bess-evpn-l2gw-proto

Support the adoption.


On Mar 29, 2021, at 12:05 AM, 
slitkows.i...@gmail.com wrote:

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-l2gw-proto [1].

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 will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures 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 April 12th 2021.

Regards,
Matthew and Stephane


[1] 
https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-l2gw-proto/

___
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-irb-extended-mobility-01

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of LINGALA, AVINASH
Sent: Tuesday, February 02, 2021 4:20 AM
To: slitkows.i...@gmail.com; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Hi,

Support as co-author. Not aware of any undisclosed IPR.

Thanks,
Avinash

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>
Date: Monday, January 18, 2021 at 3:58 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-irb-extended-mobility-01


This email starts a two-week working group last call for 
draft-ietf-bess-evpn-irb-extended-mobility-01 [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 February 1st.







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.


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-irb-extended-mobility/
[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 adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Satya Mohanty (satyamoh)
Sent: Friday, January 08, 2021 12:16 PM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: draft-mohanty-bess-weighted-...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-mohanty-bess-weighted-hrw-01

Support as co-author and not aware of any undisclosed IPR.

Thanks,
--Satya

From: "Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Wednesday, December 9, 2020 at 1:23 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: 
"draft-mohanty-bess-weighted-...@ietf.org"
 
mailto:draft-mohanty-bess-weighted-...@ietf.org>>
Subject: WG adoption and IPR poll for draft-mohanty-bess-weighted-hrw-01
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:satya...@cisco.com>>, 
mailto:manka...@cisco.com>>, 
mailto:a...@cisco.com>>, 
mailto:saja...@cisco.com>>, 
"jdr...@juniper.net" 
mailto:jdr...@juniper.net>>
Resent-Date: Wednesday, December 9, 2020 at 1:22 AM

Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-weighted-hrw-01 [1].

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 will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures 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 23rd December 2020.

Regards,
Matthew and Stephane

[1]  
https://datatracker.ietf.org/doc/draft-mohanty-bess-weighted-hrw/



___
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-02

[UTTARO, JAMES]

Support. I am unaware of any IPR..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of John E Drake
Sent: Tuesday, January 05, 2021 9:25 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org; 
draft-ietf-bess-evpn-vpws-...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc-02

Support, not aware of any IPR

Yours Irrespectively,

John



Juniper Business Use Only
From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Sent: Monday, January 4, 2021 6:13 AM
To: bess@ietf.org; 
draft-ietf-bess-evpn-vpws-...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc-02

[External Email. Be cautious of content]

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc-02 [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 18th January 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] [Idr] XXCs

[UTTARO, JAMES]

Not sure if the intention here intersects with what I had in mind in 2012.. 
Pradosh, Saikat and I created a draft that introduced the notion of OAD ( One 
Administrative Domain ). The challenge from my point of view was and still is 
how to treat non-transitive attributes as transitive across the set of AS 
domains that “belong” to the same administrative domain. An example of this is 
the application of Local-Pref across a set of disparate As domains that a 
customers VPN spans.

We are tackling a similar problem when spanning AS domains that are reflective 
of differing services.. i.e  a customer VPN spans EVPN and 2547 signaling 
domains.

https://tools.ietf.org/html/draft-uttaro-idr-oad-01

https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

Thanks,
  Jim Uttaro

From: Idr  On Behalf Of Robert Raszuk
Sent: Wednesday, April 08, 2020 10:41 AM
To: Jakob Heitz (jheitz) 
Cc: idr@ietf. org 
Subject: [Idr] XXCs

Hey Jakob,

So just an idea - if we are to redefine transitivity for XXC why don't we 
forget about all of this ASN reservations and simply instead of two transitive 
bits define three.

Make 3rd bit to mean transitive only under set of ASes under same 
administrative control ?

You still need a knob to know which ASNs are to be treated as same 
administration. And with that no change to community syntax  is needed at all - 
LOCAL_ASN:NUMBER

Done !

Thx,
R.




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

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[UTTARO, JAMES]

Jeffrey,

  I was unaware that local bias had been standardized. Will take a 
read..

Thanks,
  Jim Uttaro

From: Jeffrey (Zhaohui) Zhang 
Sent: Wednesday, March 04, 2020 10:54 AM
To: UTTARO, JAMES ; Gyan Mishra ; BESS 

Subject: RE: [bess] VXLAN EVPN fabric extension to Hypervisor VM

EVPN/VLXAN uses Local Bias method for MH split horizon, which is specified in 
RFC 8365.

Extending EVPN to servers don’t require new IETF standards – the servers just 
need to support existing relevant standards. Having said that, with many 
servers in the underlay, routing in the underlay needs to be able to scale 
well. For that you can run BGP in the underlay (RFC 7938), or RIFT 
(draft-ietf-rift-rift), or LSVR (draft-ietf-lsvr-bgp-spf).

Jeffrey

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
UTTARO, JAMES
Sent: Wednesday, March 4, 2020 7:17 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>; BESS 
mailto:bess@ietf.org>>
Subject: Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

Gyan,

  One of the big advantages of EVPN is the MLAG capability without 
the need for proprietary MLAG solutions. We have been actively testing EV-LAG 
to accomplish this in the WAN for L2 services.. That being said, we use 
EVPN/MPLS where MH ( EV-LAG ) is conveyed via labels.. My understanding is that 
when using EVPN/VXLAN proprietary mechanisms are need to make EV-LAG work.. The 
is no SH label..

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Gyan Mishra
Sent: Monday, March 02, 2020 6:26 PM
To: BESS mailto:bess@ietf.org>>
Subject: [bess] VXLAN EVPN fabric extension to Hypervisor VM


Dear BESS WG

Is anyone aware of any IETF BGP development in the Data Center arena to extend 
BGP VXLAN EVPN to a blade server Hypervisor making the Hypervisor part of the  
vxlan fabric.  This could eliminate use of MLAG on the leaf switches and 
eliminate L2 completely from the vxlan fabric thereby maximizing  stability.

Kind regards,

Gyan
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>


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

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[UTTARO, JAMES]

Gyan,

  The following draft may also be of interest. AT ( A.Lingala ) 
has co-authored a draft that addresses unequal load balancing within a data 
center.. This draft intends to optimize the use of links of different size 
within the data center to fully utilize the capacity of the links from the 
leaf’s to the servers..

https://tools.ietf.org/html/draft-ietf-bess-evpn-unequal-lb-03

Thanks,
  Jim Uttaro

From: Jeff Tantsura 
Sent: Wednesday, March 04, 2020 10:47 AM
To: Gyan Mishra ; BESS ; UTTARO, JAMES 

Subject: Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

James,

ESI multihoming (load-sharing) works just fine with VxLAN encapsulation (when 
supported), there’s no need for additional (proprietary) mechanisms (at least 
with basic synchronization).

Gyan - the devil is in the details (as always) - I’m looking at multivendor 
EVPN VxLAN ESI designs as we speak, I’m yet to figure out how ESI type 3 (only 
ESI type supported in NX-OS) is going to work with ESI types 0/1 supported in 
Junos and Arista. I’d assume upcoming open source implementations will support 
type 0 (manual) only.

To second James - replacing MLAG with ESI multihoming could be a really big 
deal in terms of simplification and normalization of the fabric (and you could 
finally remove peer-links!).
L2 vs L3 discussion is somewhat orthogonal to that, if your services require 
stretched L2, whether your VTEPs are on a server or switch - you’d still be 
doing L2overL3.

I still wouldn’t dare to deploy multivendor leafs though, but one step at a 
time ;-)

Cheers,
Jeff
On Mar 4, 2020, 10:17 AM -0500, UTTARO, JAMES 
mailto:ju1...@att.com>>, wrote:

Gyan,

  One of the big advantages of EVPN is the MLAG capability without 
the need for proprietary MLAG solutions. We have been actively testing EV-LAG 
to accomplish this in the WAN for L2 services.. That being said, we use 
EVPN/MPLS where MH ( EV-LAG ) is conveyed via labels.. My understanding is that 
when using EVPN/VXLAN proprietary mechanisms are need to make EV-LAG work.. The 
is no SH label..

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Gyan Mishra
Sent: Monday, March 02, 2020 6:26 PM
To: BESS mailto:bess@ietf.org>>
Subject: [bess] VXLAN EVPN fabric extension to Hypervisor VM


Dear BESS WG

Is anyone aware of any IETF BGP development in the Data Center arena to extend 
BGP VXLAN EVPN to a blade server Hypervisor making the Hypervisor part of the  
vxlan fabric.  This could eliminate use of MLAG on the leaf switches and 
eliminate L2 completely from the vxlan fabric thereby maximizing  stability.

Kind regards,

Gyan
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>


___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwQFaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=fDyO1T8959Mh1nCyB_DTHbuaJUWs7wQ01X_Pd18tPg0=sySZWuq5YBFtsqh6Y6wIrU5SDUpVQaB-cxlVNTZ84g8=>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] VXLAN EVPN fabric extension to Hypervisor VM

[UTTARO, JAMES]

Gyan,

  One of the big advantages of EVPN is the MLAG capability without 
the need for proprietary MLAG solutions. We have been actively testing EV-LAG 
to accomplish this in the WAN for L2 services.. That being said, we use 
EVPN/MPLS where MH ( EV-LAG ) is conveyed via labels.. My understanding is that 
when using EVPN/VXLAN proprietary mechanisms are need to make EV-LAG work.. The 
is no SH label..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Gyan Mishra
Sent: Monday, March 02, 2020 6:26 PM
To: BESS 
Subject: [bess] VXLAN EVPN fabric extension to Hypervisor VM


Dear BESS WG

Is anyone aware of any IETF BGP development in the Data Center arena to extend 
BGP VXLAN EVPN to a blade server Hypervisor making the Hypervisor part of the  
vxlan fabric.  This could eliminate use of MLAG on the leaf switches and 
eliminate L2 completely from the vxlan fabric thereby maximizing  stability.

Kind regards,

Gyan
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com


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

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-irb-mcast-04

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Wen Lin
Sent: Wednesday, February 26, 2020 11:07 PM
To: slitkows.i...@gmail.com; 'BESS' 
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-irb-mcast-04

Support as co-author.  I am unaware of any undisclosed IPRs.

Thanks,
Wen

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>
Date: Wednesday, February 26, 2020 at 9:26 AM
To: 'BESS' 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-evpn-irb-mcast-04

Hi WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-irb-mcast-04 [2]

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 11th March 2020.


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 one IPR disclosed.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-irb-mcast



We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations.

 Thank you,

Stephane

[1] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
[2] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/

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

Re: [bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of zhang.zh...@zte.com.cn
Sent: Tuesday, February 04, 2020 9:00 AM
To: slitkows.i...@gmail.com
Cc: bess-cha...@ietf.org; draft-wsv-bess-extended-evpn-optimized...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption and IP poll 
fordraft-wsv-bess-extended-evpn-optimized-ir


I read this draft and support the adoption.



Thanks,

Sandy


原始邮件
发件人：slitkows.i...@gmail.com 
mailto:slitkows.i...@gmail.com>>
收件人：'BESS' 
mailto:bess@ietf.org>>;draft-wsv-bess-extended-evpn-optimized...@ietf.org
 
mailto:draft-wsv-bess-extended-evpn-optimized...@ietf.org>>;
抄送人：bess-cha...@ietf.org 
mailto:bess-cha...@ietf.org>>;
日 期 ：2020年02月04日 21:50
主 题 ：[bess] WG adoption and IP poll fordraft-wsv-bess-extended-evpn-optimized-ir
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Hi,

This email begins a two-weeks WG adoption poll for 
draft-wsv-bess-extended-evpn-optimized-ir [1]
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 are no IPR disclosures 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 18th Feb 2020.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-wsv-bess-extended-evpn-optimized-ir/


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

Re: [bess] WG Adoption and IPR Poll for draft-brissette-bess-evpn-mh-pa-04

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Sami Boutros
Sent: Tuesday, January 21, 2020 2:26 PM
To: Bocci, Matthew (Nokia - GB) 
Cc: draft-brissette-bess-evpn-mh...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-brissette-bess-evpn-mh-pa-04

Support,

Sami
Sent from my iPhone


On Jan 21, 2020, at 6:48 AM, Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-mh-pa-04 [1] .

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 are no IPR disclosures 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 Tuesday 4th February 2020.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-mh-pa/





___
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] WGLC , IPR and implementation poll for draft-ietf-bess-evpn-unequal-lb-03

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Friday, January 17, 2020 3:56 AM
To: bess@ietf.org; draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC , IPR and implementation poll for 
draft-ietf-bess-evpn-unequal-lb-03

Hi WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-unequal-lb-03 [2]

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 Fri 31th January 2019.


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.

We are also polling for any existing implementation as per [1]. Please indicate 
if you are aware of any implementations.

 Thank you,

Stephane

[1] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
[2] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Adoption and IPR Poll for draft-litkowski-bess-rfc5549revision-00

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Wednesday, November 27, 2019 8:49 AM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Support.

Thx
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"Bocci, Matthew (Nokia - GB)" 
mailto:matthew.bo...@nokia.com>>
Date: Wednesday, November 27, 2019 at 1:37 PM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG Adoption and IPR Poll for 
draft-litkowski-bess-rfc5549revision-00

Hello,

This email begins a two-weeks WG adoption poll for 
draft-litkowski-bess-rfc5549revision-00 [1] .

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 are no IPR disclosures 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 Wednesday 11th December 2019.

Regards,
Matthew

[1] 
https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/



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

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[UTTARO, JAMES]

Support for WG adoption..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Saturday, August 24, 2019 6:41 AM
To: Stephane Litkowski ; bess@ietf.org
Subject: Re: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

As a co-author, I support this document for WG adoption.
I’m not aware of any IPR relevant to this document.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Stephane Litkowski mailto:slitkows.i...@gmail.com>>
Date: Tuesday, August 20, 2019 at 11:15 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-07 [1]
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 are no IPR disclosures 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 2nd September 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[UTTARO, JAMES]

Could the authors provide further insight on the following..

“   The intend of this new Type is to allow operators and vendors to
   design rapidly new EVPN applications/prototypes and experiment with
   them in deployed networks before standardizing the specific
   application. Software Defined Networks (SDN) are evolving fast and
   the flexibility allowed by this new Route Type will contribute to the
   SDN control plane evolution.”

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Jeff Tantsura
Sent: Tuesday, August 20, 2019 1:24 PM
To: bess@ietf.org; Stephane Litkowski 
Subject: Re: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

In general I support the adoption.

Could the authors please clarify how a company that doesn’t have OUI assigned 
should populate the OUI field and how interdependency between IEEE registration 
and EVPN implementation would be handled.

Informal references for IEEE OUI handling process would be useful too, perhaps 
this one - 
https://standards.ieee.org/products-services/regauth/tut/index.html

Cheers,
Jeff
On Aug 20, 2019, 5:15 AM -0400, Stephane Litkowski 
mailto:slitkows.i...@gmail.com>>, wrote:

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-07 [1]
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 are no IPR disclosures 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 2nd September 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
___
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] EVPN VPWS BDF forwarding behavior at MH site

[UTTARO, JAMES]

Gangadhar,

  Do you have a picture describing the desired behavior..

Thanks,
  Jim Uttaro

From: gangadhara reddy chavva 
Sent: Monday, August 12, 2019 9:46 AM
To: UTTARO, JAMES 
Cc: Thirumavalavan Periyannan (thiperiy) ; bess@ietf.org
Subject: Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Yes, Jim Uttaro, it is related to FXC, please let me know your comments on the 
below proposal.

Regards,
Gangadhar

On Mon, Aug 12, 2019 at 6:45 PM UTTARO, JAMES 
mailto:ju1...@att.com>> wrote:
I assume this discussion applies to FXC ( Flexible Cross Connect )..

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
gangadhara reddy chavva
Sent: Saturday, August 10, 2019 7:29 AM
To: Thirumavalavan Periyannan (thiperiy) 
mailto:thipe...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Hi Thiru,

here is the clarifications for your questions.

this is basically primary PE reach ability /  availability can be determined 
through BFD/Multihop BFD, in this case FRR switch can happen very quickly at 
the remote PE, control plane convergence later.

please see in line answers for the below questions:
for faster convergence if we can install the route such that BDF can allow the 
traffic from remote PE towards to multi homed segment, we can forward the 
traffic received from the remote PE.

Gangadhar >> this explains the route programming at multi homed site, if 
elected PE is BDF, program the label path, so that traffic received from remote 
PE will be send to multi homed CE.

at the same time we shouldn't allow the traffic from multi homed site this 
leads to duplicate traffic on the remote PE. to achieve this we should not 
program the path from multi home site towards remote PE until this PE elected 
as DF for that VPWS instance.

Gangadhar >> again this is at BDF, we shouldn't allow the traffic from multi 
homed site CE to remote PE, for this BDF should not program the path towards 
remote PE, so at BDF if there is any traffic from CE will be get  dropped at 
BDF.


I hope this will clarify your question.

Regards,
Gangadhar



On Sat, Aug 10, 2019 at 2:50 AM Thirumavalavan Periyannan (thiperiy) 
mailto:thipe...@cisco.com>> wrote:
Hello Gangadhara,

How remote PE detect the DF failure? It’s based on EVI/AD Withdraw message from 
DF PE if so then NDF PE also received this route and changed its DF status at 
the same time Remote PE changed its nexthop to NEW DF PE.

The below info is not clear, could you please help me to understand.

for faster convergence if we can install the route such that BDF can allow the 
traffic from remote PE towards to multi homed segment, we can forward the 
traffic received from the remote PE.

at the same time we shouldn't allow the traffic from multi homed site this 
leads to duplicate traffic on the remote PE. to achieve this we should not 
program the path from multi home site towards remote PE until this PE elected 
as DF for that VPWS instance.

Thanks,
Thiru

On 09-Aug-2019, at 19:02, gangadhara reddy chavva 
mailto:meetgangadh...@gmail.com>> wrote:
HI All,

i have one question on EVPN VPWS BDF forwarding behavior at MH site.
when PE is selected as BDF, it will communicate the EAD EVI route with B bit 
set to remote PE. so remote PE will install the FRR route with primary path 
towards DF PE and secondary path towards BDF.
when ever primary path get disconnected it will switch the path to secondary 
path quickly at remote PE. because of this data from the remote PE will reach 
to BDF very quickly, but if BDF is not programmed its path towards multi homed 
segment then traffic will be get dropped until control plane convergence and it 
will be elected as DF.

for faster convergence if we can install the route such that BDF can allow the 
traffic from remote PE towards to multi homed segment, we can forward the 
traffic received from the remote PE.

at the same time we shouldn't allow the traffic from multi homed site this 
leads to duplicate traffic on the remote PE. to achieve this we should not 
program the path from multi home site towards remote PE until this PE elected 
as DF for that VPWS instance.

can you please let me know if there are any problems with this kind of 
approach..



Regards,
Gangadhar






___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=dw_cbEJEFGb2ttG_aLztLllgQ6WbTf5f6YdWdNY3Sgo=VYEDWxQx9AA9mJMDxJ8_BoKV0xANI0ORk2zfcb3cfF4=>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [Idr] [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[UTTARO, JAMES]

+1

From: Idr  On Behalf Of Robert Raszuk
Sent: Wednesday, June 26, 2019 7:53 AM
To: Xiejingrong 
Cc: i...@ietf.org; ian.far...@telekom.de; ianfar...@gmx.com; 
softwi...@ietf.org; bess@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address 
coding for IPv4 VPN over IPv6 Core in RFC5549

All,

RD is a property of the NLRI not next hop. I am not sure where in this thread 
or some spec someone came to the conclusion that next hop field should contain 
an RD. RD is not useful there and should never be part of any next hop field.

Remember RD role is to make prefix unique - that's it - no more no less. Next 
hop uniqness is given by architecture and there is no need to make it unique.

In some cases when we need to carry IPv4 address in IPv6 next hop field (there 
was historically some assumption that next hop must be of the same AF as 
prefix) we prepend to it numerical zeros.

Thx,
R.





On Wed, Jun 26, 2019 at 1:40 PM Xiejingrong 
mailto:xiejingr...@huawei.com>> wrote:
Hi folks,

I guess this is an inconsistency due to past carelessness. Is there anyone can 
tell us the history of this inconsistency ?
RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6 network) 
both require to use RD+IP(v4 or v6 respectively) as nexthop.
RFC5549(VPNv4/IPv4 over IPv6 network) requires to use IPv6 without RD as 
nexthop.
This same question also occur in MVPN: RFC6515, which talks about MVPN6 over 
IPv4/IPv6, or MVPN over IPv6, but does imply loosely to use IPv4/IPv6 without 
RD as nexthop (see below).
   The purpose of this document is to make clear that whenever a PE
   address occurs in an MCAST-VPN route (whether in the NLRI or in an
   attribute), the IP address family of that address is determined by
   the length of the address (a length of 4 octets for IPv4 addresses, a
   length of 16 octets for IPv6 addresses), NOT by the AFI field of the
   route.

My suggestion: implementation should interpret nexthop RD+IPv4 and nexthop IPv4 
the same, and interpret nexthop RD+IPv6 and nexthop IPv6 the same.
The RFC5549/SRv6-VPN/RFC6515 can keep as current shape, while interoperate can 
meet between different implementations.
Need a new draft to clarify this and to give a guide on further FooService over 
FooNetwork ?

Thanks
Jingrong

From: Softwires 
[mailto:softwires-boun...@ietf.org] On 
Behalf Of ian.far...@telekom.de
Sent: Tuesday, June 25, 2019 11:12 PM
To: Zhuangshunwan mailto:zhuangshun...@huawei.com>>; 
ianfar...@gmx.com
Cc: softwi...@ietf.org; 
bess@ietf.org
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi Shunwan,

I’ve just re-checked RFC5539, and the referenced section 3 of RFC2545 and I can 
find nothing about using VPN-IPv6 for encoding the next-hop. Section 3 of 
RFC5539 is very clear that it’s a 16-byte GU IPv6 address or 32-bytes with a GU 
and LL address.

Can you point me to the text that gives you the impression that VPN-IPv6 is 
correct?

Note – I see that there is reported Errata on RFC5549, (not verified) saying 
that the length should be 24 or 48 to include the RD. However, as mentioned 
above, the supporting text in multiple places in the RFC and its references 
support the use of an IPv6 address (or 2) with no RD at 16 or 32 bytes, so this 
does seem to be the intention of the document as written.
https://www.rfc-editor.org/errata_search.php?rfc=5549

Thanks,
Ian

From: Softwires mailto:softwires-boun...@ietf.org>> 
on behalf of Zhuangshunwan 
mailto:zhuangshun...@huawei.com>>
Date: Tuesday, 25. June 2019 at 13:18
To: "ianfar...@gmx.com" 
mailto:ianfar...@gmx.com>>
Cc: "softwi...@ietf.org" 
mailto:softwi...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 
VPN over IPv6 Core in RFC5549

Hi Ian,

Thanks for your response!

The opinion I have collected is:
Per RFC4634, the IPv4-VPN routes shall carry the V4 Next-hop, beginning with an 
8-octet RD and ending with a 4-octet IPv4 address.
Per RFC4659, the IPv6-VPN routes shall carry the V6 Next-hop, beginning with an 
8-octet RD and ending with a 16-octet IPv6 address.
When we start to implement the IPv4 VPN over IPv6 Core,  it is a natural way to 
encode the IPv4-VPN routes with VPN-IPv6 next-hop (i.e. beginning with an 
8-octet RD and ending with a 16-octet IPv6 address) .

I believe this is not just a minority opinion, and some of the current 
implementations are also doing this way.

I hope that the 

Re: [bess] WG adoption poll and IPR poll for draft-boutros-bess-evpn-geneve

[UTTARO, JAMES]

Support

Jim Uttaro

From: BESS  On Behalf Of Jeff Tantsura
Sent: Thursday, June 06, 2019 1:54 AM
To: stephane.litkow...@orange.com
Cc: aldrin.i...@gmail.com; bess-cha...@ietf.org; bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-boutros-bess-evpn-geneve

Stephane,

I support the adoption.
Cheers,
Jeff

On Jun 5, 2019, at 11:53, 
mailto:stephane.litkow...@orange.com>> 
mailto:stephane.litkow...@orange.com>> wrote:
Hi WG,

We are currently missing the IPR reply from Sam to clear the IPR poll.
In addition, we lack of significant support for this draft, however we haven’t 
seen any objection yet.
We, chairs, think that this document is an important piece of work as GENEVE is 
the standard overlay from NVO3 WG.

I’m extending the poll for an additional week to hear about additional support 
but also objections to adopt the document.

The polls now ends on June 12th.

Brgds,

Stephane



From: stephane..litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Wednesday, May 22, 2019 15:55
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption poll and IPR poll for draft-boutros-bess-evpn-geneve

Hi,


This email begins a two-week poll for adoption of 
draft-boutros-bess-evpn-geneve-04[1]

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 are no IPR disclosures 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 5th June 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-boutros-bess-evpn-geneve/

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may 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] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

[UTTARO, JAMES]

Ryan,

  My take here is that we are trying to approach the notion of 
routing to the "customer" without actually routing.. PE2 and PE3 never receive 
the MAC as expected in data plane learning.. This is forcing the MAC via the 
origination at PE2 and PE3 to seem like it was "learned" there. The notion of 
EVPN was Data Plane learning to the customer, control plane learning to in the 
EVPN signaling domain. Why can't the state simple be persisted if there are 
still valid PEs ( PE2, PE3 ) the ESI.. IMO this seems to accomplish your goal 
without changing the paradigm. I believe the draft below comes close to what 
you want.. addl text would be needed to persist if ESI is valid..

Thanks,
  Jim Uttaro

https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-persistence-04.txt

From: BESS  On Behalf Of Ryan Bickhart
Sent: Friday, March 29, 2019 3:38 PM
To: Sandy Breeze ; bess@ietf.org
Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Sandy,

It is intentional that PE4 sees an RT2 for the CE1 MAC/IP advertised from PE2 
and PE3 as well as PE1. The reason is that we want to cover the transition 
cases of link or node failure occurring on PE1. PE4 might be using CE1's IP 
carried in the RT2 for IRB or routing purposes and it is desirable for PE4 to 
maintain constant awareness of the existence of the CE1 IP across failures on 
PE1. Under normal 7432 behavior, if PE1 were the only PE advertising the RT2 
for CE1's MAC/IP and PE1's link to the multihomed site goes down, PE1 might 
withdraw the RT2 before PE2/PE3 are able to learn the CE1 IP->MAC binding in 
the data plane and advertise it as a RT2 to PE4. By having PE2/PE3 originate 
the proxy advertisements, we avoid the case where the CE1 MAC/IP might 
completely disappear and later reappear in the EVPN when there is a failure on 
PE1. (Maybe a general L2 way of phrasing this concept is that you can do 
aliasing only for entities that you know about. If there is no trace of a MAC's 
existence left in the EVPN, you would flood rather than use aliasing.)

Thanks,
-Ryan




Juniper Internal
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: bess@ietf.org
Subject: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Wen,

First, thank you for this work, I see the problem you're trying to solve and 
support trying to do that.  I have some questions.

Lets say for example, PEs: 1,2,3 have CE1 attached on the same all-active ES.  
PE4 is a remote PE participating in the same EVPN.  CE1's MAC/IP is learned in 
the dataplane by PE1 only, and PE1 originates the RT2 initially.

At this point, with standard 7432 mechanisms, PE4 can already have aliasing and 
backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 from either 
PE2 or PE3.  What PE2 and PE3 might be missing locally, however, is ARP/ND 
state for CE1, which is and which your draft looks to solve in BGP..  (If my 
understanding is correct?)

Now if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND upon 
receipt of the RT2 from PE1.  Why do PE2 and PE3 then need to originate their 
own RT2?  If they originate RT2's then this can influence the forwarding 
decisions at other remote PE's like PE4, who lets say doesn't understand the 
proxy-adv bit in the ARP/ND extended community and will see the RT2 as 
originating from 3 different PE's.  Is that the intention of the draft or just 
a consequence?  Or is it the intention to keep the proxy-adv mechanism for use 
amongst the multihomed PE's only?

Thanks
Sandy

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

[bess] Mail regarding draft-rbickhart-evpn-ip-mac-proxy-adv

[UTTARO, JAMES]

Wen,

  A few comments.

  I think I understand the why of this draft. One could take the 
view that a MAC/IP learned via a single PE on an ESI has actually gone away and 
will not be re-learned via other PEs on said ESI.. In that case incorrectness 
is being injected into the VPN state machine for said customer for as long as 
it takes the timer to expire. Is that right??

Generally speaking state learned via the control plane is never allowed to be 
re-advertised so PE1->PE2->PEX is disallowed. I am assuming that split horizon 
will be disabled for a MAC/IP learned from PE1 advertised to PE2, subsequently 
advertised to PE3 ( Actually everywhere ) as the ESI is in common.

You could also use BGP Persistence on PE3.. PE3 would enable persistence on 
MAC/IP:NH=PE1, ESI10 if ESI10 is also available at PE2.. In this manner PE3 
would continue sending traffic to MAC/IP via PE2 as long as the ESI is valid 
and the timer on PE3 did not expire.


Thanks,
  Jim Uttaro




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

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Krishna Muddenahally 
Ananthamurthy (kriswamy)
Sent: Wednesday, March 27, 2019 2:58 AM
To: stephane.litkow...@orange.com; bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

I support.

Thanks
Krishna


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
"stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Tuesday, March 5, 2019 at 9:43 AM
To: "bess@ietf.org" 
mailto:bess@ietf.org>>, 
"draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org"
 
mailto:draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-04
[1]

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 are no IPR disclosures 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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[UTTARO, JAMES]

Support

Jim Uttaro

From: BESS  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 20, 2019 9:08 AM
To: stephane.litkow...@orange.com; bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

I support WG adoption. The draft precisely defines the host mobility for EVPN 
IRB and the attendant route types.
Thanks,
Acee


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>
Date: Wednesday, March 20, 2019 at 8:53 AM
To: Stephane Litkowski 
mailto:stephane.litkow...@orange.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org"
 
mailto:draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org>>
Cc: "bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi WG,

Apart from the authors, we haven’t received a lot of feedback for this draft 
(positive or negative).
I would like to expand the poll to an additional week (ends at 26th March) to 
see if we can get more support on the list.

Brgds,

From: stephane..litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 05, 2019 09:43
To: bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-04
[1]

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 are no IPR disclosures 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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without 

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[UTTARO, JAMES]

Support..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of John E Drake
Sent: Monday, March 18, 2019 5:23 PM
To: mitesh kanjariya ; bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org; 
stephane.litkow...@orange.com
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Support

Yours Irrespectively,

John

From: mitesh kanjariya 
mailto:mitesh.kanjar...@gmail.com>>
Sent: Monday, March 18, 2019 4:49 PM
To: bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org;
 stephane.litkow...@orange.com
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04


Support.



-Mitesh





Hi,



This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-04

[1]



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 are no IPR disclosures 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 19th March 2019.



Regards,

Stephane and Matthew



[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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.









--

Regards,

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

Re: [bess] WG adoption and IPR poll for draft-malhotra-bess-evpn-irb-extended-mobility-04

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 05, 2019 10:53 AM
To: stephane.litkow...@orange.com; bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Support… not aware of any IPR..

-Avinash

​
From: stephane.litkow...@orange.com 
mailto:stephane.litkow...@orange.com>>
Sent: Tuesday, March 05, 2019 3:43 AM
To: bess@ietf.org; 
draft-malhotra-bess-evpn-irb-extended-mobil...@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-malhotra-bess-evpn-irb-extended-mobility-04

Hi,


This email begins a two-week poll for adoption of 
draft-malhotra-bess-evpn-irb-extended-mobility-04
[1]

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 are no IPR disclosures 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 19th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-irb-extended-mobility/



_



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] WG adoption and IPR poll for draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02

[UTTARO, JAMES]

As co-author

Support.

Not aware of any undisclosed IPR.

Thanks,
  Jim Uttaro

From: stephane.litkow...@orange.com 
Sent: Monday, February 18, 2019 10:53 AM
To: draft-rabadan-sajassi-bess-evpn-ipvpn-interwork...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WG adoption and IPR poll for 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02


This email begins a two-week poll for adoption of 
draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-02
[1]

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 are no IPR disclosures 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 Wednesday 4th March 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/


_



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] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane

[UTTARO, JAMES]

None that I am aware of

Thanks,
Jim Uttaro

-Original Message-
From: IETF Secretariat [mailto:ietf-...@ietf.org] 
Sent: Wednesday, November 28, 2018 10:39 AM
To: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
Cc: ipr-annou...@ietf.org; bess@ietf.org
Subject: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR 
related to draft-ietf-bess-nsh-bgp-control-plane

Dear Adrian Farrel, John Drake, Eric C. Rosen, Jim Uttaro, Luay Jalil:


An IPR disclosure that pertains to your Internet-Draft entitled "BGP
Control Plane for NSH SFC" (draft-ietf-bess-nsh-bgp-control-plane) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_3347_=DwICaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=xqeXEnvJFt7KGraKxUKhn8CA8XzUmnF0HkpMGUv2dSg=r5REH4JewO3L5H_FPOS8wG7dBgHt7MCFZo6VuPbA6iA=).
 The title of the IPR disclosure is
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-bess-nsh-bgp-control-plane"


Thank you

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

Re: [bess] WG adoption poll for draft-zzhang-bess-mvpn-evpn-aggregation-label-01

[UTTARO, JAMES]

Support

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, October 31, 2018 8:50 AM
To:  
Cc: bess@ietf.org
Subject: Re: [bess] WG adoption poll for 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01

Support

On Tue, Oct 30, 2018, 09:22 
mailto:stephane.litkow...@orange.com> wrote:
Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 13th November.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-evpn-aggregation-label/





[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 

  NEW !
stephane.litkow...@orange.com


_



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

Re: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

[UTTARO, JAMES]

Support

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, September 04, 2018 9:32 AM
To: stephane.litkow...@orange.com; bess@ietf.org
Subject: Re: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
As a co-author , I support for WG adoption.
I am not aware of any IPR relevant to this document.

​
Thanks,
Avinash Lingala


From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
stephane.litkow...@orange.com
Sent: Tuesday, September 04, 2018 3:29 AM
To: bess@ietf.org
Subject: [bess] WG adoption poll for draft-malhotra-bess-evpn-unequal-lb-04

Hi WG,

This email begins a two-week poll for BESS working group adoption 
draft-malhotra-bess-evpn-unequal-lb-04 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Tue 18th September.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-unequal-lb/






_



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] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[UTTARO, JAMES]

Support

Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Tuesday, August 21, 2018 1:20 PM
To: stephane.litkow...@orange.com; bess@ietf.org
Subject: Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

Yes/support

Cheers,
Jeff

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
mailto:stephane.litkow...@orange.com>>
Date: Wednesday, August 8, 2018 at 07:03
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_



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

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

IMO, there is going to be a need for that the various flavors 
of SD-WAN to inter-operate with the current suite of network services with an 
emphasis on 2547.  May be best to approach this as we did with EVPN and create 
a requirements draft detailing what the need is.

Thanks,
Jim Uttaro

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, July 10, 2018 10:11 AM
To: UTTARO, JAMES ; Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Jim,

This is a general statement applicable to overall SD-WAN effort.

Cheers,
Jeff

From: "UTTARO, JAMES" mailto:ju1...@att.com>>
Date: Tuesday, July 10, 2018 at 05:22
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Ron Bonica mailto:rbon...@juniper.net>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, RTGWG 
mailto:rt...@ietf.org>>, Eric Rosen 
mailto:ero...@juniper.net>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

There are also many companies using EVPN as the control plane.
It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.
[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended 
as a general statement in re interoperability with the 2547 ?
Data planes are a jungle and would not be standardized any time soon.
However - an abstraction on top would be very useful.

Regards,
Jeff

On Jul 6, 2018, at 14:23, Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

There are also many companies using EVPN as the control plane.
It is important to find a “golden middle” where on one side we achieve 
interoperability but on another don’t hinder the innovation in that, fast 
growing space.
[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended 
as a general statement in re interoperability with the 2547 ?
Data planes are a jungle and would not be standardized any time soon.
However - an abstraction on top would be very useful.

Regards,
Jeff

On Jul 6, 2018, at 14:23, Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jess,

Great Action! There are much more than the Data modeling.
A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use 
NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed 
decades ago (for ATM) just doesn’t scale to support Managed Overlay network of 
100s or 1000s CPEs.

Linda

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 3:20 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Robert/Linda,

RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG.
Service data modeling(data modeling in general)is an obvious candidate (at ONUG 
we started, there’s some early effort, but IETF help is needed).
Control plane interworking is another interesting topic.
Please bring your ideas, I’m still working on agenda

Regards,
Jeff

On Jul 6, 2018, at 13:12, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Linda,

What you are expressing is very clear and in fact happens today on any good 
SD-WAN controller.

But in the context of this discussion are you bringing it here to suggest that 
draft-rosen-bess-secure-l3vpn should have such functionality build in ?

Personally I don't think it really belongs in this draft as perfect sweet spot 
for it still IMHO resides on a SD-WAN controller. Pushing all that logic into 
BGP may be a bit excessive ...

Many thx,
R.


On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
Ron,

This is referring to a Managed Overlay WAN services with many CPEs (large scale 
SD-WAN) and where

-there are many CPEs at each location and multiple WAN ports on each CPE

-SD-WAN Controller needs to detour a path between Site -A-&  Site-B via 
another site (e.g. Site-C) for reasons like Performance, Regulatory,  or 
others. Instead of designating to specific CPE of the site-C.

It is preferable to partition CPEs to clusters, as shown in the figure below:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org
Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Linda,

I’m not sure that I understand what you mean when you say, “aggregate CPE-based 
VPN routes with internet routes that interconnect the CPEs”. Could you 
elaborate?

Ron


From: Linda Dunbar mailto:linda..dun...@huawei..com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org
Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Eric and Ron,

We think that the method described in your draft is useful for CPE based EVPN, 
especially for SD-WAN between CPEs.
But, it misses some aspects to aggregate CPE-based VPN routes with internet 
routes that interconnect the CPEs.

Question to you: Would you like to expand your draft to cover the scenario of 
aggregating CPE-based VPN routes with internet routes that 

Re: [bess] WG Adoption and IPR Poll for draft-sajassi-bess-evpn-virtual-eth-segment-03

[UTTARO, JAMES]

Support

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Patrice Brissette 
(pbrisset)
Sent: Tuesday, May 22, 2018 1:32 PM
To: Bocci, Matthew (Nokia - GB) ; bess@ietf.org
Cc: draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org
Subject: Re: [bess] WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03

As co-author, I support.

Regards,
Patrice Brissette
From: "Bocci, Matthew (Nokia - GB)" 
>
Date: Thursday, May 17, 2018 at 6:24 AM
To: "bess@ietf.org" >
Cc: 
"draft-sajassi-bess-evpn-virtual-eth-segm...@ietf.org"
 
>
Subject: WG Adoption and IPR Poll for 
draft-sajassi-bess-evpn-virtual-eth-segment-03
Resent-From: >
Resent-To: Ali Sajassi >, Patrice 
Brissette >, 
>, 
>, 
>
Resent-Date: Thursday, May 17, 2018 at 6:24 AM

This email begins a two-week poll for adoption of 
draft-sajassi-bess-evpn-virtual-eth-segment-03.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 Thursday 31st May 2018.

Regards,
Matthew and Stéphane

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

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[UTTARO, JAMES]

Support

Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, May 14, 2018 8:03 AM
To: stephane.litkow...@orange.com; bess@ietf.org
Subject: Re: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

As co-author, I fully support the document for WG adoption.
Not aware of any IPR relevant to this document.

Thank you.
Jorge

From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Monday, May 14, 2018 at 11:48 AM
To: "bess@ietf.org" >
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

If you are 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.

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-fast-df-recovery/



[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 

  NEW !
stephane.litkow...@orange.com


_



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 on draft-ietf-bess-evpn-df-election-framework

[UTTARO, JAMES]

Support

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Patrice Brissette 
(pbrisset)
Sent: Monday, April 09, 2018 10:40 AM
To: stephane.litkow...@orange.com; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Hi,

I fully support this draft.

Regards,
Patrice Brissette
From: BESS > on behalf of 
"stephane.litkow...@orange.com" 
>
Date: Monday, March 26, 2018 at 4:21 PM
To: "bess@ietf.org" >
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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.



Currently no IPR has been disclosed 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.



We are also polling for any existing implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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] WG adoption and IPR poll for draft-sajassi-bess-evpn-vpws-fxc-03.txt

[UTTARO, JAMES]

As co-author, fully support..

Thanks,
Jim Uttaro

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com]
Sent: Monday, April 09, 2018 9:44 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Bocci, 
Matthew (Nokia - GB) <matthew.bo...@nokia.com>; 
draft-sajassi-bess-evpn-vpws-...@ietf.org; bess@ietf.org
Subject: Re: WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

As co-author, I fully support this document for WG adoption.
Not aware of any IPR relevant to it.

Thank you.
Jorge

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, April 9, 2018 at 3:37 PM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Bocci, 
Matthew (Nokia - GB)" 
<matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, 
"draft-sajassi-bess-evpn-vpws-...@ietf.org<mailto:draft-sajassi-bess-evpn-vpws-...@ietf.org>"
 
<draft-sajassi-bess-evpn-vpws-...@ietf.org<mailto:draft-sajassi-bess-evpn-vpws-...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <saja...@cisco.com<mailto:saja...@cisco.com>>, 
<pbris...@cisco.com<mailto:pbris...@cisco.com>>, 
<ju1...@att.com<mailto:ju1...@att.com>>, 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, 
<w...@juniper.net<mailto:w...@juniper.net>>, 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Resent-Date: Monday, April 9, 2018 at 3:37 PM

I am not aware of any IPR..

Thanks,
Jim Uttaro

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Monday, April 09, 2018 9:34 AM
To: Bocci, Matthew (Nokia - GB) 
<matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>; 
draft-sajassi-bess-evpn-vpws-...@ietf.org<mailto:draft-sajassi-bess-evpn-vpws-...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

I’m not aware of any IPR

Yours Irrespectively,

John

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of 
Bocci, Matthew (Nokia - GB)
Sent: Monday, April 9, 2018 9:23 AM
To: 
draft-sajassi-bess-evpn-vpws-...@ietf.org<mailto:draft-sajassi-bess-evpn-vpws-...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-vpws-fxc-03.txt.

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Matthew and Stéphane

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

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-vpws-fxc-03.txt

[UTTARO, JAMES]

I am not aware of any IPR..

Thanks,
Jim Uttaro

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Monday, April 09, 2018 9:34 AM
To: Bocci, Matthew (Nokia - GB) ; 
draft-sajassi-bess-evpn-vpws-...@ietf.org; bess@ietf.org
Subject: RE: WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

I’m not aware of any IPR

Yours Irrespectively,

John

From: BESS > On Behalf Of 
Bocci, Matthew (Nokia - GB)
Sent: Monday, April 9, 2018 9:23 AM
To: 
draft-sajassi-bess-evpn-vpws-...@ietf.org;
 bess@ietf.org
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-vpws-fxc-03.txt

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-vpws-fxc-03.txt.

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

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.

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.

The poll for working group adoption closes on Monday 23rd April.

Regards,
Matthew and Stéphane

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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[UTTARO, JAMES]

Mankamana,

If not a requirements draft than a usage draft indicating what 
solutions are applicable for the different inter-connect solutions. I think 
this would be quite useful to architects/designers..

Thanks,
Jim Uttaro

From: Mankamana Mishra (mankamis) [mailto:manka...@cisco.com]
Sent: Tuesday, March 27, 2018 11:32 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org; Ali Sajassi (sajassi) <saja...@cisco.com>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,
About your pointing of writing down requirement draft for multicast. I had 
discussion with Ali in this IETF (After we discussed). But looks like it might 
be too late for now to write requirement, as there are many multicast related 
solution draft already in BESS working group.  But still if majority thinks we 
need it. We can think about it.

Thanks
Mankamana

From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of 
"UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:46 AM
To: "Ali Sajassi (sajassi)" <saja...@cisco.com<mailto:saja...@cisco.com>>, John 
E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia 
- US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So, is this going to be a family of drafts dealing with 
inter-connection aspects across a set of use cases ? Would it be useful to 
right up a requirements draft like we did with EVPN??

Thanks,
Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay 
(VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN 
L3 core) will be covered in the other drafts that I mentioned below because 
they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So is the plan to incorporate Sandy’s work in these docs??

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(s

Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

[UTTARO, JAMES]

Support..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, March 26, 2018 6:26 PM
To: stephane.litkow...@orange.com; bess@ietf.org
Subject: Re: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework

Yes/support

Cheers,
Jeff
From: BESS > on behalf of 
>
Date: Monday, March 26, 2018 at 07:21
To: "bess@ietf.org" >
Subject: [bess] WGLC on draft-ietf-bess-evpn-df-election-framework


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-df-election-framework-00 [1]



This poll runs until *the 9th of April*.



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.



Currently no IPR has been disclosed 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.



We are also polling for any existing implementation.



Thank you



Matthew, Stéphane

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



_



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

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[UTTARO, JAMES]

Ali,

So, is this going to be a family of drafts dealing with 
inter-connection aspects across a set of use cases ? Would it be useful to 
right up a requirements draft like we did with EVPN??

Thanks,
Jim Uttaro

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 1:20 PM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Hi Jim,

draft-mohanty-bess-evpn-bum-opt will focus on L2 only between EVPN overlay 
(VxLAN) access domain and EVPN MPLS core. Connectivity EVPN IRB core (or EVPN 
L3 core) will be covered in the other drafts that I mentioned below because 
they are  already doing it for other use cases.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 10:03 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

So is the plan to incorporate Sandy’s work in these docs??

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, Jorge (Nokia - 
US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; Ali Sajassi (sajassi) 
<saja...@cisco.com<mailto:saja...@cisco.com>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description


Hi Jim,

Wrt multicast for L2 EVPN<-> L3 EVPN, that should be covered in corresponding 
EVPN multicast drafts:

https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-mcast-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast-2D00=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
https://tools.ietf.org/html/draft-sajassi-bess-evpn-mvpn-seamless-interop-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dmvpn-2Dseamless-2Dinterop-2D00=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

I will update my draft to address Eric’s comments as well as capture the L2 
EVPN <-> L3 EVPN explicitly in a few weeks.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

All,

Should we expand this conversation to a L2 EVPN<-> L3 EVPN 
space? IOW do we want to tackle this once and for all..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[UTTARO, JAMES]

Ali,

So is the plan to incorporate Sandy’s work in these docs??

Thanks,
Jim Uttaro


From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Monday, March 26, 2018 11:55 AM
To: UTTARO, JAMES <ju1...@att.com>; John E Drake <jdr...@juniper.net>; Rabadan, 
Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Eric Rosen 
<ero...@juniper.net>; Sandy Breeze <sandy.bre...@eu.clara.net>; Satya Mohanty 
(satyamoh) <satya...@cisco.com>
Cc: bess@ietf.org; Ali Sajassi (sajassi) <saja...@cisco.com>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description


Hi Jim,

Wrt multicast for L2 EVPN<-> L3 EVPN, that should be covered in corresponding 
EVPN multicast drafts:

https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-mcast-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dirb-2Dmcast-2D00=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=Ek3T8FismWFOPCcpsLXCVErB9uzwJ3Y1w9N_553cDtE=>
https://tools.ietf.org/html/draft-sajassi-bess-evpn-mvpn-seamless-interop-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dmvpn-2Dseamless-2Dinterop-2D00=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=9SAgBpjkWp7kuXpNCFnHc0yYR4z5MDVrwDCLAD0vsGE=YtlZmFFol1NiX2LvH9SsVJuAZks-JdhzptPE0JZOdeU=>

I will update my draft to address Eric’s comments as well as capture the L2 
EVPN <-> L3 EVPN explicitly in a few weeks.

Cheers,
Ali

From: "UTTARO, JAMES" <ju1...@att.com<mailto:ju1...@att.com>>
Date: Monday, March 26, 2018 at 6:25 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Satya Mohanty 
(satyamoh)" <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

All,

Should we expand this conversation to a L2 EVPN<-> L3 EVPN 
space? IOW do we want to tackle this once and for all..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>; Rabadan, 
Jorge (Nokia - US/Mountain View) 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>; Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>; Satya Mohanty 
(satyamoh) <satya...@cisco.com<mailto:satya...@cisco.com>>
Cc: Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description


I had some further discussions with the authors of the draft and we have 
reached the following conclusions:

1)  The solution that they will capture in their draft will be based on 
option-A which is:
a.   Enable DF election on per mcast flow – this gives the best 
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
b.  Enable IGMP proxy and SMET route – avoid unnecessary 
replication/transmission of mcast flows over core
2)  They will re-spin their draft as informational and capture their use 
case along with the requirements and the solution
3)  We will need to update the text in per-mcast-flow-df-election draft, 
igmp-mld-proxy draft, and pim-proxy draft to capture vES in addition to ES and 
in future drafts, we should make sure that both ES and vES are captured

Cheers,
Ali

From: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>>
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen 
<ero...@juniper.net<mailto:ero...@juniper.net>>, Sandy Breeze 
<sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

I don'

Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

[UTTARO, JAMES]

All,

Should we expand this conversation to a L2 EVPN<-> L3 EVPN 
space? IOW do we want to tackle this once and for all..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, March 26, 2018 12:54 AM
To: John E Drake ; Rabadan, Jorge (Nokia - US/Mountain 
View) ; Eric Rosen ; Sandy Breeze 
; Satya Mohanty (satyamoh) 
Cc: Ali Sajassi (sajassi) ; bess@ietf.org
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description


I had some further discussions with the authors of the draft and we have 
reached the following conclusions:

1)  The solution that they will capture in their draft will be based on 
option-A which is:
a.   Enable DF election on per mcast flow – this gives the best 
load-balancing for DF election among multicast flows and avoids FAT VLAN issue
b.  Enable IGMP proxy and SMET route – avoid unnecessary 
replication/transmission of mcast flows over core
2)  They will re-spin their draft as informational and capture their use 
case along with the requirements and the solution
3)  We will need to update the text in per-mcast-flow-df-election draft, 
igmp-mld-proxy draft, and pim-proxy draft to capture vES in addition to ES and 
in future drafts, we should make sure that both ES and vES are captured

Cheers,
Ali

From: John E Drake >
Date: Sunday, March 25, 2018 at 9:57 AM
To: Cisco Employee >
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" 
>, Eric Rosen 
>, Sandy Breeze 
>, 
"bess@ietf.org" >
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Ali,

I don't mean to quibble but your option A also requires all PEs to be upgraded. 
 However, it's both a more mainstream upgrade and a better solution than the 
Sandy/Satya proposal.

Also, as we discussed last week, the SMET processing already includes what 
Sandy/Satya proposal wants to do.   I.e., when  a PE is no longer the DF on any 
of the ESes to which it is attached it withdraws its SMET routes.

Sent from my iPhone

On Mar 24, 2018, at 1:30 PM, Ali Sajassi (sajassi) 
> wrote:

Hi Jorge,

As I pointed out in my previous email, the use of flag is not a viable option 
because it requires update to every single PE for it to be effective. Before 
getting too much into a new solution with many restrictions, we should evaluate 
the current mechanisms and if they fall short, then discuss new mechanism. In 
one of my emails (which got sent out of order because the connection on the 
plane is very slow), I talked about option-A:

The best solution for your use case is (option-A):

  1.  Enable DF election on per mcast flow – gives the best load-balancing for 
DF election among multicast flows and avoids FAT VLAN issue
  2.  Enable IGMP proxy and SMET route – avoid unnecessary 
replication/transmission of mcast flows over core

Cheers,
Ali

From: BESS > on behalf of 
"Rabadan, Jorge (Nokia - US/Mountain View)" 
>
Date: Saturday, March 24, 2018 at 3:58 AM
To: Eric C Rosen >, Sandy Breeze 
>, 
"bess@ietf.org" >
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on 
problem description

Eric, as discussed and you point out, one can easily interpret that IMET is not 
mandatory in some cases where multi-destination traffic is not needed. In any 
case, whether this document is Informational or Standards Track is probably not 
that important.

If this had to be done, out of the options you list, I think omitting the PTA 
would not be backwards compatible since the use of PTA is a MUST in RFC7432, so 
RRs wouldn’t like it. Maybe label zero could cause issues too. So maybe a flag 
is the least disruptive one if the document has to modify something.

I still think it may be better to proceed with the IMET withdraw procedure and 
clarify that it is only valid for:
a) BUM traffic in IR cases
b) BDs with no igmp/mld/pim proxy
c) BDs with no OISM or IRBs
d) BDs with I-ES associated to overlay tunnels and no other ACs

And any other restrictions/caveats we may need to add.

My 2 cents.
Jorge


From: Eric C Rosen >
Date: Friday, March 23, 2018 at 5:00 PM
To: "Rabadan, Jorge 

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com>; BOUCADAIR Mohamed IMT/OLN 
<mohamed.boucad...@orange.com>; UTTARO, JAMES <ju1...@att.com>; Henderickx, Wim 
(Nokia - BE/Antwerp) <wim.henderi...@nokia.com>; Robert Raszuk 
<rob...@raszuk.net>; Adrian Farrel <adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are 
requirements/constraints/new practices/new OAM procedures that need to be 
supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
    Jim Uttaro

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Med,

When I say simply, I am speaking as an operator. The 
operations, systems, tools, institutional knowledge etc… in this space is 
around MPLS. There is a simpler path to creating simple chains by using MPLS 
instead of introducing a new encap.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <ju1...@att.com>; Henderickx, Wim (Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com>; Robert Raszuk <rob...@raszuk.net>; Adrian Farrel 
<adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without 
any code upgrade.


NSH does provide the simple functionality you need; that is the information to 
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with 
length is 0x2.

Of course you can encode that information using another channel, but still code 
change is needed.

Please note that NSH is not at the same level as “GENEVE, VXLAN”.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Henderickx, Wim 
(Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Med,

We run an MPLS network so there is no NSH deployed anywhere. I 
want to create simple chains that we can make available to our WAN customers 
and I want to keep it simple from a technology and operations POV.. At this 
point I do not see the need to introduce NSH for what we need to do. I can 
simply re-use MPLS.

Not sure why NSH is the winner here there are folks who advocate for GENEVE, 
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to 
define the set of requirements/criteria and compare the encaps.

Thanks,
Jim Uttaro

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <ju1...@att.com>; Henderickx, Wim (Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com>; Robert Raszuk <rob...@raszuk.net>; Adrian Farrel 
<adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org; 
bess@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

Perhaps I missed your point, but I’m not asking to disallow whatever transport 
encapsulation scheme deployed in a network for SFC purposes.

What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a 
transport-agnostic approach that can be deployed in conjunction with one’s 
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to 
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert 
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) 
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>; Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@raszuk.net>>; Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List 
<spr...@ietf.org<mailto:spr...@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org>; 
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; bess@ietf.org<mailto:bess@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: <rras...@gmail.com<mailto:rras...@gmail.com>> on behalf of Robert Raszuk 
<rob...@raszuk.net<mailto:rob...@rasz

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[UTTARO, JAMES]

Where I get a little lost in this discussion is assuming that there must be one 
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is 
an encap that has tons of functionality but if a simple chain is needed why is 
it that an existing encap should be disallowed by the IETF?? I want to simplify 
the network, when I say network it is all of the plumbing to realize a service 
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single 
encap across an integrated solution is quite attractive.

Thanks,
Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) ; Robert 
Raszuk ; Adrian Farrel 
Cc: mpls ; SPRING WG List ; s...@ietf.org; 
bess@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.


For all these proposals, a new behavior is needed to be followed by SFC-aware 
nodes. What differs is the channel used to signal a chain and to supply 
additional data for SFC purposes.



Leveraging on existing code/capabilities is good for a vendor/implementer, but 
the risk is that a given solution will need to support all/many of these 
flavors. Which is not optimal.



The IETF has already a consensus on a transport-agnostic solution. If we open 
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to 
go that way? If yes, what is the NEW problem are we trying to solve?



Cheers,

Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Henderickx, Wim (Nokia - 
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; bess@ietf.org; 
s...@ietf.org
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Indeed, this is exactly my point. If you want an interim solution you want to 
use what we have and draft-ietf-bess-service-chaining-04 is an example of how 
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc 
requires an implementation change in the data-plane, whether we like it or not 
and an upgrade is required even in brownfield deployments. So, you better go 
directly to the final solution defined in IETF SFC WG. If we standardize 
draft-farrel-mpls-sfc we end up supporting both forever.

From: > on behalf of Robert Raszuk 
>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel >
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" 
>, mpls 
>, SPRING WG List 
>, 
"s...@ietf.org" >, 
"bess@ietf.org" >
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

> That proxy may be a bump in the wire between the SFF and SF

I am not so sure about that ... If this would be just "bump in the wire" you 
would have zero guarantees that all packets which need to go via given function 
will actually hit that bump - so this is far from a reliable network service.

There must be associated control plane component attracting traffic to such 
bump.

That mechanism with basic MPLS (where labels by based MPLS architecture are of 
local significance) is available with L3VPN extensions as already progressing 
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you 
state "interim" ?

No one really addressed that question yet and I think it is a critical one to 
make any further judgement  as to the future of this individual submission.

Cheers,
R.



On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel 
> wrote:
Hi Wim,

Thanks for reading the draft so carefully.

> Adrian, on replacement of NSH. You will have to change the SF with this 
> proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which 
> SF(s)
> support MPLS?

This is not about "replacing" the NSH. As you'll see from point 2, below, this 
is about providing an interim / migration technology.

Clearly (and I think you agree) in the case where an SF is not SFC-aware, a 
proxy must be used. That proxy may be a bump in the wire between the SFF and 
SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the 
first two options are available. In the case of a VNF, all three options exist.

Now, let us recall where we are starting from. There are PNFs and there are 
VNFs built to look like PNFs. These SFs do not support MPLS or NSH.

Similarly, there are routers that do not support the NSH.

Now, of course, we 

Re: [bess] WG Last Call for draft-ietf-bess-fat-pw-bgp

[UTTARO, JAMES]

Support.

Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Monday, June 12, 2017 3:14 PM
To: Vigoureux, Martin (Nokia - FR/Nozay) ; BESS 

Subject: Re: [bess] WG Last Call for draft-ietf-bess-fat-pw-bgp

As a co-author I support this document for publication as a Proposed Standard 
RFC.



I’m not aware of any related IPR.

Thanks.

Jorge







On 6/12/17, 6:27 PM, "BESS on behalf of Martin Vigoureux" 
 wrote:



Hello Working Group,



This email starts a Working Group Last Call on 

draft-ietf-bess-fat-pw-bgp-02 [1] which is considered mature and ready 

for a final working group review.



¤ Please read this document if you haven't read the most recent

version yet, and send your comments to the list, no later than

*26th of June*.

Note that this is *not only* a call for comments on the document; it is 

also a call for support (or not) to publish this document as a Proposed 

Standard RFC.



¤ *Coincidentally*, we are also polling for knowledge of any IPR that 

applies to draft-ietf-bess-fat-pw-bgp, 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 a document Author or Contributor of

draft-ietf-bess-fat-pw-bgp-02 please respond to this email and indicate 

whether or not you are aware of any relevant IPR.



Note that, as of today, no IPR has been disclosed against this document 

or its earlier versions.



¤ We are also polling for knowledge of implementations of part or all of 

what this document specifies. This information is expected as per [2]. 

Please inform the mailing list, or the chairs, or only one of the chairs.





Thank you,

M



[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dfat-2Dpw-2Dbgp_=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=P_ZdihBQVa1AyhreAxJdjnZG411-YedlmZk53X7xWIc=KljzQIrOJ_XB2tu3RgwOVV_L5GwpfmgeziTAMBWPMMQ=
 

[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bess_cG3X1tTqb-5FvPC4rg56SEdkjqDpw=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=P_ZdihBQVa1AyhreAxJdjnZG411-YedlmZk53X7xWIc=06LbDOfQR-6fk2fOnVtzdqFXja3wM_Oz3rQxDD-4LYc=
 



___

BESS mailing list

BESS@ietf.org


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=P_ZdihBQVa1AyhreAxJdjnZG411-YedlmZk53X7xWIc=rqTY4jIpnox3BvGPRzra4-c4Hkh8Yr-JxitF_PMU8nM=
 





___
BESS mailing list
BESS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=P_ZdihBQVa1AyhreAxJdjnZG411-YedlmZk53X7xWIc=rqTY4jIpnox3BvGPRzra4-c4Hkh8Yr-JxitF_PMU8nM=
 
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-evpn-usage

[UTTARO, JAMES]

Fully support as co-author..I am not aware of any IPR related to this document..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Senad IETF - Internet 
Engineering Task Force
Sent: Monday, June 12, 2017 3:29 PM
To: Martin Vigoureux 
Cc: BESS 
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-usage

Full support of this document for RFC publication.  As a co-author, I am not 
aware of any IPR related to this document.

On Tue, Jun 6, 2017 at 10:11 AM, Martin Vigoureux 
> wrote:
Hello Working Group,

This email starts a Working Group Last Call on draft-ietf-bess-evpn-usage-04 
[1] which is considered mature and ready for a final working group review.

Please read this document if you haven't read the most recent
version yet, and send your comments to the list, no later than
*20th of June*.
Note that this is *not only* a call for comments on the document; it is also a 
call for support (or not) to publish this document as an Informational RFC.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to 
draft-ietf-bess-evpn-usage, 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 a document Author or Contributor of
draft-ietf-bess-evpn-usage-04 please respond to this email and indicate whether 
or not you are aware of any relevant IPR.

Note that, as of today, no IPR has been disclosed against this document or its 
earlier versions.

As opposed to the policy [2], we are not polling for knowledge of 
implementations as it does not seem to make sense in that case. If you feel 
otherwise, please let us know.

Thank you,
M

[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/
[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] [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

[UTTARO, JAMES]

Support

Jim Uttaro

From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of luay.ja...@verizon.com
Sent: Saturday, April 15, 2017 3:49 AM
To: BESS 
Cc: s...@ietf.org
Subject: Re: [sfc] Extra time to reflect on 
draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure

Support


Luay

From: sfc > on behalf of 
Martin Vigoureux >
Reply-To: BESS >
Date: Thursday, April 13, 2017 at 1:04 PM
To: BESS >
Cc: "s...@ietf.org" >
Subject: [sfc] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane 
adoption following the IPR disclosure

WG

Given the IPR disclosed [1] against
draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for
comment specifically to let people express a revised opinion on how
draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS.

This call for comment is open until the 5th of May

Thanks
M

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_2980_=DwIFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY=qN2VxBfuDQTHb9spUcOb6U-0QhNArhH4-TqX_aTjyaw=4VuflmQibSX6JGcRHsfv4SgtIIMuNUzVFEdMMccItP8=

___
sfc mailing list
s...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc=DwIFAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=7yfE7g9ZjpRzGkNuVTidj5c7H2bMIhCLfUwl8WcELSY=qN2VxBfuDQTHb9spUcOb6U-0QhNArhH4-TqX_aTjyaw=u3C3H2GPfolNL2O1q7-SoUfZRNFXGGqXbUo471yGMkU=

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

Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

[UTTARO, JAMES]

Support

I am not aware of any IPR that applies to this document..

Thanks,
Jim Uttaro

-Original Message-
From: Eric C Rosen [mailto:ero...@juniper.net] 
Sent: Thursday, March 23, 2017 3:39 PM
To: Martin Vigoureux ; bess@ietf.org
Cc: draft-mackie-bess-nsh-bgp-control-pl...@ietf.org
Subject: Re: Call for adoption: draft-mackie-bess-nsh-bgp-control-plane

Support.

I am not aware of any undisclosed IPR that applies to this document.


On 3/6/2017 6:55 AM, Martin Vigoureux wrote:
> Hello working group,
>
> This email starts a two-week call for adoption on 
> draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group 
> Document.
>
> Please state on the list if you support the adoption or not (in both 
> cases, please also state the reasons).
>
> This poll runs until *the 19th of March*.
>
> 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 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.
>
> IPR has been disclosed against this Document [2].
>
> If you are not listed as an Author or Contributor, then please 
> explicitly respond only if you are aware of any IPR that has not yet 
> been disclosed in conformance with IETF rules.
>
> Thank you
>
> Martin & Thomas
> bess chairs
>
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmackie-2Dbess-2Dnsh-2Dbgp-2Dcontrol-2Dplane_=DwIC-g=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=Jq8xVoxXAElPnANDuWQsjZ35hv1tMkl8f2fGPce3nCE=OC54K24q1RHH00jHCjzA0a2EMXDkNpSeVfFJvW_POew=
>  
> [2] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dmackie-2Dbess-2Dnsh-2Dbgp-2Dcontrol-2Dplane=DwIC-g=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=Jq8xVoxXAElPnANDuWQsjZ35hv1tMkl8f2fGPce3nCE=fX1wKM3MwLSkWdDDsAIGiirNP2liQS1E4g_q6_90bO0=
>  

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

Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

[UTTARO, JAMES]

Comments In-Line..

Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Eric C Rosen
Sent: Thursday, November 03, 2016 9:54 AM
To: Joel M. Halpern ; adr...@olddog.co.uk
Cc: bess@ietf.org
Subject: Re: [bess] FW: New Version Notification for 
draft-mackie-bess-nsh-bgp-control-plane-01.txt

On 11/2/2016 4:50 PM, Joel M. Halpern wrote:
> I would observe that what we are discussing is really SFC definition.

That's what you're discussing ;-), but we're just trying to devise a way 
that a node can figure out where the next node in the service chain for 
a particular packet is, how to get the packet there, and how to set up 
the forwarding tables to achieve that.
[Jim U>] +1


> The draft is really concerned only with the fact that the SFF passes a
> packet to a "local" service function, and ultimately gets the packet
> back with an NSH that contains an SPI/SI.  The question is -- what are
> the possible SPI/SI values that the packet may have when the SFF gets it
> back?  In order to do "fast path" forwarding, the SFF needs to create
> forwarding state for this set of SPI/SI's.  If arbitrary
> reclassification is possible, then any value of SPI/SI may be seen when
> the packet comes back, and forwarding state needs to be created for
> every valid SPI/SI value.  It's good to have some indication in advance
> about which SPI/SI values one is likely to see when the packet returns;
> this allows one to maintain only the set of forwarding states that one
> is likely to see.  That's what the markers are for.  Of course, this is
> just an optimization meant to improve performance and scaling.

>> Mostly, I think this is backwards.  The only valid values for SPI/SI 
>> that can be given back to the SFF by the SF are those for which the 
>> SFF has forwarding state.  Any other values will result in the packet 
>> being dropped.the SFF does not create this forwarding state from 
>> whole cloth.  It creates this state from the information provided by 
>> the control mechanism (BGP, ForCES, NetConf, XMPP, ...)  The SFF does 
>> not care what the SF will hand it.  Rather, it cares what it is 
>> supposed to forward, and to where. 
>

I don't see any difference between what you stated and what I stated.  
However you say it, the SFF has to have forwarding state for whatever 
SPI/SI values it might see in an NSH, and does not have to have 
forwarding state for values that it will not see.

> Even when arbitrary reclassification is possible, control mechanisms 
> need to be coordinated such that the markings the classifier wants to 
> produce correspond to forwarding state the SFF has.

Of course, that's what I said.

You seem to be trying hard to disagree with something, but I really 
don't understand the content of the disagreement.

> I am saying that the set of markers in the BGP draft seem to cover 
> cases they don't need to cover, and not cover cases that they need to 
> cover in order to handle all of the provisioning of the SFF.

I think we are having trouble following your argument here.  Do you have 
an example of how the mechanisms in the draft will produce incorrect 
forwarding state?

> The NSH draft only requires that the packet be dropped if its SPI/SI do
> not "correspond" to a "valid" next hop.   Note that the quoted terms do
> not appear to be defined.  This leaves a lot of leeway for 
> interpretation.
>
>> Eric, on this you are stretching.  If you really want us to add more 
>> specific wording, we can.  But as a participant it has seemed to me 
>> that the WG has understood these quite well, and that they are 
>> actually quite clear and reasonable words. 

The use of undefined terms like this usually hides disagreements and 
differing interpretations.


>> If you want them clarified, we can do that.  In contrast to your 
>> paragraph below, the WG has been clear that if an SFF has state for 
>> SPI X, SI Y, that does not mean that the SFF has state for any other 
>> SI value.  While we allow for SFF that also look at other things (for 
>> example load balancing), the SPI/SI match is exact. 
>

Perhaps the WG did not think of the advantages of allowing a more 
flexible scheme.  Or to put it another way, allowing more flexibility 
here doesn't really seem to damage the architecture in any way.  If we 
are wrong about that, perhaps someone will explain what goes wrong if 
one interprets "SI=n" to mean "whatever SI is closest to n without being 
greater than n".





___
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 (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

[UTTARO, JAMES]

+1 

Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US)
Sent: Thursday, May 05, 2016 1:16 PM
To: Vigoureux, Martin (Nokia - FR) ; BESS 

Subject: Re: [bess] WG Last Call (including implem status & shepherd) for 
draft-ietf-bess-evpn-vpws-03

As a co-author, I fully support this document for publication as Proposed 
Standard RFC and I’m not aware of any undisclosed IPR related to it.

It is a fundamental technology that will allow Operators to keep deploying 
EVPN, now also for ELINE services.
The document is ready for publication, however I have two LC comments that are 
already agreed with the authors:

1) Section 2.4 "Flexible CrossConnect" Service has to be removed from the final 
text. The requirements of this special service type are not in-line with the 
ones explained in section 1.2 and must be tackled separately. 

11) IANA considerations: the authors have agreed to request the value ‘4’ for 
the Extended Community Sub-Type, since there are existing implementations using 
that value.

Once both comments are addressed, the text is ready for publication.

Thank you.
Jorge
 



On 5/5/16, 12:54 PM, "BESS on behalf of EXT Martin Vigoureux" 
 wrote:

>Hello Working Group,
>
>Please read carefully, this e-mail contains new elements compared to 
>other WG LCs.
>
>This email starts a Working Group Last Call on 
>draft-ietf-bess-evpn-vpws-03 [1].
>
>¤ Please read the document if you haven't read the most recent
>version yet, and send your comments to the list, no later than
>*20th of May*.
>Note that this is *not only* a call for comments on the document, but 
>also a call for support (or not) publishing this document as a Proposed 
>Standard RFC.
>
>¤ We are also polling for knowledge of any undisclosed IPR that applies 
>to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed 
>in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 
>for more details) prior to moving forward.
>If you are listed as a document Author or 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.
>Two IPR disclosures exist against previous revisions of this document [2].
>
>¤ We are also polling for knowledge of implementations of part or all of 
>what this document specifies. This information is expected as per [3]. 
>Please inform the mailing list, the chairs, or only one of the chairs.
>
>¤ Finally, if someone wishes to volunteer to be Document Shepherd for 
>this document, please let us know.
>
>Thank you
>M
>
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/
>[2] 
>https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-bess-evpn-vpws
>[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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

[UTTARO, JAMES]

Fully support as co-author, no IRP that I am aware of.

Thanks,
Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Wen Lin
Sent: Monday, January 25, 2016 9:47 AM
To: EXT - thomas.mo...@orange.com; 'BESS'; 
draft-ietf-bess-evpn-et...@tools.ietf.org
Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

Fully support as a co-author. I am not aware of any un-disclosed IPR.

Thanks,
Wen

>
>-Original Message-
>From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
>Sent: Tuesday, January 19, 2016 2:51 AM
>To: BESS; draft-ietf-bess-evpn-et...@tools.ietf.org
>Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree
>
>Hello Working Group,
>
>This email starts a Working Group Last Call on draft-ietf-bess-evpn-etree
>[1] which is considered mature and ready for a final working group review.
>
>Please read the document if you haven't read the most recent version yet
>(-03), and send your comments to the list, no later than *February the
>2nd* (2016-02-02).
>
>This is not only a call for comments on the document, but also a call of
>support for its publication.
>
>*Coincidentally*, we are also polling for knowledge of any IPR that
>applies
>to draft-ietf-bess-evpn-etree, 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 a document author or contributor of
>draft-ietf-bess-evpn-etree please respond to this email and indicate
>whether
>or not you are aware of any relevant IPR.
>
>Thank you,
>
>Thomas/Martin
>
>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
>
>___
>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

___
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] draft-hao-bess-inter-nvo3-vpn-optionc

[UTTARO, JAMES]

+1

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
Sent: Friday, November 20, 2015 12:19 PM
To: EXT - thomas.mo...@orange.com; Lucy yong; Henderickx, Wim (Wim); 
bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Lucy,

My apologies, I misunderstood.

I think we have to accept the fact that we will have to deal with a 
multiplicity of different encapsulations in the data plane along a packet's e2e 
path and that we should take a more measured approach to deciding how to deal 
with this in a general and extensible way before accepting any solutions. 
  
Yours Irrespectively,

John

> -Original Message-
> From: thomas.mo...@orange.com [mailto:thomas.mo...@orange.com]
> Sent: Friday, November 20, 2015 12:04 PM
> To: John E Drake; Lucy yong; Henderickx, Wim (Wim); bess@ietf.org
> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
> 
> 2015-11-20, John E Drake:
> > That presupposes that the group likes either of the two proposed solutions
> in your draft.
> 
> John, I think Lucy's "two solutions" was referring to draft-hao-bess-inter-
> nvo3-vpn-optionc solution and the 3-label Optionc MPLS/MPLS/UDP solution
> described by Wim.
> 
> -Thomas
> 
> 
> 
> >
> >> -Original Message-
> >> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Lucy yong
> >> Sent: Friday, November 20, 2015 11:49 AM
> >> To: EXT - thomas.mo...@orange.com; Henderickx, Wim (Wim);
> >> bess@ietf.org
> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
> >>
> >> Share my 2 cent.
> >>
> >> Cloud providers want to tunnel its customer traffic through DC (AS)BR.
> >> Option C is a way to realize it. Both solutions summarized by Thomas
> >> have no change on WAN VPN side and seamlessly work with WAN VPN
> option C.
> >> However, to support either solution, DC has to do some enhancement on
> >> DC BR or ToR switch, etc, which dictates to different implementations
> >> within a DC. Option C pro and con remains regardless what
> >> implementation is used in a DC.
> >>
> >> Two solutions should not coexist in one DC (does not make a sense),
> >> but it does not matter if one DC operator prefers to use one solution
> >> and another DC prefers to use another solution. Since there are many
> >> cloud providers today, it is worth for the WG to document both
> >> solutions and point out the implementation requirements on impacted
> >> components. Then, up to vendors and operators to select a solution for
> their DC.
> >>
> >> It does not make a sense for us to vote which solution is better here
> >> because a better solution for a DC depends on many factors.
> >>
> >>
> >> Lucy
> >>
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of
> >> thomas.mo...@orange.com
> >> Sent: Friday, November 20, 2015 3:02 AM
> >> To: Henderickx, Wim (Wim); bess@ietf.org
> >> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
> >>
> >> 2015-11-19, Henderickx, Wim (Wim):
> >>> WH> I vote for a an evolution of switches/TORs that have proper
> >>> support for this. I hope some HW vendors of TOR chips shime in, but
> >>> I am told the MPLS solution is possible in the next generation chips
> >>> they are working on.
> >>
> >> Well, it looks like the key questions are:
> >> - when would ToR chips support MPLS/MPLS/UDP ?  (the generation that
> >> has been released recently but not present in most shipping ToRs yet,
> >> the next one ?)
> >> - do we want an interim VXLAN-based solution ? (that will involve at
> >> best a performance penalty with existing chips, and at worse
> >> impossible to implement -- we haven't seen clear information in this
> >> thread)
> >>
> >> -Thomas
> >>
> >>
>  Zhuangshunwan  :
> >
> > Hi Diego,
> >
> > Thanks for your comments. Pls see inline with [Vincent].
> >
> > Vincent
> >
> > *发件人:*BESS [mailto:bess-boun...@ietf.org] *代表 *Diego Garcia
> >> del Rio
> > *发送时间:*2015年11月18日14:25 *收件人:*bess@ietf.org *主题
> >> :*Re: [bess]
> > draft-hao-bess-inter-nvo3-vpn-optionc
> >
> > Some comments from my side, I think the draft makes quite a few
> > assumptions on specific implementation details that are way too
> > general to be considered widely available. Most of the TOR devices
> > today already pay a double-pass penalty when doing routing of
> > traffic in/out of vxlan-type tunnels. Only the newest generation
> > can route into tunnels without additional passes. And are
> > definitively limited in being able to arbitrary select UDP ports
> > on a per tunnel basis. In fact, most are even limited at using
> > more than one VNID per "service" of sorts. [Vincent]: Yes, the new
> > generation BCM chipset has already supported VXLAN routing
> without
> > additional passes. For OVS/TOR, VXLAN encapsulation is more
> > popular than MPLSoGRE/UDP, and has better performance. The
> > IP-addressed based 

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[UTTARO, JAMES]

Comments In-Line..

Jim Uttaro

From: Osama Zia [mailto:osa...@microsoft.com]
Sent: Thursday, November 19, 2015 2:06 PM
To: UTTARO, JAMES; Haoweiguo; John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com; BESS
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

CIL

From: UTTARO, JAMES [mailto:ju1...@att.com]
Sent: Thursday, November 19, 2015 10:56 AM
To: Osama Zia <osa...@microsoft.com<mailto:osa...@microsoft.com>>; UTTARO, 
JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Haoweiguo 
<haowei...@huawei.com<mailto:haowei...@huawei.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Henderickx, Wim (Wim) 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>; 
EXT - thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>; BESS 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The assumption being based on one's view of what a DC is ;) Yes when an SP and 
a Cloud Provider connect an inter-AS model of some form is needed.. It is 
doubtful that it would ever be Option C as the exposes a tremendous amount of 
internal information.
[OZ] I would beg to disagree here. Customer traffic can be tunneled to a 
customer router in the cloud that should only expose customer routes. I had 
argued previously in IETF that current practice of option A is not scalable.
[Jim U>] So, do you mean a CSC model where the NHs are the customer CEs, if so, 
then that is not Classical Option C where PE LBs are exchanged as the NHs for 
the customers path/routes.

At the end of the day network architecture/design whether internal/external to 
a provider is not mandated by the IETF or any standards body. This draft seems 
to mix encap, interconnect etc If the encap "requires" a specific 
connectivity model than I am not sure how that exactly works.

Jim Uttaro

From: Osama Zia [mailto:osa...@microsoft.com]
Sent: Thursday, November 19, 2015 1:51 PM
To: UTTARO, JAMES; Haoweiguo; John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>; BESS
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Today many large enterprises connect to cloud providers using their existing 
MPLS VPN networks. This would mean different AS Numbers at WAN and DC sites.

Regards,
Osama

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of UTTARO, JAMES
Sent: Thursday, November 19, 2015 9:46 AM
To: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Henderickx, Wim (Wim) 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>; 
EXT - thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>; BESS 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

A concern I have with this draft is that it pre-supposes the network 
architecture in terms of how DCs and WAN are connected. It assumes that DCs and 
WAN networks are in different AS domains. Why is that??

Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo
Sent: Tuesday, November 17, 2015 11:24 PM
To: John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc


Hi,

The problem we are trying to solve is to reduce data center GW/ASBR-d's 
forwarding table size, the motivation is same as traditional MPLS VPN option-C. 
Currently, the most common practise on ASBR-d is to terminate VXLAN 
encapsulation, look up local routing table, and then perform MPLS encapsulation 
to the WAN network. ASBR-d needs to maintain all VM's MAC/IP. In Option-C 
method, only transport layer information needed to be maintained at GW/ASBR-d, 
the scalability will be greatly enhanced. Traditonal Option-C is only for MPLS 
VPN network interworking, because VXLAN is becoming pervasive in data center,  
the solution in this draft was proposed for the heterogeneous network 
interworking.

The advantage of this solution is that only VXLAN encapsulation is required for 
OVS/TOR. Unlike Wim's solution, east-west bound traffic uses VXLAN encap, while 
north-south bound traffic uses MPLSoGRE/UDP encap.

There are two solutions in this draft:

1. Using VXLAN tunnel destination IP for stitching at ASBR-d.

No data plane modification requirements on OVS or TOR switches, only hardware 
changes on ASBR-d. ASBR-d normally is router, it has capability to realize the 
hardware changes. It will consume many IP addresses and the IP pool for 
allocation needs to be configured on ASBR-d beforehand.

2. Using VXLAN destination UDP port for stit

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[UTTARO, JAMES]

IMO an Option C model not CSC between to different administrative authorities 
where internal reachability state is exchanged is a non-starter.  But coming 
back to this draft it seems that tying the encap and the network architecture 
is a requirement or am I getting that wrong. If not, how should I interpret 
this draft? Should it be if I do Option C as I must have different AS domains 
between my internal DCs and WAN and my encap models are different in the WAN 
and DC, and I am using specific encaps in different places etcc... it would be 
in my solution space??

Jim Uttaro

From: Osama Zia [mailto:osa...@microsoft.com]
Sent: Thursday, November 19, 2015 2:38 PM
To: UTTARO, JAMES; Haoweiguo; John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com; BESS
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

CIL

From: UTTARO, JAMES [mailto:ju1...@att.com]
Sent: Thursday, November 19, 2015 11:16 AM
To: Osama Zia <osa...@microsoft.com<mailto:osa...@microsoft.com>>; UTTARO, 
JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Haoweiguo 
<haowei...@huawei.com<mailto:haowei...@huawei.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Henderickx, Wim (Wim) 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>; 
EXT - thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>; BESS 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Comments In-Line..

Jim Uttaro

From: Osama Zia [mailto:osa...@microsoft.com]
Sent: Thursday, November 19, 2015 2:06 PM
To: UTTARO, JAMES; Haoweiguo; John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>; BESS
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

CIL

From: UTTARO, JAMES [mailto:ju1...@att.com]
Sent: Thursday, November 19, 2015 10:56 AM
To: Osama Zia <osa...@microsoft.com<mailto:osa...@microsoft.com>>; UTTARO, 
JAMES <ju1...@att.com<mailto:ju1...@att.com>>; Haoweiguo 
<haowei...@huawei.com<mailto:haowei...@huawei.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Henderickx, Wim (Wim) 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>; 
EXT - thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>; BESS 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

The assumption being based on one's view of what a DC is ;) Yes when an SP and 
a Cloud Provider connect an inter-AS model of some form is needed.. It is 
doubtful that it would ever be Option C as the exposes a tremendous amount of 
internal information.
[OZ] I would beg to disagree here. Customer traffic can be tunneled to a 
customer router in the cloud that should only expose customer routes. I had 
argued previously in IETF that current practice of option A is not scalable.
[Jim U>] So, do you mean a CSC model where the NHs are the customer CEs, if so, 
then that is not Classical Option C where PE LBs are exchanged as the NHs for 
the customers path/routes.
[OZ] Sorry for the confusion. My comment was not specific to the draft. I was 
responding to your comment  "Option C as the exposes a tremendous amount of 
internal information"

At the end of the day network architecture/design whether internal/external to 
a provider is not mandated by the IETF or any standards body. This draft seems 
to mix encap, interconnect etc If the encap "requires" a specific 
connectivity model than I am not sure how that exactly works.

Jim Uttaro

From: Osama Zia [mailto:osa...@microsoft.com]
Sent: Thursday, November 19, 2015 1:51 PM
To: UTTARO, JAMES; Haoweiguo; John E Drake; Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>; BESS
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Today many large enterprises connect to cloud providers using their existing 
MPLS VPN networks. This would mean different AS Numbers at WAN and DC sites.

Regards,
Osama

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of UTTARO, JAMES
Sent: Thursday, November 19, 2015 9:46 AM
To: Haoweiguo <haowei...@huawei.com<mailto:haowei...@huawei.com>>; John E Drake 
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Henderickx, Wim (Wim) 
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>; 
EXT - thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> 
<thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>>; BESS 
<bess@ietf.org<mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

A concern I have with this draft is that it p

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[UTTARO, JAMES]

A concern I have with this draft is that it pre-supposes the network 
architecture in terms of how DCs and WAN are connected. It assumes that DCs and 
WAN networks are in different AS domains. Why is that??

Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo
Sent: Tuesday, November 17, 2015 11:24 PM
To: John E Drake; Henderickx, Wim (Wim); EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc


Hi,

The problem we are trying to solve is to reduce data center GW/ASBR-d's 
forwarding table size, the motivation is same as traditional MPLS VPN option-C. 
Currently, the most common practise on ASBR-d is to terminate VXLAN 
encapsulation, look up local routing table, and then perform MPLS encapsulation 
to the WAN network. ASBR-d needs to maintain all VM's MAC/IP. In Option-C 
method, only transport layer information needed to be maintained at GW/ASBR-d, 
the scalability will be greatly enhanced. Traditonal Option-C is only for MPLS 
VPN network interworking, because VXLAN is becoming pervasive in data center,  
the solution in this draft was proposed for the heterogeneous network 
interworking.

The advantage of this solution is that only VXLAN encapsulation is required for 
OVS/TOR. Unlike Wim's solution, east-west bound traffic uses VXLAN encap, while 
north-south bound traffic uses MPLSoGRE/UDP encap.

There are two solutions in this draft:

1. Using VXLAN tunnel destination IP for stitching at ASBR-d.

No data plane modification requirements on OVS or TOR switches, only hardware 
changes on ASBR-d. ASBR-d normally is router, it has capability to realize the 
hardware changes. It will consume many IP addresses and the IP pool for 
allocation needs to be configured on ASBR-d beforehand.

2. Using VXLAN destination UDP port for stitching at ASBR-d.

Compared with solution 1, less IP address will be consumed for allocation. If 
UDP port range is too large, we can combine with solution 1 and 2.

In this solution, both data plane modification changes are needed at OVS/TOR 
and ASBR-d. ASBR-d also has capability to realize the hardware changes. For 
OVS, it also can realize the data plane changes. For TOR switch, it normally 
can't realize this function.  This solution mainly focuses on pure software 
based overlay network, it has more scalability. In public cloud data center, 
software based overlay network is the majority case.



Whether using solution 1 or 2 depends on the operators real envionment.



So I think our solution has no flaws, it works fine.

Thanks,

weiguo




From: BESS [bess-boun...@ietf.org] on behalf of John E Drake 
[jdr...@juniper.net]
Sent: Wednesday, November 18, 2015 2:49
To: Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
Hi,

I think Wim has conclusively demonstrated that this draft has fatal flaws and I 
don't support it.  I also agree with his suggestion that we first figure out 
what problem we are trying to solve before solving it.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 12:49 PM
To: EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

- Snip -

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
>, 
BESS >
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current 

Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

[UTTARO, JAMES]

Sami,

In what way is this different from the work we have been doing on creating the 
flexible cross connect table which enables thousands of PWs to be “landed” on a 
L3/L2/Internet PE? Is this specific to always using EVPN on the service PE to 
facilitate L2/L3 closed user groups?

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Sami Boutros
Sent: Wednesday, October 07, 2015 5:14 PM
To: bess@ietf.org
Subject: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi,
The draft proposes a dynamic mechanism to terminate the VPWS transport service 
at a service PE into an overlay L2 or L3 service based on a single side 
provisioning at the access PE.

https://tools.ietf.org/html/draft-boutros-bess-evpn-vpws-service-edge-gateway-01
Thanks,
Sami
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] BGP route selection criteria - geographic distance when AS_PATH are equal

[UTTARO, JAMES]

Duleep,

So a bit confused here.

How do want the decision making to go if a path has a shorter 
AS-PATH and longer latency than the alternative?? If latency is the prime 
motivator why do you care about AS-PATH length at all.. Comments In-Line..

Jim Uttaro

From: Duleep Thilakarathne [mailto:dule...@mobitel.lk]
Sent: Friday, August 07, 2015 9:31 AM
To: Robert Raszuk
Cc: UTTARO, JAMES; bess@ietf.org
Subject: RE: [bess] BGP route selection criteria - geographic distance when 
AS_PATH are equal

Hi Raszuk,


Question 1: How does the router know about user's high latency ?

Actually I am referring ISP edge router to another ISP edge router delay due to 
transmission distance.
[Jim U] The underlying facility and it’s representative transmission distance 
will most likely differ from geographical distance. Which do you want to 
address? To Robert’s point you still need to acquire that knowledge and it may 
be orthogonal to an attribute that is defined as delay.


Question 2: How do you assure Internet stability where you start churning paths 
based on the latency of data plane ?

It is not required to consider stability in this situation since it is 
unavoidable. What is refer is, router need to select best outgoing path 
considering physical distance whenever possible when AS-PATH length is equal. 
If router selects long distance path randomly, it impacts to latency.

Question 3: What you are after has effectively been solved many years ago .. it 
is called Optimized Edge Routing (OER) / Performance Routing (PFR) - I suggest 
you google for those terms.

Thank for the suggestion. I gone through these proposals. But what I am 
suggesting is  whether we can address this idea from BGP protocol level. For 
example by introducing new attribute related to physical distance/delay similar 
to AS-PATH. New attribute need to update across the As path. My ultimate 
objective is to prevent router randomly select outgoing path when AS-PATH 
lengths are  equal. Further I am trying SDN based simulation these days. Hope I 
can share output. But this could similar to what you have proposed except geo 
distance calculation mechanism.

Refer below standard BGP route selection criteria. I suggest item 5. Wordings 
may different from vendor to vendor.




1. Discarding the routes with the unreachable Next_Hop.






2. Preferring the route with the highest Local_Pref.






3. Preferring the aggregated route. The preference of an aggregated route is 
higher than the preference of a non-aggregated route.






4. Preferring the route with the shortest AS-Path.






5. If AS-Path finds equal, consider shortest GEO distance. If still distance is 
same follow next steps.






6. Comparing the Origin attribute and selecting the routes with the Origin 
attribute as IGP, EGP, or Incomplete in order.








Regsrds
Duleept

From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Friday, August 7, 2015 6:29 PM
To: Duleep Thilakarathne
Cc: UTTARO, JAMES; bess@ietf.orgmailto:bess@ietf.org
Subject: Re: [bess] BGP route selection criteria - geographic distance when 
AS_PATH are equal

Duleep,

 Then end user experiences high latency to reach destination. In such
 a case, I suggest router need to consider geographic distance to
 destination and select path via NTT to reach destination by default.

Question 1: How does the router know about user's high latency ?

Question 2: How do you assure Internet stability where you start churning paths 
based on the latency of data plane ?

Question 3: What you are after has effectively been solved many years ago .. it 
is called Optimized Edge Routing (OER) / Performace Routing (PFR) - I suggest 
you google for those terms.

Regards,
R.












On Fri, Aug 7, 2015 at 2:51 PM, Duleep Thilakarathne 
dule...@mobitel.lkmailto:dule...@mobitel.lk wrote:
Hi Jim,

Please refer below example.

Assume destination IP is in Asian region. Particular ISP in a different  
location (Say India) has upstream peering to US POP (Say ATT) and Asia POP 
(Say NTT). If we check BGP routing table, assume it shows

XX.XX.XX.XX/24 AS - ATT,AS-XX,AS-Destination
AS - NTT,AS-YY,AS-Destination


In above case AS-PATH is equal and assume router automatically select path via 
ATT. Then end user experiences high latency to reach destination. In such a 
case, I suggest router need to consider geographic distance to destination and 
select path via NTT to reach destination by default. Deciding geo distance is a 
challenge but there are options. Here geo distance means shortest distance to 
reach IP destination from upstream POP. Current practice is to use community 
strings, but it depends on upstream ISP capability.

Can you comment my idea.

Regards
Duleept



From: UTTARO, JAMES [mailto:ju1...@att.commailto:ju1...@att.com]
Sent: Friday, August 7, 2015 4:09 PM
To: Duleep Thilakarathne; 'Robert

Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming

[UTTARO, JAMES]

I am not aware of any IPR related to this draft

Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bhupesh Kothari
Sent: Monday, July 20, 2015 4:56 PM
To: bess@ietf.org
Cc: w...@juniper.net; Senad Palislamovic; Florin Balus; Henderickx, Wim (Wim); 
Kireeti Kompella; UTTARO, JAMES; martin.vigour...@alcatel-lucent.com
Subject: Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming

I'm not aware of any IPR related to this draft.

Bhupesh

  -- Forwarded message --
  From: Martin Vigoureux martin.vigour...@alcatel-lucent.com
  Date: Fri, Jun 12, 2015 at 5:09 PM
  Subject: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming
  To: BESS bess@ietf.org
 
 
  Hello
 
  this email starts a Working Group Last Call on
  http://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming
  which is considered mature and ready for a last working group
  review.
 
  Please read the document if you haven't read the most recent
  version yet, and send your comments to the list, no later than
  June the 26th.
 
  *Coincidentally*, we are also polling for knowledge of any IPR that
  applies to this draft, 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 a document author or contributor* please
  respond to this email and indicate whether or not you are aware of
  any relevant IPR.
 
  The draft will not be moved forward until a response has been
  received from each author and contributor.
 
  If you are not listed as an author or contributor, then please
  explicitly respond only if you are aware of any IPR that has not
  yet been disclosed in conformance with IETF rules.
 
  Please note that IPR has already been disclosed for this document:
  https://datatracker.ietf.org/ipr/1809/
 
  Thank you
  MT
 
  ___
  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

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

Re: [bess] 答复: 答复: 答复: Flowspec for L2VPN and E-VPN

[UTTARO, JAMES]

IMO there are more important reasons why one does not deploy RTC.

Jim Uttaro

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Friday, November 14, 2014 2:05 AM
To: Haoweiguo; Henderickx, Wim (Wim); Thomas Morin; BESS
Cc: IDR Chairs
Subject: Re: [bess] 答复: 答复: 答复: Flowspec for L2VPN and E-VPN

Hi Weiguo, Wim and others,

IMHO, AFI/SAFI based Flowspec would have better scalability and compatibility. 
There is a precedent (RT-Constrain) that adopted the unified RT for all 
AFI/SAFI that bring many limitation when deploying RTC.

Best regards,
Mach

 -Original Message-
 From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo
 Sent: Friday, November 14, 2014 8:42 AM
 To: Henderickx, Wim (Wim); Thomas Morin; BESS
 Cc: IDR Chairs
 Subject: [bess] 答复: 答复: 答复: Flowspec for L2VPN and E-VPN
 
 Hi Wim,
 It seems to be a solution. Another problem:
 Current BGP flow spec for L2 VPN /L3 VPN relies on Rout Target for policy
 import/export. If using unified solution, RT can't overlap between different
 applications(L2VPN,L3VPN...). If using separating AFI/SAFI solution, no RT
 constraint issue.
 Maybe there are other questions for unified solution, i would like to hear 
 other
 expert's comments on your proposal.
 Thanks
 weiguo
 
 
 发件人: BESS [bess-boun...@ietf.org] 代表 Henderickx, Wim (Wim)
 [wim.henderi...@alcatel-lucent.com]
 发送时间: 2014年11月14日 8:27
 收件人: Haoweiguo; Thomas Morin; BESS
 抄送: IDR Chairs
 主题: Re: [bess] 答复:  答复:  Flowspec for L2VPN and E-VPN
 
 We define a new AFI/SAFI that accommodates all we have + include L2
 extensions.
 Operators that don’t need L2 extensions keep what they have.
 Operators that need L2 extensions go to the new method or mix the new
 method with the old methods per service type.
 
 Make sense?
 
 On 13/11/14 14:16, Haoweiguo haowei...@huawei.com wrote:
 
 How to achieve compatability with current existed flowspec[RFC5575]
 applications?
 Thanks
 weiguo
 
 
 发件人: Henderickx, Wim (Wim) [wim.henderi...@alcatel-lucent.com]
 发送时间: 2014年11月14日 8:14
 收件人: Haoweiguo; Thomas Morin; BESS
 抄送: IDR Chairs
 主题: Re: 答复: [bess] Flowspec for L2VPN and E-VPN
 
 If we define a new things I prefer to address the wider issue and
 include
 L2 in that.
 
 On 13/11/14 14:13, Haoweiguo haowei...@huawei.com wrote:
 
 Hi Wim,
 Allocating different AFI/SAFI(s) for each flow spec application is a
 applicable solution. Theoretically, unified mechanism for all flowspec
 can be designed, but it maybe a more harder work in IDR.
 Thanks
 weiguo
 
 
 发件人: BESS [bess-boun...@ietf.org] 代表 Henderickx, Wim (Wim)
 [wim.henderi...@alcatel-lucent.com]
 发送时间: 2014年11月14日 7:55
 收件人: Thomas Morin; BESS
 抄送: IDR Chairs
 主题: Re: [bess] Flowspec for L2VPN and E-VPN
 
 As I stated in the IDR meeting my observation is that we require to
 many
 AFI/SAFI(s) for all flow spec functions. Flow spec in general is
 providing match criteria¹s with related actions. Given the proposal on
 Flowspec for
 L2 is new we should look at the bigger picture.
 In My view we need a mechanism in BGP to advertise Flowspec match
 criteria¹s with related actions and they should cover L2/L3-IPv4/IPv6.
 
 On 13/11/14 13:44, Thomas Morin thomas.mo...@orange.com wrote:
 
 Hi WG,
 
 A heads up...
 
 These two drafts relate to BESS and thus may be of interest to us:
 - draft-hao-idr-flowspec-l2vpn
 http://tools.ietf.org/html?draft=draft-hao-idr-flowspec-l2vpn-01
 (on idr agenda, being presented right now)
 - draft-hao-idr-flowspec-evpn
 https://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00
 
 Best,
 
 -Thomas
 
 
 ___
 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
 
 ___
 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
___
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