Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Linda Dunbar]

Robert,

Thank you very much for the feedback.

If using your suggested Route Target approach to represent the SDWAN Instance 
ID, does it mean that a SDWAN Edge has to use the same approach to configure 
the VRF for SDWAN instances?
If the edge node supports both traditional VPN and SDWAN, will it cause 
confusion for RT to represent both?

RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is encoded 
in the MP_REACH_NLRI Path Attribute.

What do you mean by saying “different name to Route target(s) carried in the 
SAFI 128”?
Do you mean having a different name (say SDWAN_Target) in Extended_Communities 
Path Attribute, and have MP_REACH_NLRI Path Attribute including the SAFI 128?

SDWAN Instance ID is for the control Plane, not to be carried by the data 
packets. SAFI 128 for VPN has the Label encoded in the NLRI field that is to be 
carried by the data packets. But SDWAN Instance ID is not carried by the Data 
Packets. Is it correct?

Thank you.
Linda




From: Robert Raszuk 
Sent: Monday, March 23, 2020 2:28 PM
To: Linda Dunbar 
Cc: Huaimo Chen ; i...@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using 
SDWAN SAFI to encode SDWAN Instance ID in the NLRI

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a given 
VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances. This 
is precisely what RFC4364 does already and RT import/export is used to indicate 
the instance which given set of reachability belongs. Why to reinvent the wheel 
and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s) 
carried in the SAFI 128 but let's keep the mechanism the same. That would be my 
suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364 does 
not need to run over MPLS data plane. It can run over IPSec or over DTLS or 
over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
IDR experts:

SDWAN is an overlay network arching over multiple types of networks. A SDWAN 
edge node may need to map client traffic to different SDWAN network instances 
(or segmentations).
It might not be feasible to use the AS number in the BGP message to 
differentiate the SDWAN network instances as multiple SDWAN instances may share 
the same AS number.

We would like to hear feedback from IDR group on using similar method as  
Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance ID to  
prefixes.

When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI [RFC8277] 
as:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length | Label |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: NLRI with One Label

We would like to  propose the SDWAN Instance ID being encoded in the Label 
field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length |  SDWAN Instance ID (Label)|Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NLRI with SDWAN Instance ID.

Greatly appreciate any comments or other suggestions..

Thank you,
Linda Dunbar

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Monday, March 23, 2020 9:14 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i...@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?

Hi Linda,

It seems that using another SAFI is a possible solution.

Best Regards,
Huaimo

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Friday, March 20, 2020 12:54 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
i...@ietf.org mailto:i...@ietf.org>>
Cc: 

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

[Ali Sajassi (sajassi)]

Support and not aware of any undisclosed IPR

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

Date: Wednesday, February 26, 2020 at 6:28 AM
To: 'BESS' 
Cc: "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] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Robert Raszuk]

Hi Linda,

I think you are mixing data plane and control plane.

In SDWAN data plane is of no issue as you are interconnecting sites in a
given VPN over mesh of secure tunnels.

You are asking how to keep control plane separate between VPN instances.
This is precisely what RFC4364 does already and RT import/export is used to
indicate the instance which given set of reachability belongs. Why to
reinvent the wheel and do something new just for the heck of it :) ?

To be original you can at best invent a different name to Route target(s)
carried in the SAFI 128 but let's keep the mechanism the same. That would
be my suggestion.

Kind regards,
R.

PS. While this is obvious for some many folks are still confused. RFC4364
does not need to run over MPLS data plane. It can run over IPSec or over
DTLS or over UDP/IP just fine.

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar 
wrote:

> IDR experts:
>
>
>
> SDWAN is an overlay network arching over multiple types of networks. A
> SDWAN edge node may need to map client traffic to different SDWAN network
> instances (or segmentations).
>
> It might not be feasible to use the AS number in the BGP message to
> differentiate the SDWAN network instances as multiple SDWAN instances may
> share the same AS number.
>
>
>
> We would like to hear feedback from IDR group on using similar method as
>  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance
> ID to  prefixes.
>
>
>
> When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI
> [RFC8277] as:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length | Label |Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Figure 2: NLRI with One Label
>
>
>
> We would like to  propose the SDWAN Instance ID being encoded in the Label
> field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:
>
>
>
>   0   1   2   3
>
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |Length |  SDWAN Instance ID (Label)|Rsrv |S|
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  |  Prefix   ~
>
>  ~   |
>
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> NLRI with SDWAN Instance ID.
>
>
>
> Greatly appreciate any comments or other suggestions..
>
>
>
> Thank you,
>
> Linda Dunbar
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Monday, March 23, 2020 9:14 AM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that using another SAFI is a possible solution.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Linda Dunbar 
> *Sent:* Friday, March 20, 2020 12:54 AM
> *To:* Huaimo Chen ; i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* RE: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Huaimo,
>
>
>
> Thank you very much for the suggestion.
>
> Do you mean using the similar approach as VPN Label carried by NLRI Path
> Attribute [RFC8277] for SDWAN Segmentation Identifier?
>
> If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to
> avoid confusion, right?
>
>
>
> Linda
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Thursday, March 19, 2020 6:45 PM
> *To:* Linda Dunbar ; i...@ietf.org
> *Cc:* bess@ietf.org
> *Subject:* Re: [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> Hi Linda,
>
>
>
> It seems that a label may be used as an "Identifier" to differentiate
> SD-WAN Segmentation.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Idr  on behalf of Linda Dunbar <
> linda.dun...@futurewei.com>
> *Sent:* Thursday, March 19, 2020 1:22 PM
> *To:* i...@ietf.org 
> *Cc:* bess@ietf.org 
> *Subject:* [Idr] FW: Is there any problem of using Private AS as
> "Identifier" to differentiate SD-WAN Segmentation for
> draft-dunbar-bess-bgp-sdwan-usage?
>
>
>
> BGP Experts,
>
>
>
> Do you 

[bess] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

[Linda Dunbar]

IDR experts:

SDWAN is an overlay network arching over multiple types of networks. A SDWAN 
edge node may need to map client traffic to different SDWAN network instances 
(or segmentations).
It might not be feasible to use the AS number in the BGP message to 
differentiate the SDWAN network instances as multiple SDWAN instances may share 
the same AS number.

We would like to hear feedback from IDR group on using similar method as  
Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance ID to  
prefixes.

When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI [RFC8277] 
as:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length | Label |Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: NLRI with One Label

We would like to  propose the SDWAN Instance ID being encoded in the Label 
field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Length |  SDWAN Instance ID (Label)|Rsrv |S|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Prefix   ~
 ~   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NLRI with SDWAN Instance ID.

Greatly appreciate any comments or other suggestions.

Thank you,
Linda Dunbar

From: Huaimo Chen 
Sent: Monday, March 23, 2020 9:14 AM
To: Linda Dunbar ; i...@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?

Hi Linda,

It seems that using another SAFI is a possible solution.

Best Regards,
Huaimo

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Friday, March 20, 2020 12:54 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
i...@ietf.org mailto:i...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: RE: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?


Huaimo,



Thank you very much for the suggestion.

Do you mean using the similar approach as VPN Label carried by NLRI Path 
Attribute [RFC8277] for SDWAN Segmentation Identifier?

If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to avoid 
confusion, right?



Linda



From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Thursday, March 19, 2020 6:45 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
i...@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Hi Linda,



It seems that a label may be used as an "Identifier" to differentiate 
SD-WAN Segmentation.



Best Regards,

Huaimo



From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Linda Dunbar mailto:linda.dun...@futurewei.com>>
Sent: Thursday, March 19, 2020 1:22 PM
To: i...@ietf.org mailto:i...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: [Idr] FW: Is there any problem of using Private AS as "Identifier" to 
differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



BGP Experts,



Do you know if  there is any problem of using  Private AS as  "Identifier" to 
differentiate SD-WAN Segmentation? Here is the discussion in BESS WG. Want to 
get IDR WG feedbacks for this question.



Thank you.

Linda



From: Linda Dunbar
Sent: Thursday, March 19, 2020 11:54 AM
To: Najem, Basil mailto:basil.na...@bell.ca>>; 
bess@ietf.org
Cc: 
draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: Is there any problem of using Private AS as "Identifier" to 
differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Based on Basil's comment on needing an identifier to differentiate SDWAN 
instances, I added a section to  draft-dunbar-bess-bgp-sdwan-usage . Want to 
hear people's feedback.



3.1Requirements

Re: [bess] [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?

[Huaimo Chen]

Hi Linda,

It seems that using another SAFI is a possible solution.

Best Regards,
Huaimo

From: Linda Dunbar 
Sent: Friday, March 20, 2020 12:54 AM
To: Huaimo Chen ; i...@ietf.org 
Cc: bess@ietf.org 
Subject: RE: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?


Huaimo,



Thank you very much for the suggestion.

Do you mean using the similar approach as VPN Label carried by NLRI Path 
Attribute [RFC8277] for SDWAN Segmentation Identifier?

If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to avoid 
confusion, right?



Linda



From: Huaimo Chen 
Sent: Thursday, March 19, 2020 6:45 PM
To: Linda Dunbar ; i...@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" 
to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Hi Linda,



It seems that a label may be used as an "Identifier" to differentiate 
SD-WAN Segmentation.



Best Regards,

Huaimo



From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Linda Dunbar mailto:linda.dun...@futurewei.com>>
Sent: Thursday, March 19, 2020 1:22 PM
To: i...@ietf.org mailto:i...@ietf.org>>
Cc: bess@ietf.org mailto:bess@ietf.org>>
Subject: [Idr] FW: Is there any problem of using Private AS as "Identifier" to 
differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



BGP Experts,



Do you know if  there is any problem of using  Private AS as  "Identifier" to 
differentiate SD-WAN Segmentation? Here is the discussion in BESS WG. Want to 
get IDR WG feedbacks for this question.



Thank you.

Linda



From: Linda Dunbar
Sent: Thursday, March 19, 2020 11:54 AM
To: Najem, Basil mailto:basil.na...@bell.ca>>; 
bess@ietf.org
Cc: 
draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: Is there any problem of using Private AS as "Identifier" to 
differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Based on Basil’s comment on needing an identifier to differentiate SDWAN 
instances, I added a section to  draft-dunbar-bess-bgp-sdwan-usage . Want to 
hear people’s feedback.



3.1Requirements
3.1.1Supporting Multiple SDWAN Segmentations

The term “network segmentation” is used extensively in SDWAN deployment.. In 
general (and in this document), the “Network Segmentation” is referring to the 
process of dividing the network into logical sub-networks using isolation 
techniques on a forwarding device such as a switch, router, or firewall. For a 
homogeneous network, such as MPLS VPN or Layer 2 network, VRF or VLAN are used 
to separate network segments.

As SDWAN is an overlay network arching over multiple types of networks, it is 
important to have distinct identifiers to differentiate SDWAN network instances 
(or segmentations). When different SDWAN network segments do not have their own 
assigned AS numbers, a very easy way is to use Private AS numbers, in the range 
of 64512 to 65535, to differentiate different SDWAN segmentations. When using 
BGP to control the SDWAN networks, the Private AS numbers are carried by the 
BGP UPDATE messages to their corresponding RRs.



Greatly appreciate any feedback on this description.



Is there any scenario that Private AS cannot be used?



Thank you very much.



Linda Dunbar



From: Najem, Basil mailto:basil.na...@bell.ca>>
Sent: Friday, February 7, 2020 3:02 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bess@ietf.org
Cc: 
draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description 
of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation







Hi Linda;



The SD-WAN Segment is part of the SD-WAN fabric; in other words, there could be 
more than one Segment over a single underlay depending on the design and the 
business requirements.



Each Segment represents a single and an isolated L3 domain; therefore, I 
suggested that we may need to include the Segment ID in the BGP update messages 
in order to identify and build the routing the table for each Segment (based on 
the Segment ID).



Hope this helps.



Regards;



Basil





From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: February-03-20 10:40 AM
To: Najem, Basil mailto:basil.na...@bell.ca>>; 
bess@ietf.org
Cc: 
draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: [EXT]RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage 
description of using BGP UPDATE messages to achieve SD-WAN Application Based 
Segmentation



Basil,



Thank you very much for the comments.

Your suggested wording change will be 

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

[Eric C Rosen]

I am unaware of any undisclosed IPR applicable to this document.

On 2/26/20 9:25 AM, slitkows.i...@gmail.com wrote:


Hi WG,

This email starts a two weeks Working GroupLast 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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess