Re: [bess] WG adoption and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

2020-06-23 Thread Majumdar, Kausik 
Hi Stephane, Matthew, et all,

This is a pretty stable draft. It defines the SDWAN use cases and those are 
pretty important for the deployment. I support the WG adoption.

I am not aware of any IPR associated with the draft.

Thanks,
Kausik

From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Tuesday, June 23, 2020 5:14 AM
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll for 
draft-dunbar-bess-bgp-sdwan-usage-07

Hello, This email begins a two-weeks WG adoption poll for 
draft-dunbar-bess-bgp-sdwan-usage-07 [1] .. Please review the draft and post 
any comments to the BESS working group list. We are also polling
External (slitkows.i...@gmail.com)
Report This 
Email
  FAQ  Protection by 
INKY

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dunbar-bess-bgp-sdwan-usage-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 7th July 2020.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/


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

Re: [bess] WG adoption and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

2020-06-23 Thread Andrew G. Malis 
This draft is already pretty mature (it started almost a year ago and is
now at -07) and stable (the last update was in April). It's pretty
straightforward and non controversial. It's well past time for the WG to
adopt it.

Cheers,
Andy


On Tue, Jun 23, 2020 at 8:13 AM  wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dunbar-bess-bgp-sdwan-usage-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 7th July 2020.
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/
>
>
>
>
> ___
> 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 and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

2020-06-23 Thread Linda Dunbar 
Support the WG adoption.

I am not aware of any IPR associated with the draft.

Linda Dunbar

From: BESS  On Behalf Of slitkows.i...@gmail.com
Sent: Tuesday, June 23, 2020 7:14 AM
To: bess@ietf.org
Subject: [bess] WG adoption and IPR poll for 
draft-dunbar-bess-bgp-sdwan-usage-07

Hello,

This email begins a two-weeks WG adoption poll for 
draft-dunbar-bess-bgp-sdwan-usage-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 7th July 2020.

Regards,
Matthew and Stephane

[1] 
https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/


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

[bess] The BESS WG has placed draft-dunbar-bess-bgp-sdwan-usage in state "Call For Adoption By WG Issued"

2020-06-23 Thread IETF Secretariat 


The BESS WG has placed draft-dunbar-bess-bgp-sdwan-usage in state
Call For Adoption By WG Issued (entered by Stephane Litkowski)

The document is available at
https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/


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

[bess] WG adoption and IPR poll for draft-dunbar-bess-bgp-sdwan-usage-07

2020-06-23 Thread slitkows.ietf 
Hello,

 

This email begins a two-weeks WG adoption poll for
draft-dunbar-bess-bgp-sdwan-usage-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 7th July 2020.

 

Regards,

Matthew and Stephane

 

[1]  
https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/

 

 

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

Re: [bess] WG Last Call and IPR Pollfordraft-ietf-bess-evpn-oam-req-frmwk-02

2020-06-23 Thread xiao.min2 
Hi Donald,






Thanks for your reply, please see my inline comments with .






Best Regards,


Xiao Min









原始邮件



发件人：DonaldEastlake 
收件人：肖敏10093570;
抄送人：Bocci, Matthew (Nokia - GB) 
;draft-ietf-bess-evpn-oam-req-fr...@ietf.org 
;bess@ietf.org ;
日 期 ：2020年06月23日 05:33
主 题 ：Re: [bess] WG Last Call and IPR 
Pollfordraft-ietf-bess-evpn-oam-req-frmwk-02




Hi,

On Sat, Jun 20, 2020 at 5:12 AM  wrote:
> Hi Matthew, Stephane and Authors,
>
> After reading through this draft, I think it's very useful and
> well-written, so I support its publication.

Thanks for your support and comments.

> I also have several specific comments as follows.
>
> In section 2.2, it says
>
> "
> The EVPN PE SHOULD support MEP
>  functions in the applicable service OAM protocol. This includes both
>  Up and Down MEP functions.
> "
>
> In my opinion it's reasonable to include Down MEP functions, which
> means sending OAM messages between EVPN PE and CE, but UP MEP
> functions should be excluded, because that means sending OAM
> messages between EVPN PEs, which I think doesn't belong to EVPN
> Service OAM. My understanding is that for any kind of EVPN Service
> OAM it must include CE, if an OAM mechanism runs between EVPN PEs,
> then this OAM mechanism belongs to EVPN Network OAM or EVPN
> Transport OAM.

Replying just for myself, I believe MEPs are logically in ports. What
we are talking about here is the MEP logically located in the
CE-facing port of the PE. Certainly down MEP functions from there go
to the CE. I think UP MEP functions would go to the UP MEP logically
located in the CE facing port of a remote PE. So, this is PE-to-PE and
similar to EVPN Network OAM, which runs from the brain of one PE to
the brain of another, but not identical. So I do not see any reason
why both should not be available.  Perhaps these distinctions should
be clarified in the text.



 I agree to your detailed analysis, nevetheless I lean to classifying UP 
MEP functions at a pair of PEs into EVPN Network OAM, actually I think it's a 
good candidate for the operator to choose to achieve EVPN PE-to-PE Network OAM. 
My argument is that any EVPN Service OAM should have CE involved, which will 
check the CE address mapping table but EVPN Network OAM won't. With that, I 
suggest to clarify that when an UP MEP at PE interacts with an UP MEP at remote 
PE, it's EVPN Network OAM, and when an UP MEP at PE interacts with a Down MEP 
at remote CE, it's EVPN Service OAM.




> In section 2.2, it says
>
> "
> The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP
>  Advertisement route. Since these are not subject to mobility, they
>  SHOULD be advertised with the static (sticky) bit set (see Section
>  15.2 of [RFC7432]).
> "
>
> In my opinion "MEP/MIP" should be substituted by "MIP", because as I
> said above, the MEP at the EVPN PE should be a Down MEP, it's peer
> MEP is at locally attached CE, there is no need to advertise it to
> remote PEs.

See my response above. By the way, I think if there is a MIP at PE1
then an UP MEP at a remote PE can run through the MIP to a CE local to
PE1 (actually, to be precise, to the PE facing port of that CE).



 I agree to your example that a Down MEP at local CE can interact with an 
UP MEP at the remote PE, although I suspect that the operator would like to 
deploy it. With that, no any changes needed here.




> In section 3.1.2.2, it says
>
> "EVPN Service OAM mechanisms only have visibility to the PEs but not
>  the MPLS/IP P nodes. As such, they can be used to deduce whether the
>  fault is in the customer's own network, the local CE-PE segment or
>  remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms
>  can be used for fault isolation between the PEs and P nodes."
>
> Considering in section 2.3 the first sentence reads "EVPN Network
> OAM is visible to the PE nodes only", I suggest to rephrase this
> paragraph possibly as below:
>
> "EVPN Service OAM and EVPN Network OAM mechanisms only have
> visibility to the PEs but not the MPLS/IP P nodes. As such, they can
> be used to deduce whether the fault is in the customer's own
> network, the local CE-PE segment, the PE-PE segment or the remote
> CE-PE segment(s). EVPN Transport OAM mechanisms can be used for
> fault isolation between the PEs and P nodes."

Your suggested change looks OK to me.

> Section 3.1.2.1, there is a typo, s/to rest a representative path
> between PEs/to test a representative path between PEs.

OK, we'll fix that.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> Best Regards,
>
> Xiao Min
>
> 原始邮件
> 发件人：Bocci,Matthew(Nokia-GB) 
> 收件人：draft-ietf-bess-evpn-oam-req-fr...@ietf.org 
> ;bess@ietf.org ;
> 日 期 ：2020年06月15日 18:56
> 主 题 ：[bess] WG Last Call and IPR Poll fordraft-ietf-bess-evpn-oam-req-frmwk-02
> ___
> BESS mailing list
> BESS@ietf.org
>