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] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[Jeff Tantsura]

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

[bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

[stephane.litkowski]

Hi,

There are some Nits to fix:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-igmp-mld-proxy-03.txt


Here is my review of the document:

Abstract & Intro:
s/RFC 7432/ RFC7432.
The reference should be removed from the abstract (as per IDNits).


§2.1:
It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD 
in the paragraph. This comment could apply to various other places of the 
document.

§2.1.1:

-"it only sends a single BGP
   message corresponding to the very first IGMP Join".
[SLI] Do we really care about the IGMP message (first or second...) used as a 
source to build the EVPN route ? The important point is that we do it only one 
time.


-  For MLD what is the expected behavior in term of flag setting in the 
SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 
and then we set v3 ?


-  s/BGP is a statefull/BGP is a stateful  ?

-  In 1),  for clarity purpose, it would be good to separate the (*,G) 
and (S,G) case in two separate paragraphs. At the first read, when reading "In 
case of IGMPv3, exclude flag...", I thought it was always applicable for IGMPv3 
which does not make sense, while it is applicable only "If the IGMP Join is for 
(*,G)".


-  IMO, 1) 2) 3) and 4) should use normative language



-  Wouldn't it be better to present the encoding of SMET before ? 
Because the text talks about fields set in the route while it hasn't been 
presented yet.



-  5) talks about errors that SHOULD be logged, but from a BGP 
perspective, is it considered as a BGP error ? What is the expected behavior 
per RFC7606 ?



-  7) is not clear about IGMPv3, the first part of the text tells that 
the IGMP Join must not be sent if there is no PIM router. While the end of the 
text tells that it is not a problem for IGMPv3. So is there a difference 
between IGMPv2 and IGMPv3 reports ?
§2.1.2:

-  You have a paragraph numbering issue "IGMP Leave Group Advertisement 
in BGP" should be 2.1.2

-  As for §2.1.1, normative language should be used

-  2) I agree that there is an error when a SMET is received with all 
version flags unset. How does the receiver handle this ? does it consider the 
NLRI has withdrawn per RFC7606 from a BGP perspective ? Does it the the current 
state of the route and ignore the update ? Does it close the session ?

-  2) "If the PE receives an EVPN SMET route withdraw, then it must
   remove the remote PE from the OIF list associated with that multicast
   group." This text is a duplicate on 3).



§2.2:
s/each PE need to have/each PE MUST have/ ?

§4:
s/support IGMP sync procedures/support IGMP synchronization procedures/

§4.1:
s/The IGMP Join Sync route carries the ES-Import RT/ The IGMP Join Sync route 
MUST carry the ES-Import RT/

Again, the paragraph lacks of normative language

§4.3:
s/procedure section(4.1)/the procedure defined in section 4.1/
s/Remote PE (PE/Remote PEs (PEs/

§5:
Need to use normative language

The paragraph uses IGMP Join Sync Route or Leave Sync route while §7 uses 
Multicast Join Synch Route. Please ensure consistency. This applies to other 
sections of the document.


§6:
Please expand "IR" in the title and add it into the acronyms section.

"all of the PEs in the BD support that tunnel type and IGMP", do you mean IGMP 
proxy ?


§7.1 brings some clarification about MLD usage which wasn't clear in section 2.
However §2 is still confusing in version numbers between IGMP and MLD. As an 
example, a SMET with a source must not exist with IGMPv2/1 while it must not 
with MLDv1 only.

§7.1.1

"Support for this route type is
   optional.". With regards to RFC7432, yes. However if an implementation 
supports this draft, the support of the NLRI is mandatory.


§7.3.1
Typo is the title: s/Multicas/Multicast/

§7.4:
s/it Must set the IGMP Proxy/it MUST set the IGMP/MLD Proxy/
Could we have some device that support IGMP proxy but not MLD proxy ?


§9:
s/RECOMENDED/RECOMMENDED

§10:
Does it change something to IGMP/MLD security ? Maybe this should be mentioned 
as well

References:
I think that IGMP and MLD RFCs should be set as normative. You should add 
MLDv1, IGMPv2, IGMPv1 as references as well and use the references in the text.

RFC7387 and 7623 are referenced but not used

s/FC4541/RFC4541/

RFC7606 and 4684 should be set as normative


Brgds,


[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 

[bess] The BESS WG has placed draft-rabadan-bess-vendor-evpn-route in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The BESS WG has placed draft-rabadan-bess-vendor-evpn-route in state
Call For Adoption By WG Issued (entered by Stephane Litkowski)

The document is available at
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] Publication has been requested for draft-ietf-bess-nsh-bgp-control-plane-12

[Stephane Litkowski via Datatracker]

Stephane Litkowski has requested publication of 
draft-ietf-bess-nsh-bgp-control-plane-12 as Proposed Standard on behalf of the 
BESS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

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

[bess] New version of draft-ietf-bess-nsh-bgp-control-plane

[Adrian Farrel]

Hi again,

Finally got around to a very minor change resulting from Stephane's shepherd
review. Sorry for the delay.

The effect of the change is that attributes (that have not been correlated)
can't simply be timed out.

Best,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 20 August 2019 12:30
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-12.txt


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

Title   : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-12.txt
Pages   : 59
Date: 2019-08-20

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-
12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-12.txt

[internet-drafts]

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

Title   : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Jim Uttaro
  Luay Jalil
Filename: draft-ietf-bess-nsh-bgp-control-plane-12.txt
Pages   : 59
Date: 2019-08-20

Abstract:
   This document describes the use of BGP as a control plane for
   networks that support Service Function Chaining (SFC).  The document
   introduces a new BGP address family called the SFC AFI/SAFI with two
   route types.  One route type is originated by a node to advertise
   that it hosts a particular instance of a specified service function.
   This route type also provides "instructions" on how to send a packet
   to the hosting node in a way that indicates that the service function
   has to be applied to the packet.  The other route type is used by a
   Controller to advertise the paths of "chains" of service functions,
   and to give a unique designator to each such path so that they can be
   used in conjunction with the Network Service Header defined in RFC
   8300.

   This document adopts the SFC architecture described in RFC 7665.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-12
https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[bess] New version of draft-ietf-bess-datacenter-gateway

[Adrian Farrel]

Hi Bess,

This revision is mainly a keep-alive, but I did fix an (embarrassing) bug in
the name of the IANA registry.

Thanks,
Adrian

-Original Message-
From: BESS  On Behalf Of internet-dra...@ietf.org
Sent: 20 August 2019 12:09
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-03.txt


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

Title   : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-03.txt
Pages   : 12
Date: 2019-08-20

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a popular protocol mechanism for use within a data
   center, but also for steering traffic that flows between two data
   center sites.  In order that one data center site may load balance
   the traffic it sends to another data center site, it needs to know
   the complete set of gateway routers at the remote data center, the
   points of connection from those gateways to the backbone network, and
   the connectivity across the backbone network.

   Segment Routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-03
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[bess] I-D Action: draft-ietf-bess-datacenter-gateway-03.txt

[internet-drafts]

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

Title   : Gateway Auto-Discovery and Route Advertisement for 
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
  John Drake
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-03.txt
Pages   : 12
Date: 2019-08-20

Abstract:
   Data centers are critical components of the infrastructure used by
   network operators to provide services to their customers.  Data
   centers are attached to the Internet or a backbone network by gateway
   routers.  One data center typically has more than one gateway for
   commercial, load balancing, and resiliency reasons.

   Segment Routing is a popular protocol mechanism for use within a data
   center, but also for steering traffic that flows between two data
   center sites.  In order that one data center site may load balance
   the traffic it sends to another data center site, it needs to know
   the complete set of gateway routers at the remote data center, the
   points of connection from those gateways to the backbone network, and
   the connectivity across the backbone network.

   Segment Routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-03
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[Stephane Litkowski]

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