Re: [bess] A question about RFC 8317

[Aldrin Isaac]

Btw, the other problem with “two RTs” scheme might be mobility.  The leaf
MAC-VRF can’t  see each others sequence numbers for a MAC.  Please
see/consider my prior email.  Need to address E-Tree for non-MPLS encaps
and in DC settings (think PVLAN).

Cheers,
Aldrin


On Thu, Dec 20, 2018 at 11:42 PM Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Jorge,
> Lots of thanks for a prompt response.
> My conclusion js tbat the "two RTs" scheme should be used with special
> care in E-tree solutions. This was not my impression from the first reading
> of 8317.
>
> Since the "two RTs" scheme is very popular in hub-and-spoke" solutiobs for
> IP VPN, the fact that it is not the universal answer in EVPN E-Tree
> deserves some expla ation IMHO- but I do not see how this can be done in
> IETF.
>
> Thumb typed by Sasha Vainshtein
>
> --
> *From:* Rabadan, Jorge (Nokia - US/Mountain View)  >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi  (
> saja...@cisco.com)
> *Cc:* Samer Salam (ssalam); John E Drake (jdr...@juniper.net);
> ju1...@att.com; sbout...@vmware.com; bess@ietf.org
> *Subject:* Re: A question about RFC 8317
>
>
> Hi Sasha,
>
>
>
> What you are explaining is correct.
>
>
>
> PE3 would flood anything for which MAC DA is unknown to both local ESes.
> That is normal behavior, only that in this case CE-1’s MAC will not be
> learned on PE3 *until CE-1 hashes the traffic to PE3 and not only PE2*
> (which will happen if you have a decent number of flows). **Technically
> speaking**, the E-Tree solution works since you don’t have leaf-to-leaf
> communication. However, I would not use the two RT solution in this
> scenario since it could create unnecessary flooding to local ESes as you
> describe.
>
>
>
> For this scenario I would always use a single RT per EVI, ingress
> filtering for unicast (based on the leaf indication on MAC/IP routes), and
> egress filtering for BUM based on leaf label, as explained in RFC8317.
>
>
>
> My two cents.
>
>
>
> Thank you.
>
> Jorge
>
>
>
>
>
> *From: *Alexander Vainshtein 
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi  (saja...@cisco.com)" <
> saja...@cisco.com>
> *Cc: *"Samer Salam (ssalam)" , "John E Drake (
> jdr...@juniper.net)" , "ju1...@att.com" <
> ju1...@att.com>, "sbout...@vmware.com" , "Rabadan,
> Jorge (Nokia - US/Mountain View)" , "
> bess@ietf.org" 
> *Subject: *A question about RFC 8317
>
>
>
> Ali and all,
>
> I have read RFC 8317 , and I would
> like to clarify a question dealing with Leaf ACs of an EVPN-based E-Tree
> service on All-Active Multi-Homed Ethernet Segments (MH ES).
>
>
>
> The reference model for my question is shown in the Embedded diagram below.
>
>
>
> [image: cid:image002.png@01D49865.895588B0]
>
>
>
> It shows an EVPN E-tree service with one Root customer site and two leaf
> customer sites, where each Leaf CE is dual-homed to the same pair of PEs
> using two different All-Active multi-homed Ethernet Segments.
>
>
>
> Suppose that the scheme with two RTs (one identifying the Root site and
> the other identifying the Leaf sites) is used as described in 4.3.1.
>
>
>
> Suppose also that each MAC-VRF uses per MAC-VRF label assignment as
> defined in section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN
> application label that identifies it as the Egress MAC-VRF, while the
> disposition of the received Ethernet frame within this MAC-VRF is based on
> the destination MAC address. In this case the per MAC-VRF label can be also
> used as the “aliasing” label in the per EVI EAD route.
>
>
>
> PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2
> and PE-3 with the corresponding “aliasing” labels.
>
>
>
> Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally
> from the Leaf CE-1 and advertises this pair in the EVPN MAC/IP
> Advertisement route. With the “two RTs” scheme this route will be accepted
> by the MAC-VRF in PE-1 but it will not be accepted by the MAC-VRF in PE3.
> As a consequence:
>
> -  MAC-VRF in PE-1 will know that this pair has been learned from
> the “blue” all-active MH ES, and therefore can decide to send locally
> received unicast frames with destination MAC address X to PE-3 using the
> corresponding “aliasing label”. No other labels will be included in the EVN
> encapsulation of such  frames because they are received from the Root AC.
>
> -  MAC-VRF in PE-3 will not know anything about MAC address X,
> therefore, when it receives an EVPN-encapsulated frame with this
> destination, *it will treat it as an “unknown unicast” and flood it to
> both Leaf CE-1 (where it should be sent) and to Leaf CE-2 (where it should
> not be sent)*.
>
>
>
> Is this what is really supposed to happen in this scenario? If not, what
> did I miss in the E-tree EVPN solution?
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: 

Re: [bess] A question about RFC 8317

[Aldrin Isaac]

Hi guys,

If we instead consider that the two-RTs scheme from operator point-of-view
is really a Root-only and Leaf-only MAC-VRF scheme (vs mixed root/leaf
MAC-VRF). Suppose all routes from a leaf VRF are marked with a “leaf
indication”. Suppose we use only one RT where leaf MAC-VRF rejects any
route with “leaf indication” except those of local active ESI which are
processes normally. Would we be able to support basic E-Tree behavior for
non-MPLS tunnel types using such a scheme?

Need a way to address basic E-tree with multi-homing in EVPN VXLAN/Geneve,
namely PVLAN.

Cheers,
Aldrin
On Thu, Dec 20, 2018 at 11:42 PM Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Jorge,
> Lots of thanks for a prompt response.
> My conclusion js tbat the "two RTs" scheme should be used with special
> care in E-tree solutions. This was not my impression from the first reading
> of 8317.
>
> Since the "two RTs" scheme is very popular in hub-and-spoke" solutiobs for
> IP VPN, the fact that it is not the universal answer in EVPN E-Tree
> deserves some expla ation IMHO- but I do not see how this can be done in
> IETF.
>
> Thumb typed by Sasha Vainshtein
>
> --
> *From:* Rabadan, Jorge (Nokia - US/Mountain View)  >
> *Sent:* Thursday, December 20, 2018 7:31:20 PM
> *To:* Alexander Vainshtein; Ali Sajassi  (
> saja...@cisco.com)
> *Cc:* Samer Salam (ssalam); John E Drake (jdr...@juniper.net);
> ju1...@att.com; sbout...@vmware.com; bess@ietf.org
> *Subject:* Re: A question about RFC 8317
>
>
> Hi Sasha,
>
>
>
> What you are explaining is correct.
>
>
>
> PE3 would flood anything for which MAC DA is unknown to both local ESes.
> That is normal behavior, only that in this case CE-1’s MAC will not be
> learned on PE3 *until CE-1 hashes the traffic to PE3 and not only PE2*
> (which will happen if you have a decent number of flows). **Technically
> speaking**, the E-Tree solution works since you don’t have leaf-to-leaf
> communication. However, I would not use the two RT solution in this
> scenario since it could create unnecessary flooding to local ESes as you
> describe.
>
>
>
> For this scenario I would always use a single RT per EVI, ingress
> filtering for unicast (based on the leaf indication on MAC/IP routes), and
> egress filtering for BUM based on leaf label, as explained in RFC8317.
>
>
>
> My two cents.
>
>
>
> Thank you.
>
> Jorge
>
>
>
>
>
> *From: *Alexander Vainshtein 
> *Date: *Thursday, December 20, 2018 at 12:30 PM
> *To: *"Ali Sajassi  (saja...@cisco.com)" <
> saja...@cisco.com>
> *Cc: *"Samer Salam (ssalam)" , "John E Drake (
> jdr...@juniper.net)" , "ju1...@att.com" <
> ju1...@att.com>, "sbout...@vmware.com" , "Rabadan,
> Jorge (Nokia - US/Mountain View)" , "
> bess@ietf.org" 
> *Subject: *A question about RFC 8317
>
>
>
> Ali and all,
>
> I have read RFC 8317 , and I would
> like to clarify a question dealing with Leaf ACs of an EVPN-based E-Tree
> service on All-Active Multi-Homed Ethernet Segments (MH ES).
>
>
>
> The reference model for my question is shown in the Embedded diagram below.
>
>
>
> [image: cid:image002.png@01D49865.895588B0]
>
>
>
> It shows an EVPN E-tree service with one Root customer site and two leaf
> customer sites, where each Leaf CE is dual-homed to the same pair of PEs
> using two different All-Active multi-homed Ethernet Segments.
>
>
>
> Suppose that the scheme with two RTs (one identifying the Root site and
> the other identifying the Leaf sites) is used as described in 4.3.1.
>
>
>
> Suppose also that each MAC-VRF uses per MAC-VRF label assignment as
> defined in section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN
> application label that identifies it as the Egress MAC-VRF, while the
> disposition of the received Ethernet frame within this MAC-VRF is based on
> the destination MAC address. In this case the per MAC-VRF label can be also
> used as the “aliasing” label in the per EVI EAD route.
>
>
>
> PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2
> and PE-3 with the corresponding “aliasing” labels.
>
>
>
> Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally
> from the Leaf CE-1 and advertises this pair in the EVPN MAC/IP
> Advertisement route. With the “two RTs” scheme this route will be accepted
> by the MAC-VRF in PE-1 but it will not be accepted by the MAC-VRF in PE3.
> As a consequence:
>
> -  MAC-VRF in PE-1 will know that this pair has been learned from
> the “blue” all-active MH ES, and therefore can decide to send locally
> received unicast frames with destination MAC address X to PE-3 using the
> corresponding “aliasing label”. No other labels will be included in the EVN
> encapsulation of such  frames because they are received from the Root AC.
>
> -  MAC-VRF in PE-3 will not know anything about MAC address X,
> therefore, when it receives an EVPN-encapsulated frame with this
> destination, *it will treat it as an “unknown 

Re: [bess] Call for adoption: draft-lin-bess-evpn-irb-mcast

[Aldrin Isaac]

+1. Support fully.

Cheers,
Aldrin
On Sat, Jan 13, 2018 at 7:57 PM Henderickx, Wim (Nokia - BE/Antwerp) <
wim.henderi...@nokia.com> wrote:

> support
>
> On 11/01/2018, 10:50, "BESS on behalf of Rabadan, Jorge (Nokia -
> US/Mountain View)"  jorge.raba...@nokia.com> wrote:
>
> Support as co-author. Not aware of any IPR relevant to this document.
>
> This is an important document. It describes a solution that integrates
> L2/L3 multicast in a very efficient and simplified way, under a single
> control plane protocol. It will be key for multicast applications in Data
> Centers and overlay networks. This revision is very mature already and
> includes all the details needed for the implementation, therefore it is
> ready for adoption.
>
> Thank you.
> Jorge
>
>
> -Original Message-
> From: Martin Vigoureux 
> Date: Thursday, January 11, 2018 at 2:12 AM
> To: "bess@ietf.org" 
> Cc: "draft-lin-bess-evpn-irb-mc...@ietf.org" <
> draft-lin-bess-evpn-irb-mc...@ietf.org>
> Subject: Call for adoption: draft-lin-bess-evpn-irb-mcast
> Resent-From: 
> Resent-To: , , <
> jdr...@juniper.net>, , , <
> saja...@cisco.com>
> Resent-Date: Thursday, January 11, 2018 at 2:12 AM
>
> Hello working group,
>
> This email starts a two-week call for adoption on
> draft-lin-bess-evpn-irb-mcast-04 [1] as a BESS 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 26th of January*.
>
> 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.
>
> Thank you
>
> Martin & Stéphane
> bess chairs
>
> [1]
> https://datatracker.ietf.org/doc/draft-lin-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
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Aldrin Isaac]

Support this document for publication as an RFC.   Not aware of any IPR that 
relates to this document.

Cheers,
Aldrin

From: Aldrin Isaac <ais...@juniper.net>
Date: Friday, June 16, 2017 at 6:09 PM
To: Ravi Shekhar <rshek...@juniper.net>, "Rabadan, Jorge (Nokia - US/Mountain 
View)" <jorge.raba...@nokia.com>, "EXT - thomas.mo...@orange.com" 
<thomas.mo...@orange.com>, BESS <bess@ietf.org>, 
"draft-ietf-bess-evpn-optimized...@ietf.org" 
<draft-ietf-bess-evpn-optimized...@ietf.org>
Subject: Re: WG Last Call for draft-ietf-bess-evpn-optimized-ir

Yes -- support for publication.

Cheers,
Aldrin

Sent using OWA for iPhone

From: Ravi Shekhar <rshek...@juniper.net>
Sent: Friday, June 16, 2017 11:46:10 AM
To: Rabadan, Jorge (Nokia - US/Mountain View); EXT - thomas.mo...@orange.com; 
BESS; draft-ietf-bess-evpn-optimized...@ietf.org
Subject: RE: WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support as co-author as well. Not aware of any IPR.
- Ravi Shekhar.

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Friday, June 16, 2017 11:35 AM
To: EXT - thomas.mo...@orange.com <thomas.mo...@orange.com>; BESS 
<bess@ietf.org>; draft-ietf-bess-evpn-optimized...@ietf.org
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support this document for Standard Track RFC publication as co-author.
Not aware of any IPR.

Already mentioned, Nokia SROS has an implementation.

Thank you.
Jorge


On 6/16/17, 3:43 PM, "thomas.mo...@orange.com" <thomas.mo...@orange.com> wrote:

Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-optimized-ir-01 [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 *30th 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 Standard
Track RFC.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-evpn-optimized-ir, 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 the draft
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,
T

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



_

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 Last Call for draft-ietf-bess-evpn-usage

[Aldrin Isaac]

I support to move this document forward to publication.  There are no
IPR that I am aware of related to this document.

Apologies for leaving out IPR statement.

Regards -- Aldrin



On Mon, Jun 12, 2017 at 12:52 PM Aldrin Isaac <aldrin.is...@gmail.com>
wrote:

> Yes. I support to move this forward.
>
> Regards -- Aldrin
> On Mon, Jun 12, 2017 at 3:39 PM UTTARO, JAMES <ju1...@att.com> wrote:
>
>> *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 <martin.vigour...@nokia.com>
>> *Cc:* BESS <bess@ietf.org>
>> *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 <
>> martin.vigour...@nokia.com> 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/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Devpn-2Dusage_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=NsXRNCpI-XG9vxejXm9NHxu1FVv_j2gAG3NSW3vZPh8=RuJG5P3GiwU0kDVlo12PU41vXQ4DzY-_xqvgolWjkq4=>
>> [2]
>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_bess_cG3X1tTqb-5FvPC4rg56SEdkjqDpw=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=NsXRNCpI-XG9vxejXm9NHxu1FVv_j2gAG3NSW3vZPh8=tLVXhULe4bJzbVBsBOybultgu62EreH6szg5v5-j5As=>
>>
>> ___
>> BESS mailing list
>> 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=NsXRNCpI-XG9vxejXm9NHxu1FVv_j2gAG3NSW3vZPh8=ocQqmy844e0BOlY73StBUg5Zh5vxs8JaCD6hhDXfm7Q=>
>>
>>
>> ___
>> 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 for draft-ietf-bess-evpn-optimized-ir

[Aldrin Isaac]

Yes -- support for publication.

Cheers,
Aldrin

Sent using OWA for iPhone

From: Ravi Shekhar 
Sent: Friday, June 16, 2017 11:46:10 AM
To: Rabadan, Jorge (Nokia - US/Mountain View); EXT - thomas.mo...@orange.com; 
BESS; draft-ietf-bess-evpn-optimized...@ietf.org
Subject: RE: WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support as co-author as well. Not aware of any IPR.
- Ravi Shekhar.

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Friday, June 16, 2017 11:35 AM
To: EXT - thomas.mo...@orange.com ; BESS 
; draft-ietf-bess-evpn-optimized...@ietf.org
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-optimized-ir

Support this document for Standard Track RFC publication as co-author.
Not aware of any IPR.

Already mentioned, Nokia SROS has an implementation.

Thank you.
Jorge


On 6/16/17, 3:43 PM, "thomas.mo...@orange.com"  wrote:

Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-optimized-ir-01 [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 *30th 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 Standard
Track RFC.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-evpn-optimized-ir, 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 the draft
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,
T

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



_

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 Last Call for draft-ietf-bess-evpn-usage

[Aldrin Isaac]

Yes. I support to move this forward.

Regards -- Aldrin
On Mon, Jun 12, 2017 at 3:39 PM UTTARO, JAMES  wrote:

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

Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01

[Aldrin Isaac]

I would also like to indicate my support.  
Cheers,Aldrin






On Tue, Jan 31, 2017 at 6:58 AM -0800, "Thomas Morin"  
wrote:










Hello working group,

This email starts a two-week poll on adopting 
draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or 
not (in the later case, please also state the reasons).

This poll runs until **February 14th**.

*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 adopted 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.

Thank you,

Martin & Thomas
bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01

___
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] Poll for adoption: draft-rabadan-bess-evpn-ac-df

[Aldrin Isaac]

Support.
On Tue, Aug 30, 2016 at 10:38 AM Nabeel Cocker 
wrote:

> support
>
> thanks
> Nabeel
>
> On Tue, Aug 30, 2016 at 4:45 AM, Thomas Morin 
> wrote:
>
>> Hello working group,
>>
>> This email starts a two-week poll on adopting
>> draft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document.
>>
>> Please state on the list if you support adoption or not (in both cases,
>> please also state the reasons).
>>
>> This poll runs until *September 14th*.
>>
>> 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.
>>
>> At this date, no IPR has been disclosed against this Document.
>>
>> 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://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-ac-df
>>
>> ___
>> 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] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03

[Aldrin Isaac]

Support as well.  






On Tue, Aug 16, 2016 at 5:37 AM -0700, "Martin Vigoureux" 
 wrote:










Hello working group,

This email starts a two-week poll on adopting
draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group 
Document.

Please state on the list if you support adoption or not (in both cases, 
please also state the reasons).

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

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.
No IPR has been disclosed against this Document

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://datatracker.ietf.org/doc/draft-zzhang-bess-evpn-bum-procedure-updates/

___
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

[Aldrin Isaac]

I support as co-author. Not aware of any related IPR.
Cheers,
Aldrin

On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin 
wrote:

> 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

Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02

[Aldrin Isaac]

Support as co-author. IETF should adopt this use-case -- optimized
multi-destination forwarding for overlays where multicast support is not
available in the underlay. I am not aware of any related IPR.

On Tue, Jan 26, 2016 at 12:12 AM Thomas Morin 
wrote:

> Hello working group,
>
> This email starts a two-week poll on adopting
> draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item.
>
> Please send comments to the list and state if you support adoption or
> not (in the later case, please also state the reasons).
>
> This poll runs until **February 9th**.
>
>
> *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 adopted 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.
>
> Thank you,
>
> Martin & Thomas
> bess chairs
>
> [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Poll for adoption: draft-sajassi-bess-evpn-etree

[Aldrin Isaac]

Support as co-author.  Unaware of any related IPR.

Cheers,
Aldrin

On Tue, May 19, 2015 at 3:22 PM, Martin Vigoureux 
martin.vigour...@alcatel-lucent.com wrote:

 Hello working group,

 This email starts a two-week poll on adopting
 draft-sajassi-bess-evpn-etree [1] as a working group item.

 Please send comments to the list and state if you support adoption or
 not (in the later case, please also state the reasons).

 This poll runs until **June the 2nd**.


 *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 adopted 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.

 Thank you,

 Martin  Thomas
 bess chairs

 [1] https://tools.ietf.org/html/draft-sajassi-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

Re: [bess] Poll for adoption: draft-sajassi-bess-evpn-vpls-seamless-integ

[Aldrin Isaac]

Support.

On Monday, January 26, 2015, Martin Vigoureux 
martin.vigour...@alcatel-lucent.com wrote:

 Hello working group,

 This email starts a two-week poll on adopting
 draft-sajassi-bess-evpn-vpls-seamless-integ [1] as a working group item.

 Please send comments to the list and state if you support adoption or
 not (in the later case, please also state the reasons).

 This poll runs until **February 9th**.


 *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 adopted 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.

 Note that an IPR disclosure [2] exists for this document.

 Thank you,

 Martin  Thomas
 bess chairs

 [1] https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpls-
 seamless-integ
 [2] https://datatracker.ietf.org/ipr/2472/

 ___
 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