Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-service-chaining

Hi Stéphane, all, On 03/09/2018 10:30, stephane.litkow...@orange.com wrote: 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).

Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

All, Martin Vigoureux, 2017-12-05 11:34: > > Alvaro: [...] > > > > What about Geneve (draft-ietf-nvo3-geneve)? The nvo3 WG is > > focusing on > > Geneve as the Standard encapsulation, but this document doesn’t > > even mention it. > > Indeed. But The decision by NVO3 to work on Geneve is fairl

Re: [bess] New bess Co-Chair

Alvaro Retana, 2017-12-01 11:16: > I am sad to report that Thomas Morin has decided not to continue as > bess Co-Chair due to the demands of his job. Thomas: thank you for > all the effort you have put into the WG, we all look forward to your > continued contributions to the IETF! Thank you Alvar

[bess] Re : WGLC for draft-ietf-idr-tunnel-encaps-07

Support. -Thomas John Scudder, 2017-10-06 14:39: > [resending with corrected draft alias in cc, sorry about that] > > Hi All, > > A working group last call has been requested for draft-ietf-idr- > tunnel-encaps-07. Please reply to the list with your comments. As > usual note we cannot advance

Re: [bess] RtgDir review: draft-ietf-bess-evpn-etree-12

Hi Ravi, Many thanks for this review. One question below... Ravi Singh, 2017-08-16 06:56: > The only major comments pertain to > a.   Sections 5.2/8.1: which appear like an overkill and could be > considered for dropping from text. [...] Can you expand on why you this this is overkill ? T

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

Hi everyone, This call was missing a formal closure... This document is considered ready to move to the next stage. Best, -Thomas Thomas Morin, 2017-06-16 15:43: > Hello Working Group, > > This email starts a Working Group Last Call on  > draft-ietf-bess-evpn-optimized-ir-01 [1] which is c

Re: [bess] Call for adoption: draft-rabadan-bess-evpn-pref-df / adopted !

Hi everyone, We have a new working group document! Can authors please repost as draft-ietf-bess-evpn-pref-df-00 ? Thanks, Thomas & Martin 2017-06-06, Thomas Morin: Hello working group, This email starts a two-week call for adoption on draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Gro

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

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

[bess] Call for adoption: draft-rabadan-bess-evpn-pref-df

Hello working group, This email starts a two-week call for adoption on draft-rabadan-bess-evpn-pref-df-02 [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 20th of June*. We a

Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

Ok, thanks for the update and for progressing this work! -Thomas 2017-06-01, Hiroshi Tsunoda: Hi Thomas, Glenn Sorry, this is my fault. I think Glenn is waiting for the new revision because the last revision posted in March does not have essential improvement. I am going to make a major upda

Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

Hi Glenn, Thanks for the reviews on the other mvpn-related MIB (draft-ietf-bess-l2l3-vpn-mcast-mib-03). We would like to have an idea of what is the progress around this draft. Do you know when you could do a review of the revision posted in early March ? Thanks in advance, -Thomas 2017-

Re: [bess] ietf-bess-fat-pw-bgp

Hi Sami, Noted. -Thomas Sami Boutros a écrit Hi, We recently updated the draft, and we feel it is ready for WG last call. Could you please start the call? Thanks, Sami

[bess] draft minutes from our session at IETF 96

HI everyone, The draft minutes of yesterday's session are here: https://www.ietf.org/proceedings/96/minutes/minutes-96-bess Please read and suggest any relevant correction or adjustment. These minutes will become final on September 12th. Best, -Thomas/Martin

[bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01

Hello working group, This email starts a two-week poll on adopting draft-boutros-bess-vxlan-evpn-01 [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 *July 4th*. We are also polling fo

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Sounds perfect. Thanks, -Thomas Ali Sajassi (sajassi) a écrit Hi Thomas, Referencing the section 8 of idr-tunnel-encap draft is too wide a scope IMHO and maybe confusing, thus I'd like to narrow it down. I went over the both sections 3.5 and 8 of the idr-tunnel-encap draft and with

[bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-overlay

Hello Working Group, (Please read carefully, this e-mail contains new elements compared to WG LCs we were doing in a still recent past.) This email starts a Working Group Last Call on draft-ietf-bess-evpn-overlay [1]. * Please read the document if you haven't read the most recent version yet,

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John, John. When the tunnel encaps draft was first published it did not carry forward the RFC 5512 extended community and it did not propose to obsolete RFC 5512. There was discussion of using the attribute defined in the tunnel encaps draft instead of the extended community and we decide

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

Hi Jorge, all, While looking at pending shepherd write-ups, I noticed that draft-ietf-bess-evpn-etree is also asking for the same sub-type (0x04) [1]. Hopefully there will be a nice way to sort this out, but the lesson is that we collectively fail to get the benefits that a First Come First

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Hi John, I have a hard time reconciliating the fact that yesterday you were fine with having bess-evpn-overlay refer to idr-tunnel-encap instead of RFC5512, with the fact that you consider (belox) the two docs "not aligned" for unicast. Can you be more explicit in where the "misalignment" lies?

Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Thanks for the clarification on the intent around draft-ietf-bess-evpn-overlay. Then indeed section 9 needs some tidying up. The issue that I think remain is that it would be much cleaner to explain how to use PMSI with overlay encaps in a spec not specific to E-VPN and in a way more consistent

[bess] TR: [Technical Errata Reported] RFC4577 (4659)

This errata on RFC4577, "OSPF as the PE/CE Protocol for BGP/MPLS IP VPNs" was reported to l3vpn, now closed, and to original authors for some of whom with obsolete addresses. -Thomas Message original Objet : [Technical Errata Reported] RFC4577 (4659) Envoyé : 8 avr. 2016 9:11 AM De

[bess] IETF 95 meeting, final agenda

Hi everyone, We've just posted an updated agenda (last minute cancellation of draft-hao-bess-evpn-centralized-df-00, replaced by draft-hu-bess-l2vpn-service-yang-00). https://www.ietf.org/proceedings/95/agenda/agenda-95-bess Useful links: - http://tools.ietf.org/wg/bess/agenda?item=agenda-95

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

Hi everyone, This WG Last Call is now closed and the document will move to the next steps toward publication. The modification mentioned below will be incorporated in next release. Best, -Thomas 2016-03-15, Ali Sajassi (sajassi): Jeffrey, On 2/1/16, 2:41 PM, "Jeffrey (Zhaohui) Zhang"

Re: [bess] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree

FYI. The following can now be read at https://datatracker.ietf.org/ipr/2774/ : "Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-etree This IPR disclosure was removed at the submitter's request. " Best, -Thomas IETF Secretariat : Dear Ali Sajassi, Samer Salam,

Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03 / -04

Hi Alvaro, We've posted -04 last week, based on the discussion we had. Please tell us if you think this is ready to move forward. Best, -Thomas 2016-03-09, Alvaro Retana (aretana): On 2/24/16, 11:58 AM, "Thomas Morin" > wrote: Thomas: Hi! There are several p

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

FYI, the disclosure has been made March 8th: https://datatracker.ietf.org/ipr/2765/ -Thomas Le 07/03/2016 13:35, Martin Vigoureux a écrit : Hello Dhananjaya, thanks for the notice. WG, I'll let this poll run for at least a week after the disclosure is made. For those who have already stated t

Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02

Hi Martin, I'm not aware of any related and undisclosed IPR. (and yes, as a co-author, I certainly support adoption!) -Thomas Martin Vigoureux : Hello working group, This email starts a two-week poll on adopting draft-fm-bess-service-chaining-02 [1] as a working group Document. Please state

[bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02

Hello working group, This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [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 19th**.

Re: [bess] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01]

Hi Gunter, all, VAN DE VELDE, Gunter (Gunter) : I had had a read through the document. I think it is a nice clear document which is well written and is to me ready for publication. First thank you very much for this review. Below are a few topics that crossed my mind when digging through

Re: [bess] Introducing a one-implementation requirement before WG last calls

Hi Patrice, 2015-11-26, Patrice Brissette (pbrisset): Have we look at our ³forum² such as OpenStack? Do they have something in place there? Producing standards and producing implementations are different things. Openstack produces implementations, which may then may (or may not) become a de

Re: [bess] Introducing a one-implementation requirement before WG last calls

Hi Loa, Loa Andersson : One can speculate about the reasons for this, but it seems that often the decision whether or not to disclose an implementation is outside the mandate for people participating in immediate IETF process. I would find it quite unlikely to be in a situation where none of t

Re: [bess] Introducing a one-implementation requirement before WG last calls

Hi Andrew, Andrew G. Malis : - There are some (many?) operators that won’t put drafts into an RFP, only RFCs. My take on that is that if a known-stable specs is considered as something important to have, operators will put it in their RFPs (maybe not as a strict compliance requirement, but c

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

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

2015-11-20, Haoweiguo: WH> ok now we have not discussed the constraints some HW vendors have with respect to global VNIDs. To make this work all VNID/Labels need to be globally unique. Hm > [weiguo2]: In SDN scenario, a virtual network normally is represented by a global VN ID or MPLS VPN

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

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 proposal I cannot agree to for the reasons explained. TM> Well, although discussing forever is certainly not the goal,

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Lucy, The tunnel encap also describe how to use the extended community, in section 6. Best, -Thomas Lucy yong a écrit Hi Gunter, Thank you to point to the right section. This overlay draft suggests to use Encapsulation extended community to indicate the type of data plane encapsu

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

John, (Cc'ing IDR.) 2015-11-13, John E Drake: I spoke with Eric and Ali and we would like to change both the overlay draft and the tunnel encaps drafts as follows. For the overlay draft, replace this text in section 5.1.3: "If the BGP Encapsulation extended community is not present, then th

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

Hi Wim, 2015-11-13, Henderickx, Wim (Wim): Thomas, we need a solution that is implementable and will scale in control/data-plane. As such the solution I outline is standardised today and does not need new extensions in control/data-plane. Hence informational draft and can be implemented if the

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

Wim, (below) 2015-11-12, Henderickx, Wim (Wim): Henderickx, Wim (Wim): I don’t support the adoption of this draft as a WG. There is a major flaw in this proposal: Basically the encapsulation of VXLAN/NVGRE is incompatible with MPLS IP-VPNs. VXLAN/NVGRE contains a MAC address and IP-VPNs don’

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

Hi Wim, Thanks for your feedback. With my co-chair hat, let met ask a few questions for the sake of well understanding the issue you raise. Henderickx, Wim (Wim): I don’t support the adoption of this draft as a WG. There is a major flaw in this proposal: Basically the encapsulation of VXLAN/

[bess] IPR issue resulting in an *Extended* Poll for adoption: draft-hao-bess-inter-nvo3-vpn-option

Hi working group, IPR [1] has been disclosed on draft-hao-bess-inter-nvo3-vpn-optionc during the call for adoption (2015-10-26). We regret that this disclosure came this late in the process, and we have to let the working group comment on this call with full awareness of existing IPR. This

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

HI John, Weiguo, John E Drake : It is needed in order to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. An advertising node that only supports MPLS encapsulation does not need to advertise anything.

Re: [bess] The BESS WG has adopted draft-hao-bess-inter-nvo3-vpn-optionc (*not yet*, in fact)

Please ignore this bogus automated email: the document is just being called for adoption, and no decision will be taken before the call for adoption is over. -Thomas 2015-11-02, IETF Secretariat: The BESS WG has adopted draft-hao-bess-inter-nvo3-vpn-optionc (entered by Thomas Morin) The doc

Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

Authors of draft-singh-bess-bgp-vpls-control-flags, working group, The support base for this proposal is not large. Before adopting this draft, we would like hear people actually experiencing pain related to not solving this issue and hear about implementations in actual products. Let's consi

Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover

Martin Vigoureux: *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

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Hi Alvaro, 2015-09-30, Alvaro Retana (aretana): 2015-09-28, Jeffrey (Zhaohui) Zhang: Alvaro, > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References. I thought about this further, and would like to keep them both as informational for the follow

Re: [bess] Comments on draft-ietf-bess-ir

Hi Eric, 2015-09-28, Eric C Rosen: From the draft: "This document does not provide any new protocol elements or procedures" I think we can agree that it does not specify any new protocol elements. > [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be consi

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Hi Jeffrey, Alvaroo, 2015-09-28, Jeffrey (Zhaohui) Zhang: Alvaro, > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References. I thought about this further, and would like to keep them both as informational for the following reasons. The extranet draft is referred t

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Hi Alvaro, [resending, because I had mailer daemon from junipernetworks.onmicrosoft.com] 2015-09-24, Alvaro Retana (aretana): Also, some of the text [...] may not be accesible to the average reader,... As a side note, while what you wrote is true, I would say that it will be hard to fix. M

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Jeffrey, all, [resending this one too...] (below) 2015-09-25, Jeffrey (Zhaohui) Zhang: *From:*Alvaro Retana (aretana) [mailto:aret...@cisco.com] 5. Section 4. (Security Considerations) Are there really no security considerations? * Section 3.1. (Control State) Says that: "To s

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Jeffrey, all, (below) 2015-09-25, Jeffrey (Zhaohui) Zhang: *From:*Alvaro Retana (aretana) [mailto:aret...@cisco.com] 5. Section 4. (Security Considerations) Are there really no security considerations? * Section 3.1. (Control State) Says that: "To speed up convergence…P

Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

Hi Alvaro, 2015-09-24, Alvaro Retana (aretana): Also, some of the text [...] may not be accesible to the average reader,... As a side note, while what you wrote is true, I would say that it will be hard to fix. Most mVPN-related specs are deemed to remain fairly inaccessible to somebody not

[bess] Comments on draft-ietf-bess-ir

Hi everyone, 1. Introduction [...] This document does not provide any new protocol elements or procedures; [...] Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be considered new procedures. (The fact that the document introduces new procedures is fine I think, and n

[bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags

Hello working group, This email starts a two-week poll on adopting draft-singh-bess-bgp-vpls-control-flags-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 **Septemb

[bess] WG Last Call for the two mVPN MIB drafts (draft-ietf-bess-l2l3-vpn-mib and draft-ietf-bess-mvpn-mib)

Hello working group, This email starts a Working Group Last Call on draft-ietf-bess-l2l3-vpn-mcast-mib-01 and draft-ietf-bess-mvpn-mib-01, which are both considered mature and ready for a working group review. One document depends on the other which is why we are last calling them together.

[bess] Prague meeting draft minutes and recording

Hi everyone, Here are the draft minutes for our Prague meeting: https://www.ietf.org/proceedings/93/minutes/minutes-93-bess Please send us any correction or clarification you think is useful (they will become final 2015-08-14). Thanks to the Meetecho team, the full meeting recording with

Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Hi Eric, 2015-07-28, Eric C Rosen: * to allow multicast support in the context of RFC6514/6513, RFC7117, and RFC7432 with a consistent way of advertising the encapsulations,I think that draft-rosen-idr-tunnel-encaps-00 section 2.4 should also consider as a "labelled address family" an AFI/SAFI

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

Weiguo, 2015-07-24, Haoweiguo: I will accept your suggestion about allocating UDP port approach on ASBR-d to save IP address space. However, if the operators want to use IANA assigned VXLAN fixed port, the IP address allocating approach maybe still should be used. Yes, it is ok to say that

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

Hi Weiguo, Haoweiguo : Thomas: Having to configure as many IPs on ASBR-d as there are PEs in the WAN seems to me as being a very strong drawback. I think that it would be better to use a combination of one ore more ASBR-d IP address and multiple destination UDP ports, to reduce the configuratio

Re: [bess] [Idr] 2 week adoption call for draft-rosen-idr-tunnel-enaps-00.txt (7/6 to 7/20/2015)

Hi, I think this draft will be a very useful tool to address different topics, in particular topics related to we integrate encapsulations over an IP transit with BGP VPNs, and I support its adoption by IDR. That said, I have the following comments that need to be addressed: * to allow multi

[bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

Hi, (Without my chair hat,) I have the following comments to offer on draft-hao-bess-inter-nvo3-vpn-optionc-01. I think the proposal has a merit in that it defines how to do Option C in a context where we want one of the AS to use an IP transit rather than MPLS, and this is done preserving t

[bess] Fwd: Routing Area YANG Coordinators Wiki

_ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisati

Re: [bess] Please send you presentations for Prague

To those who present during our session tomorrow, It seems some of the slides haven't been sent yet, and we are close to 7pm. Be ready to see your slot cancelled if you don't send them tonight. Best, -Thomas PS: if you have sent your slides already, but only to one of the chairs, please send

[bess] Extended adoption call in IDR for draft-rosen-idr-tunnel-encaps-00

Hi everyone, IDR chairs have extended the ongoing call for adoption of draft-rosen-idr-tunnel-encaps by IDR, to let BESS participants who would have missed it, comment on this call. Please read this proposal tightly related to BESS work, and send comments to IDR mailing list. -Thomas & Marti

[bess] Fwd: [Idr] 2 week adoption call for draft-rosen-idr-tunnel-encaps-00.txt (7/6 to 7/20/2015)

Hi everyone, This is "heads up" on draft-rosen-idr-tunnel-encaps-00 which is currently being called for adoption by the IDR working group. The call lasts until July 20th, and you are encouraged to comment on IDR mailing-list as you find relevant. Best, -Thomas __

[bess] Agenda for our meeting in Prague

Hi everyone, Face to face time is a scarce resource and we had to make choices. We would like to insist that we think all authors should using the mailing-list *more* and *earlier*, to allow dedicating meeting time to discussions that will most benefit from happening face to face. What is, v

[bess] Draft agenda for our meeting in Prague

Hi everyone, BESS will meet in roughly two weeks in Prague (Monday 15:20-17:20). Here is the *draft* agenda: https://www.ietf.org/proceedings/93/agenda/agenda-93-bess We won't be able to satisfy all the requests for slots and we have already made some choices. However, note well that this draf

Re: [bess] Status of draft-ietf-l3vpn-acceptown-community

Thanks you Pradosh for submitting revision -10. As far as can tell, it is ok to proceed. Best, -Thomas 2015-06-15, Alvaro Retana (aretana): Pradosh?? Thanks! Alvaro. On 5/6/15, 5:41 PM, "David Smith (djsmith)" wrote: Pradosh is working on so I'll defer to him. /dave -Original Messa

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Jorge, Jorge: If you have any other scenario, let’s talk offline. We are boring people ;-) I think its nice to keep the discussion on the list, which is here for a reason (that is, not just for polls for adoption and WG last calls...). I'm sure these clarifications can be useful for some

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

HI Weigo, all, Let me try to help again... RFC7432, section 8.5 says: If a bridged network is multihomed to more than one PE in an EVPN network via switches, then the support of All-Active redundancy mode requires the bridged network to be connected to two or more PEs using a LAG.

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Weiguo, 2015-03-26, Haoweiguo: > Thomas: > - RFC7432 may have transient periods where the DF election state is > not yet synchronized between the two peers: > [weiguo]: Yes, i think RFC 7432 has transient periods of traffic loop Note well that I didn't write that there can be transient _l

Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi, Let me attempt at clarifying the exchange between the few of you. My understanding is that: - RFC7432 already does a good job of avoiding forwarding loops thanks to the split-horizon procedure that does not depend on DF election and has no transient state - RFC7432 may have transient perio

Re: [bess] [Technical Errata Reported] RFC4659 (4087) / IPv6 mandatory for an RFC4364 implem ?

Everyone, Here is my very own interpretation, possibly wrong given that I may not have the full history. The underlying claim of this errata is that the specifications for IPv6 support in IP VPN should officially UPDATE the specifications for IPv4 IP VPNs (RFC4364), so as to convey the idea th

[bess] BESS at IETF91: Call for presentations

Hi everyone, We're pleased to have BESS meet for  the first time, during next IETF in Honolulu (the Wednesday morning). Please send us, *before Monday 27th*, your slot presentation requests indicating draft name, presenter name, and the time needed for the presentation. Note well that with BES