Re: [bess] Lars Eggert's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS)
Hello Lars, Le 2021-10-18 à 13:15, Lars Eggert via Datatracker a écrit : Lars Eggert has entered the following ballot position for draft-ietf-bess-evpn-bum-procedure-updates-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/ -- DISCUSS: -- Entering a DISCUSS to make sure the authors respond to Paul Kyzivat's Gen-ART review (https://mailarchive.ietf.org/arch/msg/gen-art/g5QZK_1U6boqzG8FjuJWhGG74RI), and so that the IESG can discuss that review and (hopefully) any responses to it. Just in case. Paul has sent the exact same review on v09. At that time, the authors have replied and discussed the different points raised. gen-...@ietf.org was copied on these e-mails. The authors have made modifications to the document to tentatively address Paul's comments. -m ___ 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] IPR poll on draft-ietf-bess-l2l3-vpn-mcast-mib-13
Dear BESS, please disregard this e-mail. Thank you -m Le 2018-02-26 à 4:57, Mach Chen a écrit : Dear BESS, This email starts an IPR call on draft-ietf-bess-l2l3-vpn-mcast-mib-13, in preparation to document advancement. Are you aware of any IPR that applies to draft-ietf-bess-l2l3-vpn-mcast-mib-13? If so, has this IPR 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 regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the BESS WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the BESS WG email list but 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. Best regards, Mach Chen (Shepherd of this document) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Request for WG call for draft-sajassi-bess-evpn-vpws-fxc-02.txt
ok, let us know when you've updated it, we'll call it for adoption fater that. -m Le 2018-02-13 à 3:50, Ali Sajassi (sajassi) a écrit : Hi Martin, Stephane: This is one of the draft in my plate that I needed to update and ask for a WG call. It has already been implemented by number of vendors and has had pretty good consensus. Regards, Ali ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Call for adoption: draft-lin-bess-evpn-irb-mcast
All, there is support and all authors have reported back on the list regarding the IPR question so we have a new WG doc. To the authors, could you please republish as draft-ietf-bess-evpn-irb-mcast-00? thank you M&S Le 2018-01-11 à 11:11, Martin Vigoureux a écrit : 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
Re: [bess] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC
Ali, licensing information is optional, as well as specifying which section of the document is affected by the patent(s). regards, Martin Le 2018-01-18 à 2:17, Ali Sajassi (sajassi) a écrit : Hi Martin, I have the following two questions: 1) The disclosed IPR doesn’t have the licensing declaration section filled up. Is this section optional or is it just being overlooked? 2) I found the following url for this IPR: https://www.google.com.pg/patents/US7936693. It would be good for the IPR author to explain how this CPOL is related to this draft – i.e., what section(s) of the draft is covered by this IPR as I couldn’t figure it out by glancing through it. Regards, Ali On 1/16/18, 1:56 PM, "BESS on behalf of Martin Vigoureux" wrote: WG, as you can see, an IPR disclosure was made during the IESG review phase of draft-ietf-bess-evpn-overlay. We'd like to give you the opportunity to reflect on this and let us know if you see any reason not to proceed with the standardisation process. Deadline for voicing opinions is set to the 23rd of January. -m Le 2018-01-16 à 19:51, IETF Secretariat a écrit : > Dear Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx: > > > An IPR disclosure that pertains to your Internet-Draft entitled "A > Network Virtualization Overlay Solution using EVPN" > (draft-ietf-bess-evpn-overlay) was submitted to the IETF Secretariat on and > has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/3131/). The title of the IPR > disclosure is "Eric Rescorla's Statement about IPR related to > draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC" > > > Thank you > > IETF Secretariat > > ___ > 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] IPR Disclosure Eric Rescorla's Statement about IPR related to draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC
WG, as you can see, an IPR disclosure was made during the IESG review phase of draft-ietf-bess-evpn-overlay. We'd like to give you the opportunity to reflect on this and let us know if you see any reason not to proceed with the standardisation process. Deadline for voicing opinions is set to the 23rd of January. -m Le 2018-01-16 à 19:51, IETF Secretariat a écrit : Dear Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx: An IPR disclosure that pertains to your Internet-Draft entitled "A Network Virtualization Overlay Solution using EVPN" (draft-ietf-bess-evpn-overlay) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3131/). The title of the IPR disclosure is "Eric Rescorla's Statement about IPR related to draft-ietf-bess-evpn-overlay belonging to Chemtron Research LLC" Thank you IETF Secretariat ___ 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] Fwd: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane
WG, this dates a bit. Yet, if you have any issue with this situation, please speak up. Thanks -m Message transféré Sujet : [bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane Date : Mon, 20 Nov 2017 08:12:07 -0800 De : IETF Secretariat Pour : draft-ietf-bess-nsh-bgp-control-pl...@ietf.org Copie à : bess@ietf.org, ipr-annou...@ietf.org Dear Adrian Farrel, John Drake, Eric C. Rosen, Jim Uttaro, Luay Jalil: An IPR disclosure that pertains to your Internet-Draft entitled "BGP Control Plane for NSH SFC" (draft-ietf-bess-nsh-bgp-control-plane) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3107/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-bess-nsh-bgp-control-plane" Thank you IETF Secretariat ___ 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] Call for adoption: draft-lin-bess-evpn-irb-mcast
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
Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication
if the intent was to help people better understand the reasoning behind the design, is it really best to remove it? Wouldn't a rephrasing be more appropriate? -m Le 2017-12-15 à 19:21, Ali Sajassi (sajassi) a écrit : Hi Thomas, On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" wrote: Here I would suggest to authors to consider purely removing this paragraph, not because it would be wrong or ambiguous (as said above, I don't think it is), but because as far as I can tell it has never meant to specify anything not already implied by RFC7432, but was here only to help understand. OK, I will remove it in the next rev. Cheers, Ali Best, -Thomas -Original Message- > From: John E Drake [mailto:jdr...@juniper.net] > Sent: Friday, December 15, 2017 9:52 AM > To: EXT - thomas.mo...@orange.com ; Fedyk, > Don ; Marco Marzetti > Cc: bess@ietf.org > Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress > Replication > > Thomas, > > I completely agree w/ your email, below. > > Yours Irrespectively, > > John > > > > -Original Message- > > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin > > Sent: Friday, December 15, 2017 5:42 AM > > To: Fedyk, Don ; Marco Marzetti > it> > > Cc: bess@ietf.org > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with > > Ingress > > Replication > > > > Hi Don, > > > > Fedyk, Don, 2017-12-14 20:33: > > > I think the gray area is that this draft talks about BUM traffic > > > and > > > ingress replication and then has a section on Multicast tunnels > > > which excludes ingress replication traffic from the tunnels. > > > > No, ingress replication is not excluded at all: > > > >The following tunnel types as defined in [RFC6514] can be used > > in > >the PMSI tunnel attribute for VXLAN/NVGRE: > > > > + 3 - PIM-SSM Tree > > + 4 - PIM-SM Tree > > + 5 - BIDIR-PIM Tree > > + 6 - Ingress Replication > > > > > If you are using point to point VXLAN/NVGRE tunnels then > > > ingress > > > replication is default [...] > > > > This formulation surprises me: that some implementations behave as > > you > > describe is possibly true (this seems to be the case of the > > implementation that triggered this discussion), but I don't know > > about > > any text in the specs we are discussing that would imply such a > > 'default'. > > > > You might have implementations that in the absence of any local > > configuration for an EVPN instance on which type of tunnel to use > > for > > BUM, will default to ingress replication: this is fine, out of the > > scope of what is specified for interop, and not breaking other > > implementations (as long, of course, that what is chosen locally > > is > > then advertised as expected in a PMSI Tunnel Attribute). > > > > > > > but IMET is being used to identify the NVE IP.I read RFC7432 > > > and > > > RFC6514 in this area and thought that the PMSI attribute MUST be > > > set > > > when there is an Inclusive Multicast Ethernet tag IMET. > > > > Yes! (the text of RFC7432 quoted by Ali reminds us that) > > > > > > > I can see two possible fixes: > > > - Specify that the PMSI attribute MUST be set if there > > > is an > > > IMET route and specify correct attribute. > > > > Given the content of RFC7432 and the fact that this is a normative > > ref > > of draft-ietf-bess-evpn-overlay, I think that we don't need to > > repeat > > this MUST in draft-ietf-bess-evpn-overlay. That is, unless we > > explicitly identify an ambiguous piece of text. > > > > > - Allow that ingress replication is default when PMSI is > > > absent but accept PMSI that specifies ingress replication. > > > > > > > I don't think we should do that. It would overnight make non- > > compliant > > pre- standard implementation of draft-ietf-bess-evpn-overlay, > > without > > a rationale to do so except coping with an implementation that > > assumed a bit too much. > > > > Best, > > > > -Thomas > > > > > > > > > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Marco > > > Marzetti > > > Sent: Thursday, December 14, 2017 9:21 AM > > > To: Thomas Morin > > > Cc: bess@ietf.org > > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with > > > Ingress Replication > > > > > > Hello, > > > > > > I have encountered an
Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-12
Glenn, Tsuno, many many thanks for bringing this to conclusion! Mach, can you check the shepherd write-up and let me know when we are good to go. Thanks -m Le 2017-12-14 à 14:15, Glenn Mansfield Keeni a écrit : Dear Tsuno, Thank you for the good work. All the issues are addressed. I have no further issues with this MIB. I believe the MIB review is complete. Thanks again for the cooperation during this long review period,. Glenn On 2017/12/12 19:23, Hiroshi Tsunoda wrote: Dear Glenn, I have fixed some nits and submitted as new revision. Links to the draft and diff are as follows. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-13.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-13 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-13 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-13 Thanks in advance, -- tsuno 2017-11-28 0:09 GMT+01:00 Hiroshi Tsunoda : Dear Glenn, May I ask you to give one more review for draft-ietf-bess-l2l3-vpn-mcast-mib matter? I posted a new revision (-12). In this revision, I have made the following changes in order to make the MIB simpler and be less dependent on BGP. - Added l2L3VpnMCastPmsiTunnelLeafInfoRequired object. This object corresponds to "Leaf Information Required" flag in Flags field. - Removed two objects shown below - l2L3VpnMcastPmsiTunnelAttributeFlags - l2L3VpnMcastPmsiTunnelAttributeAddlFlags - Fixed some editorial issues. Links to the draft and diff are as follows. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-12.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-12 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-12 Thanks in advance, -- tsuno ___ 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] AD Review of draft-ietf-bess-evpn-overlay-08
Alvaro, the docs are draft-boutros-bess-evpn-geneve-00 draft-rabadan-nvo3-evpn-applicability-00 -m Le 05/12/2017 à 23:08, Alvaro Retana a écrit : On December 5, 2017 at 9:25:39 AM, thomas.mo...@orange.com <mailto:thomas.mo...@orange.com> (thomas.mo...@orange.com <mailto:thomas.mo...@orange.com>) wrote: 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 fairly recent. I have indicated in the BESS report that we'll likely be working closeer with NVO3 from now on. An individual draft on the applicability of EVPN to NVO3 networks is targeting NVO3 WG. Conversely, an individual draft on EVPN extensions for Geneve is targeting BESS. We have agreed that we'll do cross reviews at the important milestones of these docs. Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve work for EVPN; something like: "Adapting the EVPN control plane to the Geneve encapsulation is out of the scope of this document, and is expected to be covered in a separate document based on the same architectural principles" Perfect, thanks! Is that draft already in the works, or just planned? Alvaro. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
Hello Alvaro, thanks for your review. Please see in-line regarding the two first points. -m Le 04/12/2017 à 22:49, Alvaro Retana a écrit : Dear Authors: I just finished reading this document (finally!). I have a some comments (see below) which I think should be easy to address. I also have some bigger issues that we’ll need the Chairs’ help to solve: (1) Coordination with nv03 For the Chairs: Except for some clarification comments [1] related to the current version, I see no other traffic in the nvo3 list related to this document. Was there some other coordination that I’m missing? I am not questioning having this document in bess (that’s perfectly fine); I’m just raising the needed coordination with other WGs, from the Charter: "The working group will also coordinate with...NVO3 working group for coordination of protocols to support data center VPNs.” 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 fairly recent. I have indicated in the BESS report that we'll likely be working closeer with NVO3 from now on. An individual draft on the applicability of EVPN to NVO3 networks is targeting NVO3 WG. Conversely, an individual draft on EVPN extensions for Geneve is targeting BESS. We have agreed that we'll do cross reviews at the important milestones of these docs. (2) Document Status Why is this a Standards Track document? The Abstract/Introduction say that “this document describes how Ethernet VPN (EVPN) can be used as an NVO solution and explores applicability of EVPN functions and procedures.” -- if it’s just a description (as the text clearly is), and not a technical specification, then why it is not Informational? I can see how we could call it an Applicability Statement (rfc2026) and still publish it in the Standards Track. If we want to go that way, we would need some minor updates to make it clear that this is an Applicability Statement and is not intended to stand in for a Technical Specification. I am not clear on the process as it related to possible DownRefs (see below), but I’m willing to Last Call an Applicability Statement in the Standards Track…if that is what you want. Maybe the authors should s/describes/specifies/ to better reflect the content of the document. On the other hand, rfc2026 says "A Technical Specification is any description of a protocol, service, procedure, convention, or format." It seems to match as well. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0 Major: M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to illustrate how the RT can be auto-derived. Without any context, the description doesn’t make much sense: the fields are not described in order, the reader is expected to know about global and local administrative fields, the “A-bit” (or the Type field) are not mentioned in the description, people could probably guess that “D-ID” means “domain-id”, there’s no indication of what to do with that “packet format”, etc. Please clean the description up, include clearer explanations and some references can’t hurt. M1.2. What about 4-byte ASNs? M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be advertised with multiple encapsulation types as long as they use the same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”. Is Split Horizon an example, or the only multi-homing procedure that should be considered? Please be clear. M3. From 5.2 (MPLS over GRE): M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD be present, and SHOULD be used to provide a 32-bit entropy field.” What are the cases when it is ok not to include the field, or use it for that purpose? IOW, why are these SHOULDs not MUSTs? Or maybe, when is the key field needed? M3.2. "The Checksum and Sequence Number fields are not needed and their corresponding C and S bits MUST be set to zero.” This is different than what rfc4023 specifies (not a problem). If you’re specifying the setting of the bits, then you should be more prescriptive with whether the fields are included of not; suggestion: "The Checksum and Sequence Number fields MUST NOT be included and the corresponding C and S bits in the GRE Packet Header MUST be set to zero.” M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulation) M4.1. These 2 MUSTs seem out of place as they are used to explain, and not in a Normative way: “ ..the RD must be a unique value per EVI or per NVE as described in [RFC7432]. In other words, whenever there is more than one administrative domain for global VNI, then a unique RD MUST be used, or whenever the VNI value have local significance, then a unique RD MUST be used.” s/MUST/must M4.2. This SHOULD is also out of place because
Re: [bess] New bess Co-Chair
Thomas, we really had great times together! Thanks for that. Thanks for your dedication and I wish you all the best. Stéphane, welcome! -m Le 01/12/2017 à 17:48, thomas.mo...@orange.com a écrit : 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 Alvaro. It has been an honor and a pleasure for me to co-chair l3vpn & bess, trying to accompany the working group contributions and maybe contribute a bit to driving it into useful directions. The great experience of co-chairing with Martin was unarguably a plus in this journey. In consultation with Martin and the other ADs, we have asked Stephane Litkowski to take on the role of bess Co-Chair. [...] Welcome Stephane! Welcome Stephane! :) Be aware that co-chairing bess comes with the risk of being possibly misrepresented [1]. And to all, many thanks for being great BESS contributors ; don't celebrate too fast though: I'll still possibly be around lurking for that little-thing-in-this-obscure-extended-community or the other thing on which there can be something to nitpick about ! ;) Bess regards, -Thomas [1] https://twitter.com/LlanOldDog/status/643796807852630016 _ 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
[bess] Publication has been requested for draft-ietf-bess-evpn-prefix-advertisement-09
Martin Vigoureux has requested publication of draft-ietf-bess-evpn-prefix-advertisement-09 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-evpn-prefix-advertisement/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] BESS agenda available - Please send presentation material
Oups. Thanks Robert. Le 06/11/2017 à 13:36, Robert Raszuk a écrit : Hey Martin, I think your link is a bit outdated ... Instead it may be easier to follow this one: https://datatracker.ietf.org/meeting/100/materials/agenda-100-bess/ Thx, Robert. On Mon, Nov 6, 2017 at 12:50 PM, Martin Vigoureux mailto:martin.vigour...@nokia.com>> wrote: Presenters, WG, we have posted the agenda for BESS in Singapore. Please have a look at it: https://datatracker.ietf.org/meeting/100/agenda/bess/ <https://datatracker.ietf.org/meeting/100/agenda/bess/> Please start sending your presentation material now. Deadline is Sunday 12th of November, 23:59 local time. Please design your presentation in order to respect the time which was allocated to it. Thank you M&T ___ BESS mailing list BESS@ietf.org <mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess> ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] BESS agenda available - Please send presentation material
Presenters, WG, we have posted the agenda for BESS in Singapore. Please have a look at it: https://datatracker.ietf.org/meeting/100/agenda/bess/ Please start sending your presentation material now. Deadline is Sunday 12th of November, 23:59 local time. Please design your presentation in order to respect the time which was allocated to it. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway
WG, we have a new WG Document. Authors could you republish as draft-ietf-bess-datacenter-gateway-00 thank you Le 25/09/2017 à 11:42, Martin Vigoureux a écrit : Hello working group, This email starts a two-week call for adoption on draft-drake-bess-datacenter-gateway-05 [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 2nd of October*. 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 & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ ___ 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] Slots requests for BESS WG session - IETF 100 - Singapore
All, it is time we start building the BESS WG agenda for Singapore. The IETF agenda (still preliminary) is available at: https://datatracker.ietf.org/meeting/100/agenda.html The BESS WG session (2h) is scheduled on Friday, November 17th, 2017 / Morning session I / 09:30-11:30 (local time) Please send us your request for a presentation slot, indicating draft name, speaker, and desired duration (covering presentation and discussion). Please send the requests no later than the 30th of October. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Call for adoption: draft-snr-bess-evpn-na-flags
Authors, WG, this document is adopted. Please republish as draft-ietf-bess-evpn-na-flags-00 -m Le 12/09/2017 à 09:35, Martin Vigoureux a écrit : Hello working group, This email starts a two-week call for adoption on draft-snr-bess-evpn-na-flags-07 [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 26th of September*. 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 & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-na-flags/ ___ 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-drake-bess-datacenter-gateway
I meant the 9th of October, sorry. Le 25/09/2017 à 11:42, Martin Vigoureux a écrit : Hello working group, This email starts a two-week call for adoption on draft-drake-bess-datacenter-gateway-05 [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 2nd of October*. 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 & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ ___ 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] Call for adoption: draft-drake-bess-datacenter-gateway
Hello working group, This email starts a two-week call for adoption on draft-drake-bess-datacenter-gateway-05 [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 2nd of October*. 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 & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Call for adoption: draft-snr-bess-evpn-na-flags
Hello working group, This email starts a two-week call for adoption on draft-snr-bess-evpn-na-flags-07 [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 26th of September*. 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 & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-na-flags/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Fwd: New Liaison Statement, "Review and Comment on TR-350 Issue 2 - Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN) – ELINE and ETREE"
Hello, I am not sure if this reached the list. In any case, please be aware of this liaison statement, also available here https://datatracker.ietf.org/liaison/1540/ Action is needed for this liaison statement. -m Message transféré Sujet : New Liaison Statement, "Review and Comment on TR-350 Issue 2 - Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN) – ELINE and ETREE" Date : Tue, 08 Aug 2017 10:31:30 -0700 De : Liaison Statement Management Tool Pour : Alvaro Retana , Deborah Brungard , George Swallow , Alia Atlas , Martin Vigoureux , Loa Andersson , Thomas Morin , Nicolai Leymann Copie à : Alvaro Retana , Deborah Brungard , Multiprotocol Label Switching Discussion List , David Sinicrope , david.sinicr...@ericsson.com, Alia Atlas , BGP Enabled ServiceS Discussion List , Martin Vigoureux , The IETF Chair , George Swallow , Loa Andersson , Thomas Morin , rme...@broadband-forum.org, Nicolai Leymann Title: Review and Comment on TR-350 Issue 2 - Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN) – ELINE and ETREE Submission Date: 2017-08-08 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1540/ Please reply by 2017-09-06 From: Michael Fargano To: Martin Vigoureux , Thomas Morin ,Nicolai Leymann ,Loa Andersson ,George Swallow ,Alia Atlas ,Alvaro Retana ,Deborah Brungard Cc: Alvaro Retana ,Deborah Brungard ,Multiprotocol Label Switching Discussion List ,David Sinicrope ,Alia Atlas ,BGP Enabled ServiceS Discussion List ,Martin Vigoureux ,The IETF Chair ,George Swallow ,Loa Andersson ,Thomas Morin ,Nicolai Leymann ,rme...@broadband-forum.org Response Contacts: david.sinicr...@ericsson.com Technical Contacts: Purpose: For comment Body: Dear Colleagues, In November 2015, the BBF published TR-350 - Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN) which covered architecture and equipment requirements for implementation of ELAN service types using the EVPN technology. Also in November 2015, the BBF started working the second phase of the TR-350 work adding ELINE and ETREE service types to this important specification. The work has progress through 2016 and early 2017 and has entered the beginning of the Broadband Forum approval process. During this phase we would greatly appreciate your review and comments. To consider your comments during our 3Q2017 meeting we would need to receive them by 6 September 2017. Comments received after 6 September will be considered during our 4Q2017 meeting in December 2017. We look forward to working with you and we would like to thank you for your timely consideration and response. Sincerely, Michael Fargano, Broadband Forum Technical Committee Chair CC: Robin Mersh, Broadband Forum CEO Attachments: WT-350i2SBLiaison.approved https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-08-08-broadband-forum-mpls-rtg-bess-review-and-comment-on-tr-350-issue-2-ethernet-services-using-bgp-mpls-based-ethernet-vpns-evpn-eline-and-etre-attachment-1.pdf WT-350i2ELineETree.SBText-Sinicrope-RnTAD https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-08-08-broadband-forum-mpls-rtg-bess-review-and-comment-on-tr-350-issue-2-ethernet-services-using-bgp-mpls-based-ethernet-vpns-evpn-eline-and-etre-attachment-2.pdf ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call for draft-ietf-bess-fat-pw-bgp
WG, I have received all IPR feedbacks. No author knows about any undisclosed IPR. We have one report of an implementation. There is clear support to move forward. No technical comment was expressed So we are good to go to the next step. thanks -m Le 12/06/2017 à 18:27, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-fat-pw-bgp-02 [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 *26th 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 Proposed Standard RFC. ¤ *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-fat-pw-bgp, 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-fat-pw-bgp-02 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/ [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] BESS agenda available - Please send presentation material
Presenters, WG, we have posted the agenda for BESS in Prague. Please have a look at it: https://datatracker.ietf.org/meeting/99/agenda/bess/ Please start sending you presentation material now. Strict deadline is Wednesday 19th of July, 23:59 local time. Anything received after that will translate in a move of your slot at the end of the session. We have a full agenda. Please be reasonable regarding the number of slides you plan on presenting and thus be respectful of the others. We'll have quite a strict time management. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] BESS - IETF99 - Agenda requests
80% of the requests are for 00, including your 3 Ali :-) -m Le 04/07/2017 à 00:34, Ali Sajassi (sajassi) a écrit : I presume based on actions taken before in such situations, new works will be given preference over older drafts. Regards, Ali On 7/3/17, 3:24 PM, "Martin Vigoureux" wrote: Ali, yes, there have been. Le 04/07/2017 à 00:16, Ali Sajassi (sajassi) a écrit : Hi Martin, Are there any requests that haven¹t been asked publicly? There are about 9 requests posted on the mailing list plus another one from Jorge which brings the total to 10. Regards, Ali On 7/3/17, 2:22 PM, "BESS on behalf of Martin Vigoureux" wrote: WG, we've had (much) more requests than we can accommodate for. Many of them came in the last two days. Please give us a bit of time to prioritize and publish an agenda. Not every slot request will be granted. -m ___ 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] BESS - IETF99 - Agenda requests
Ali, yes, there have been. Le 04/07/2017 à 00:16, Ali Sajassi (sajassi) a écrit : Hi Martin, Are there any requests that haven¹t been asked publicly? There are about 9 requests posted on the mailing list plus another one from Jorge which brings the total to 10. Regards, Ali On 7/3/17, 2:22 PM, "BESS on behalf of Martin Vigoureux" wrote: WG, we've had (much) more requests than we can accommodate for. Many of them came in the last two days. Please give us a bit of time to prioritize and publish an agenda. Not every slot request will be granted. -m ___ 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] BESS - IETF99 - Agenda requests
WG, we've had (much) more requests than we can accommodate for. Many of them came in the last two days. Please give us a bit of time to prioritize and publish an agenda. Not every slot request will be granted. -m ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Slots requests for BESS WG session - IETF 99 - Prague
Sami, could you please specify the duration, as requested. Thanks -m Le 28/06/2017 à 00:03, Sami Boutros a écrit : Hi Martin, Need a slot for me to present. EVPN control plane for Geneve draft-boutros-bess-evpn-geneve-00.txt Thanks, Sami On Jun 21, 2017, at 1:33 AM, Martin Vigoureux mailto:martin.vigour...@nokia.com>> wrote: All, it is time we start building the BESS WG agenda for Prague. The IETF agenda (still preliminary) is available at: https://datatracker.ietf.org/meeting/99/agenda.html The BESS WG session (2h) is scheduled on Thursday, July 20, 2017 / Afternoon session II / 15:50-17:50 (local time) Please send us your request for a presentation slot, indicating draft name, speaker, and desired duration (covering presentation and discussion). Please send the requests no later than the 5th of July. Thank you M&T ___ 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 <mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Slots requests for BESS WG session - IETF 99 - Prague
All, it is time we start building the BESS WG agenda for Prague. The IETF agenda (still preliminary) is available at: https://datatracker.ietf.org/meeting/99/agenda.html The BESS WG session (2h) is scheduled on Thursday, July 20, 2017 / Afternoon session II / 15:50-17:50 (local time) Please send us your request for a presentation slot, indicating draft name, speaker, and desired duration (covering presentation and discussion). Please send the requests no later than the 5th of July. Thank you M&T ___ 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
WG, the WG LC has ended and we have support to move forward. I'll shepherd the document. -m Le 06/06/2017 à 16:11, Martin Vigoureux a écrit : 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&T [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
Re: [bess] WG feedback on early allocation requests for new EVPN Route types
WG, we haven't receive any feedback. I'll proceed with asking for the code points allocation. -m Le 01/06/2017 à 12:29, Martin Vigoureux a écrit : Dear WG, we have received an early allocation request (see details below) from the authors of draft-ietf-bess-evpn-igmp-mld-proxy. Please let us know if you are aware of any code-point conflict, or if you have issues with the WG moving forward with this early allocation. We envisage to proceed with the request on the 16th of June. Thank you M&T --- "EVPN Route Types" from registry defined by RFC7432 https://www.iana.org/assignments/evpn/evpn.xhtml 6 - Selective Multicast Ethernet Tag Route 7 - IGMP Join Synch Route 8 - IGMP Leave Synch 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 Last Call for draft-ietf-bess-evpn-usage
WG, Authors/Contributors, this is a reminder. Thank you -m Le 06/06/2017 à 16:11, Martin Vigoureux a écrit : 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&T [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] WG Last Call for draft-ietf-bess-fat-pw-bgp
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-fat-pw-bgp-02 [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 *26th 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 Proposed Standard RFC. ¤ *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-fat-pw-bgp, 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-fat-pw-bgp-02 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-fat-pw-bgp/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WG Last Call for draft-ietf-bess-evpn-usage
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&T [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] WG feedback on early allocation requests for new EVPN Route types
Dear WG, we have received an early allocation request (see details below) from the authors of draft-ietf-bess-evpn-igmp-mld-proxy. Please let us know if you are aware of any code-point conflict, or if you have issues with the WG moving forward with this early allocation. We envisage to proceed with the request on the 16th of June. Thank you M&T --- "EVPN Route Types" from registry defined by RFC7432 https://www.iana.org/assignments/evpn/evpn.xhtml 6 - Selective Multicast Ethernet Tag Route 7 - IGMP Join Synch Route 8 - IGMP Leave Synch Route --- ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure
WG, there is a clear renewed support for this document, so we'll continue as normal. Thank you. M&T Le 13/04/2017 à 20:04, Martin Vigoureux a écrit : WG Given the IPR disclosed [1] against draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for comment specifically to let people express a revised opinion on how draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. This call for comment is open until the 5th of May Thanks M&T [1] https://datatracker.ietf.org/ipr/2980/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Extra time to reflect on draft-mackie-bess-nsh-bgp-control-plane adoption following the IPR disclosure
WG Given the IPR disclosed [1] against draft-mackie-bess-nsh-bgp-control-plane, we are starting a call for comment specifically to let people express a revised opinion on how draft-ietf-bess-nsh-bgp-control-plane should be pursued in BESS. This call for comment is open until the 5th of May Thanks M&T [1] https://datatracker.ietf.org/ipr/2980/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane
All, we have good support for the adoption of this document and all Authors and Contributors have stated that they are not aware of any undisclosed IPR which relates to this draft so we have a new WG Document. Authors, could you please republish as draft-ietf-bess-nsh-bgp-control-plane-00? Thank you M&T Le 06/03/2017 à 12:55, Martin Vigoureux a écrit : Hello working group, This email starts a two-week call for adoption on draft-mackie-bess-nsh-bgp-control-plane-04 [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 19th of March*. 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. IPR has been disclosed against this Document [2]. 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-mackie-bess-nsh-bgp-control-plane/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane ___ 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] BESS agenda available - Please send presentation material - Beware of deadline
Presenters, WG, we have posted the agenda for BESS in Chicago. Please have a look at it: https://www.ietf.org/proceedings/98/agenda/agenda-98-bess-00 Please note that BESS in on Monday at 9 am. We are thus setting a *very strict deadline Sunday 11:59 pm local time* for receiving the presentation materials. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
Authors, there has been a number of comments on this draft during WG LC. Please make sure you give an answer regarding each, and then update the draft if needed. Thank you M&T Le 13/02/2017 à 23:07, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered mature and ready for a final working group review. Note that this call is longer than usual because we are pushing two correlated documents together. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *5th of March*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-evpn-prefix-advertisement, 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-prefix-advertisement-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. 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ [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
Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
Authors, there has been a number of comments on this draft during WG LC. Please make sure you give an answer regarding each, and then update the draft if needed. Thank you M&T Le 13/02/2017 à 23:07, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered mature and ready for a final working group review. Note that this call is longer than usual because we are pushing two correlated documents together. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *5th of March*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-evpn-inter-subnet-forwarding, 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-inter-subnet-forwarding-03 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ [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
Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04
All, we now have all the IPR related answers. We are good to go. I'll shepherd the document. -m Le 24/02/2017 à 10:28, Martin Vigoureux a écrit : All, there is good support for this document, but we are missing few answers to the IPR question. As soon as they come in we'll move towards publication. Thanks -m Le 06/02/2017 à 14:07, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than *19th of February*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and indicate whether or not you are aware of any relevant IPR. Note that IPR exists and has been disclosed against this document [2]. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-dci-evpn-overlay ___ 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
[bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane
Hello working group, This email starts a two-week call for adoption on draft-mackie-bess-nsh-bgp-control-plane-04 [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 19th of March*. 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. IPR has been disclosed against this Document [2]. 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-mackie-bess-nsh-bgp-control-plane/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Slots requests for BESS WG session - IETF 98 - Chicago
All, it is time we start building the BESS WG agenda for Chicago. The IETF agenda is available at: https://datatracker.ietf.org/meeting/98/agenda.html The BESS WG session (2h) is scheduled on Monday, March 27, 2017 / Morning session I / 9:00-11:30 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation and discussion) Please send the requests no later than the 14th of March. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04
All, there is good support for this document, but we are missing few answers to the IPR question. As soon as they come in we'll move towards publication. Thanks -m Le 06/02/2017 à 14:07, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than *19th of February*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and indicate whether or not you are aware of any relevant IPR. Note that IPR exists and has been disclosed against this document [2]. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-dci-evpn-overlay ___ 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] Fwd: [IANA #949204] Early allocation request (draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-bum-procedure-updates)
fyi Message transféré Sujet : [IANA #949204] Early allocation request (draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-bum-procedure-updates) Date de renvoi : Fri, 17 Feb 2017 16:43:04 -0800 De (renvoi) : alias-boun...@ietf.org Pour (renvoi) : thomas.mo...@orange.com, martin.vigour...@nokia.com Date : Sat, 18 Feb 2017 00:43:01 + De : Sabrina Tanamal via RT Répondre à : iana-prot-pa...@iana.org Copie à : bess-cha...@ietf.org, draft-ietf-bess-evpn-bum-procedure-upda...@ietf.org, draft-ietf-bess-evpn-prefix-advertisem...@ietf.org, bess-...@ietf.org Hello, My apologies for forgetting to include the dates below. 5 IP Prefix route (TEMPORARY - registered 2017-02-17, expires 2018-02-17) [draft-ietf-bess-evpn-prefix-advertisement] 9 Per-Region I-PMSI A-D route (TEMPORARY - registered 2017-02-17, expires 2018-02-17) [draft-ietf-bess-evpn-bum-procedure-updates] 10 S-PMSI A-D route (TEMPORARY - registered 2017-02-17, expires 2018-02-17) [draft-ietf-bess-evpn-bum-procedure-updates] 11 Leaf A-D route (TEMPORARY - registered 2017-02-17, expires 2018-02-17) [draft-ietf-bess-evpn-bum-procedure-updates] Please see https://www.iana.org/assignments/evpn Best regards, Sabrina Tanamal IANA Services Specialist PTI On Fri Feb 17 20:37:11 2017, sabrina.tanamal wrote: Hello, We've made the following early allocations in the EVPN Route Types registry: 5 IP Prefix route [draft-ietf-bess-evpn-prefix-advertisement] 9 Per-Region I-PMSI A-D route [draft-ietf-bess-evpn-bum- procedure-updates] 10 S-PMSI A-D route[draft-ietf-bess-evpn-bum-procedure- updates] 11 Leaf A-D route [draft-ietf-bess-evpn-bum-procedure-updates] Please see https://www.iana.org/assignments/evpn Best regards, Sabrina Tanamal IANA Services Specialist PTI On Tue Feb 14 17:16:55 2017, martin.vigour...@nokia.com wrote: > Hello, > > in the framework of RFC 7120, we, as BESS chairs, are kindly > requesting > an early allocation of the code points below. > > The code points are defined in two documents: > draft-ietf-bess-evpn-prefix-advertisement [1] > and > draft-ietf-bess-evpn-bum-procedure-updates [2] > > There are known implementations using the code points for their > defined > use. WG has been polled for knowledge of conflict and none was > reported. > AD approves the request. > > Within the "EVPN Route Types" registry, defined by RFC7432, > https://www.iana.org/assignments/evpn/evpn.xhtml > could you please allocate the following: > > 5 | IP Prefix route | [draft-ietf-bess-evpn-prefix-advertisement] > 9 | Per-Region I-PMSI A-D route | > [draft-ietf-bess-evpn-bum-procedure-updates] > 10 | S-PMSI A-D route | [draft-ietf-bess-evpn-bum-procedure-updates] > 11 | Leaf A-D route | [draft-ietf-bess-evpn-bum-procedure-updates] > > Please note that the 6 to 8 gap is on purpose. A 3rd document > currently > polled for adoption by the BESS WG makes use of these code points; > code > points for which we will most likely request an early allocation if > and > when it gets adopted. > > Thank you > > Best regards, > Martin & Thomas > BESS Chairs > > [1] > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix- > advertisement/ > [2] > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure- > updates/ > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered mature and ready for a final working group review. Note that this call is longer than usual because we are pushing two correlated documents together. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *5th of March*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-evpn-inter-subnet-forwarding, 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-inter-subnet-forwarding-03 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered mature and ready for a final working group review. Note that this call is longer than usual because we are pushing two correlated documents together. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *5th of March*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-evpn-prefix-advertisement, 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-prefix-advertisement-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. 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, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG feedback on early allocation requests for new EVPN Route types
WG, we haven't heard any opposition to proceeding with this early allocation. We will thus move forward. -m Le 31/01/2017 à 11:55, Martin Vigoureux a écrit : Dear WG, we have received early allocation requests from the authors of draft-ietf-bess-evpn-prefix-advertisement and draft-ietf-bess-evpn-bum-procedure-updates: (see details below). Please let us know if you are aware of any code-point conflict, or if you have issues with the WG moving forward with this early allocation. We envisage to proceed with the request on the 6th of February. Thank you M&T --- "EVPN Route Types" from registry defined by RFC7432 https://www.iana.org/assignments/evpn/evpn.xhtml 5 - IP Prefix route 9 - Per-Region I-PMSI A-D route 10 - S-PMSI A-D route 11 - Leaf A-D 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 Last Call for draft-ietf-bess-dci-evpn-overlay-04
WG, major omission in my previous e-mail: ¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. Please inform the mailing list, or the chairs, or only one of the chairs. [3] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw -m Le 06/02/2017 à 14:07, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than *19th of February*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and indicate whether or not you are aware of any relevant IPR. Note that IPR exists and has been disclosed against this document [2]. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-dci-evpn-overlay ___ 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] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-dci-evpn-overlay-04 [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, and send your comments to the list, no later than *19th of February*. 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 Proposed Standard RFC. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-dci-evpn-overlay, 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-dci-evpn-overlay-04 please respond to this email and indicate whether or not you are aware of any relevant IPR. Note that IPR exists and has been disclosed against this document [2]. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-dci-evpn-overlay ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WG feedback on early allocation requests for new EVPN Route types
Dear WG, we have received early allocation requests from the authors of draft-ietf-bess-evpn-prefix-advertisement and draft-ietf-bess-evpn-bum-procedure-updates: (see details below). Please let us know if you are aware of any code-point conflict, or if you have issues with the WG moving forward with this early allocation. We envisage to proceed with the request on the 6th of February. Thank you M&T --- "EVPN Route Types" from registry defined by RFC7432 https://www.iana.org/assignments/evpn/evpn.xhtml 5 - IP Prefix route 9 - Per-Region I-PMSI A-D route 10 - S-PMSI A-D route 11 - Leaf A-D route --- ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] EVPN-VPWS Service Edge Gateway rev03
sent to list as admin. message had bounced. --- Begin Message --- Hi Jorge, Sorry for the delay, I will be addressing the comments below in the next rev, and will be clarifying the DF election too. The DF election between the service edge nodes will follow RFC 7432 using the per ES Ethernet AD route, however will use the HRW algorithm. The election will be performed to decide on who will be the primary responding to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the access nodes by applying the HRW algorithm. I will clarify the text to reflect the above. Thanks, Sami > On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) > wrote: > > Sami, > > I looked at your Service Edge Gateway draft, and since my comments/questions > were not addressed in rev 03, I’m resending our last exchange. > Besides the comments below (please see the thread from earlier this year), > the most confusing part to me is still the multi-homing on the Service Edge > nodes. After reading the text, still not sure if the intend is a DF election > based out of the AD per-EVI routes or if the DF election follows regular > RFC7432 procedures. This is a blurry area in the draft and I would personally > appreciate a clarification. > > Thank you. > Jorge > > > > On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" > wrote: > > Hi Sami, > > As discussed, this is the email. The new comments are tagged as [JORGE2]. > Please see in-line. > Thanks. > Jorge > > > > -- > From: Sami Boutros > Date: Tuesday, October 20, 2015 at 5:39 AM > To: Jorge Rabadan > Cc: "bess@ietf.org" > Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway > > > Hi Jorge, > > > > -- > > > Abstract > >This document describes how a service node can dynamically terminate >EVPN virtual private wire transport service (VPWS) from access nodes >and offer Layer 2, Layer 3 and Ethernet VPN overlay services to >Customer edge devices connected to the access nodes. Service nodes >using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN >overlay services it can offer for the terminated EVPN VPWS transport >service. On an access node an operator can specify the L2 or L3 or >Ethernet VPN overlay service needed by the customer edge device >connected to the access node that will be transported over the EVPN- >VPWS service between access node and service node. > > /* [JORGE] it would be good to clearly state the benefit of doing this. > The main advantages that I see are service extension with single-side > provisioning (no need to provision new ACs at the service node). */ > > > > > Sami: will update the abstract. > [JORGE2] I don’t see anything changed in rev 02 ;-) > > > > > > 1 Introduction > > > /* [JORGE] maybe this level of detail at the introduction is a bit > confusing. I think it would be better to state what the goal and > advantages are in the introduction and leave the details for the solution > description. */ > > Sami: will update. > [JORGE2] I don’t see anything changed in rev 02 ;-) > > > ... > 2.2 Scalability > >(R2a) A single service node PE can be associated with many access >node PEs. The following requirements give a quantitative measure. > >(R2b) A service node PE MUST support thousand(s) head-end connections >for a a given access node PE connecting to different overlay VRF >services on that service node. > >(R2c) A service node PE MUST support thousand(s) head-end connections >to many access node PEs. > > > /* [JORGE] It is hard to understand... should the following be better?: > > “ (R2b) A service node PE MUST support head-end functionality for > thousands of access node PEs that are connected to different VRFs on the > service node. > (R2c) A service node PE MUST support thousands of CE > connections through the attached access nodes." > */ > > > Sami: will update. > [JORGE2] I don’t see anything changed in rev 02 ;-) > > > 2.5 Multi-homing > >TBD > > /* [JORGE] The solution should describe how to handle multi-homing at two > levels: > - Access node multi-homed to 2 or more Service nodes > - CE node multi-homed to 2 or more access nodes (this one should be > aligned with the EVPN-VPWS draft) > */ > > Sami: Please have a look at the updated section in 01, as for the CE node > agreed that it should be aligned with EVPN-VPWS, and hence no need to mention > anything about it in the draft. > > [JORGE2] OK, please see below. > > > > > > 4 Solution Overview > > >+-+ +-+ >| | | | > ++ +-+ | IP/MPLS | +-+ | IP/MPLS | > | CE |---| PE1 |-| Access |-| PE2 |-| Core| > ++ +-+ | Network | +-+ | Network | >
[bess] EVPN-VPWS Service Edge Gateway rev03
sent to list as admin. message had bounced. --- Begin Message --- Sami, I looked at your Service Edge Gateway draft, and since my comments/questions were not addressed in rev 03, I’m resending our last exchange. Besides the comments below (please see the thread from earlier this year), the most confusing part to me is still the multi-homing on the Service Edge nodes. After reading the text, still not sure if the intend is a DF election based out of the AD per-EVI routes or if the DF election follows regular RFC7432 procedures. This is a blurry area in the draft and I would personally appreciate a clarification. Thank you. Jorge On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" wrote: Hi Sami, As discussed, this is the email. The new comments are tagged as [JORGE2]. Please see in-line. Thanks. Jorge -- From: Sami Boutros Date: Tuesday, October 20, 2015 at 5:39 AM To: Jorge Rabadan Cc: "bess@ietf.org" Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway Hi Jorge, -- Abstract This document describes how a service node can dynamically terminate EVPN virtual private wire transport service (VPWS) from access nodes and offer Layer 2, Layer 3 and Ethernet VPN overlay services to Customer edge devices connected to the access nodes. Service nodes using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN overlay services it can offer for the terminated EVPN VPWS transport service. On an access node an operator can specify the L2 or L3 or Ethernet VPN overlay service needed by the customer edge device connected to the access node that will be transported over the EVPN- VPWS service between access node and service node. /* [JORGE] it would be good to clearly state the benefit of doing this. The main advantages that I see are service extension with single-side provisioning (no need to provision new ACs at the service node). */ Sami: will update the abstract. [JORGE2] I don’t see anything changed in rev 02 ;-) 1 Introduction /* [JORGE] maybe this level of detail at the introduction is a bit confusing. I think it would be better to state what the goal and advantages are in the introduction and leave the details for the solution description. */ Sami: will update. [JORGE2] I don’t see anything changed in rev 02 ;-) ... 2.2 Scalability (R2a) A single service node PE can be associated with many access node PEs. The following requirements give a quantitative measure. (R2b) A service node PE MUST support thousand(s) head-end connections for a a given access node PE connecting to different overlay VRF services on that service node. (R2c) A service node PE MUST support thousand(s) head-end connections to many access node PEs. /* [JORGE] It is hard to understand... should the following be better?: “ (R2b) A service node PE MUST support head-end functionality for thousands of access node PEs that are connected to different VRFs on the service node. (R2c) A service node PE MUST support thousands of CE connections through the attached access nodes." */ Sami: will update. [JORGE2] I don’t see anything changed in rev 02 ;-) 2.5 Multi-homing TBD /* [JORGE] The solution should describe how to handle multi-homing at two levels: - Access node multi-homed to 2 or more Service nodes - CE node multi-homed to 2 or more access nodes (this one should be aligned with the EVPN-VPWS draft) */ Sami: Please have a look at the updated section in 01, as for the CE node agreed that it should be aligned with EVPN-VPWS, and hence no need to mention anything about it in the draft. [JORGE2] OK, please see below. 4 Solution Overview +-+ +-+ | | | | ++ +-+ | IP/MPLS | +-+ | IP/MPLS | | CE |---| PE1 |-| Access |-| PE2 |-| Core| ++ +-+ | Network | +-+ | Network | | | | | +-+ +-+ < EVPN-VPWS >< IP/MAC VRF ---> Figure 1: EVPN-VPWS Service Edge Gateway. AN: Access node SE: Service Edge node. EVPN-VPWS Service Edge Gateway Operation /* [JORGE] Should this be section 4.1 on its own? */ Sami: sure will do. At the service edge node, the EVPN Per-EVI Ethernet A-D routes will be advertised with the ESI set to 0 and the Ethernet tag-id set to (wildcard 0xFFF). The Ethernet A-D routes will have a unique RD and will be associated with 2 BGP RT(s), one RT corresponding to the underlay EVI i.e. the EVPN VPWS transport service that's configured only among the service edge nodes, and one corresponding to the L2, L3 or EVPN overlay service. At the access nodes, the EVPN per-EVI Ethernet A-D routes w
[bess] Please send presentation material for BESS in Seoul
Hello, the agenda has been posted: https://www.ietf.org/proceedings/97/agenda/agenda-97-bess-02 Please start sending your presentation material to Thomas and I. Please do so before Sunday the 13th of November, 23h59 Seoul local time. BESS session is on Monday and I'll be alone so please respect that deadline or take a serious risk of having your slot moved at the end :-) Thank you martin ___ 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
WG, we have now all the IPR answers and support for adopting the document. Authors, please republish as draft-ietf-bess-evpn-bum-procedure-updates-00 Thank you -m Le 16/08/2016 14:37, Martin Vigoureux a écrit : 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
[bess] Slots requests for BESS WG session - IETF 97 - Seoul
All, it is time we start building the BESS WG agenda for Seoul. The IETF agenda is available at: https://datatracker.ietf.org/meeting/97/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Monday, 14th of November, Afternoon session I 13:30-15:30 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 30th of October. Thank you M&T ___ 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
WG there is support to adopt this document in BESS. *Important note* however, please be informed that we did not get responses, to the IPR question, from two Contributors. So, before we adopt this document I'd like to give you the opportunity to reflect on that and express your opinion on the way forward for this document. target deadline: 25th of October 2016 Thank you -m Le 16/08/2016 14:37, Martin Vigoureux a écrit : 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
[bess] Lack of implementation for draft-ietf-bess-virtual-subnet-fib-reduction - submit to IESG?
WG, we have recently LCed draft-ietf-bess-virtual-subnet-fib-reduction and there was sufficient support to move forward. However we haven't received any input on existing implementations. As per [1] we are thus asking the WG whether we should nevertheless move this to IESG or wait until implementations exist. Please respond. Thank you. M&T [1]: https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WG Last Call for draft-ietf-bess-virtual-subnet-fib-reduction-04
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-virtual-subnet-fib-reduction-04 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *30th of August*. Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as an Informational RFC. ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-virtual-subnet-fib-reduction-04, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are listed as a document 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 disclosure exists against this document. ¤ 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. ¤ Finally, if someone wishes to volunteer to be Document Shepherd for this document, please let us know. Thank you M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet-fib-reduction/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03
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] test - please ignore
___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] still no slides for bess Berlin
Speakers, deadline is in less than 12 hrs and we still have not received a single set of slides ... The agenda is pretty full, don't take the risk of seeing your slot moved at the end of the agenda. M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] MVPN YANG draft, welcome your comments
WG, just to clarify, this is not a DT as commonly understood but a group of authors. Le 09/07/2016 14:37, Guofeng a écrit : Hi, We have setup a joint MVPN design team and worked on a MVPN YANG draft, http://www.ietf.org/id/draft-liu-bess-mvpn-yang-01.txt MVPN relates to areas such as MPLS/BGP VPN, P2MP(LDP/TE/GRE), welcome to review and comment on it Thank you, Feng ___ 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] Please send presentation material for BESS in Berlin
Hello, now that the agenda has been posted, please start sending your presentation material to Thomas and I. Please do so before Sunday the 17th of July, 23h59 local time. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] IETF 96 meeting agenda
Hi everyone We've just posted the agenda (still subject to changes) for our meeting in Berlin: https://www.ietf.org/proceedings/96/agenda/agenda-96-bess M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Test
please ignore ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin
All, our slot is confirmed. Please send your slot requests before the deadline indicated below. Thanks martin Le 20/06/2016 13:10, Martin Vigoureux a écrit : All, it is time we start building the BESS WG agenda for Berlin. The IETF agenda is available at: https://datatracker.ietf.org/meeting/96/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 7th of July. Thank you M&T ___ 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] WG feedback on early allocation request for PMSI Tunnel Attribute Flags
Dear WG, we have received an early allocation request from the authors of draft-ietf-bess-evpn-optimized-ir (see details below). Please let us know if you are aware of any code-point conflict, or about any question regarding this allocation. We envisage to proceed with the request on the 27th of June. Thank you M&T --- The New Flags are defined in draft-ietf-bess-evpn-optimized-ir-00 in the following way: 0 1 2 3 4 5 6 7 +-+-+-+-+-+--+-+-+ |rsved| T |BM|U|L| +-+-+-+-+-+--+-+-+ Bits 3-4 -->> 'Type' where: + 00 (decimal 0) = RNVE (non-AR support) + 01 (decimal 1) = AR-REPLICATOR + 10 (decimal 2) = AR-LEAF Bit 5 -->> 'BM' + BM= Broadcast and Multicast (BM) flag. BM=1 means "prune-me" from the BM flooding list. BM=0 means regular behavior. Bit 6 -->> 'U' + U= Unknown flag. U=1 means "prune-me" from the Unknown flooding list. U=0 means regular behavior. --- ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Slots requests for BESS WG session - IETF 96 - Berlin
All, it is time we start building the BESS WG agenda for Berlin. The IETF agenda is available at: https://datatracker.ietf.org/meeting/96/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 7th of July. Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Extended poll [Re: Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02]
All, we have a new WG Document. Authors, please republish as draft-ietf-bess-mvpn-expl-track-00 Thank you -m Le 15/06/2016 10:38, Martin Vigoureux a écrit : All, as a heads-up an IPR disclosure has been made recently: https://datatracker.ietf.org/ipr/2807/ I'll give this call one more week. For those who haven't expressed their opinion, please do so. -m Le 30/05/2016 17:55, Martin Vigoureux a écrit : Hello working group, This email starts a two-week poll on adopting draft-dolganow-bess-mvpn-expl-track-02 [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 13th of June*. 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-dolganow-bess-mvpn-expl-track ___ 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
[bess] Extended poll [Re: Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02]
All, as a heads-up an IPR disclosure has been made recently: https://datatracker.ietf.org/ipr/2807/ I'll give this call one more week. For those who haven't expressed their opinion, please do so. -m Le 30/05/2016 17:55, Martin Vigoureux a écrit : Hello working group, This email starts a two-week poll on adopting draft-dolganow-bess-mvpn-expl-track-02 [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 13th of June*. 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-dolganow-bess-mvpn-expl-track ___ 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] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Thank you Ali Le 07/06/2016 18:04, Ali Sajassi (sajassi) a écrit : Hi Martin, We¹ll also add idr-tunnel-encaps a Informative reference. With respect to Tunnel Encap Extended Community (which is the only part of idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself references RFC 5512. During the course of WG LC and RFC editorship of evpn-overlay draft, if we see that idr-tunnel-encap is progressing fast, then we can drop the reference to RFC 5512 and make the reference to idr-tunnel-encap Normative. Otherwise, we¹ll keep both references with RFC 5512 as Normative and idr-tunnel-encap as Informative. Regards, Ali On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" wrote: Hi, We are fine with keeping 5512 as the Normative reference for now. We would think it wise if the editors can add an Informative reference to draft-ietf-idr-tunnel-encaps (with some text indicating that both specs provide the required support for the procedures). The ideal situation would be that tunnel-encaps progresses fast enough so that in the last stages before publishing evpn-overlay we can be in a situation to make tunnel-encaps the Normative reference. RFC 4897 would facilitate that by the way. If the WG has specific opinions on that matter, they are welcome. We take good note of the shepherd suggestion. We'll confirm who will shepherd the document after WG LC (we'll also call for volunteers during WG Last Call). Reviews are highly welcome anyway, in particular from people close to the topic or implementations, and ideally from more than one person, the best time being now or at least before the WG LC ends. We'll start the WG LC in a couple of days. Martin & Thomas Le 24/05/2016 15:39, John E Drake a écrit : Hi, Ali and I decided to keep the normative reference to RFC 5512 rather than changing it to Eric¹s tunnel encapsulation draft because the normative reference pre-dates Eric¹s draft and because our draft does not use any of the new capabilities introduced in Eric¹s draft. Ali and I would also like to request that Jorge be the document shepherd for this draft. Yours Irrespectively, John *From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com] *Sent:* Tuesday, May 24, 2016 3:05 AM *To:* John E Drake; EXT - thomas.mo...@orange.com; IDR; BESS; draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-en...@tools.ietf.org *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 DCI using ASBR 2. The setting of Ethernet tag and VNI fields there were some inconsistencies in different sections. Section 5.1.3 captures the setting of these fields for different type of services in pretty good details. All other sections were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has been around and its multi-vendor implementation status. Regards, Ali ___ 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] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Hi, We are fine with keeping 5512 as the Normative reference for now. We would think it wise if the editors can add an Informative reference to draft-ietf-idr-tunnel-encaps (with some text indicating that both specs provide the required support for the procedures). The ideal situation would be that tunnel-encaps progresses fast enough so that in the last stages before publishing evpn-overlay we can be in a situation to make tunnel-encaps the Normative reference. RFC 4897 would facilitate that by the way. If the WG has specific opinions on that matter, they are welcome. We take good note of the shepherd suggestion. We'll confirm who will shepherd the document after WG LC (we'll also call for volunteers during WG Last Call). Reviews are highly welcome anyway, in particular from people close to the topic or implementations, and ideally from more than one person, the best time being now or at least before the WG LC ends. We'll start the WG LC in a couple of days. Martin & Thomas Le 24/05/2016 15:39, John E Drake a écrit : Hi, Ali and I decided to keep the normative reference to RFC 5512 rather than changing it to Eric’s tunnel encapsulation draft because the normative reference pre-dates Eric’s draft and because our draft does not use any of the new capabilities introduced in Eric’s draft. Ali and I would also like to request that Jorge be the document shepherd for this draft. Yours Irrespectively, John *From:*Ali Sajassi (sajassi) [mailto:saja...@cisco.com] *Sent:* Tuesday, May 24, 2016 3:05 AM *To:* John E Drake; EXT - thomas.mo...@orange.com; IDR; BESS; draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia - US); draft-ietf-idr-tunnel-en...@tools.ietf.org *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 – DCI using ASBR 2. The setting of Ethernet tag and VNI fields – there were some inconsistencies in different sections. Section 5.1.3 captures the setting of these fields for different type of services in pretty good details. All other sections were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has been around and its multi-vendor implementation status. Regards, Ali ___ 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 (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
WG, we have now received an answer from all the authors and to their knowledge there is no undisclosed IPR that relates to this draft. Sami, please update the draft and make sure that *all* the authors are identified on the submission page, with their latest address, before submitting the draft to publication (the draft alias is incomplete/incorrect). And please get back to the WG with a synthesis of the changes brought to the draft. -m Le 24/05/2016 10:05, Martin Vigoureux a écrit : WG, Authors, we are past the deadline for this WG LC. I am still waiting for statements from authors. In the meantime could you update the draft to reflect the necessary changes which were identified as part of the WG LC. In doing so, could you trim the list of authors to max 5 on the first page and make sure the e-mail addresses are all correct. Beyond that we are ready to go as we have knowledge of implementations. Thank you -m Le 05/05/2016 12:54, EXT Martin Vigoureux a écrit : Hello Working Group, Please read carefully, this e-mail contains new elements compared to other WG LCs. This email starts a Working Group Last Call on draft-ietf-bess-evpn-vpws-03 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *20th of May*. Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC. ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are listed as a document 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. Two IPR disclosures exist against previous revisions of this document [2]. ¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. Please inform the mailing list, the chairs, or only one of the chairs. ¤ Finally, if someone wishes to volunteer to be Document Shepherd for this document, please let us know. Thank you M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws [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
[bess] Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02
Hello working group, This email starts a two-week poll on adopting draft-dolganow-bess-mvpn-expl-track-02 [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 13th of June*. 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-dolganow-bess-mvpn-expl-track ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Fwd: NomCom 2016-2017 Call for Volunteers
WG, please seriously consider volunteering. IETF needs you. Thank you Message transféré Sujet : NomCom 2016-2017 Call for Volunteers Date : Thu, 19 May 2016 12:06:08 -0700 De : NomCom Chair 2016 Répondre à : i...@ietf.org Pour : IETF Announcement List Subject: NomCom 2016-2017 Call for Volunteers The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF = 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as a candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. Some 229 people have already volunteered by ticking the box on the IETF 95 registration form. 131 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Lou Berger IAB: Ralph Droms Russ Housley Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC) Joel Jaeggli (OPS) Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (with the exception of GEN) have at least one continuing AD. The primary activity for this nomcom will begin in July 2016 and should be completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a nomcom member does require some time commitment it is also a very rewarding experience. As a member of the nomcom it is very important that you be able to attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, as follows: To: nomcom-chair-2...@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: ___ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: ___ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Lucy Lynch lly...@civil-tongue.net nomcom-chair-2...@ietf.org ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
WG, Authors, we are past the deadline for this WG LC. I am still waiting for statements from authors. In the meantime could you update the draft to reflect the necessary changes which were identified as part of the WG LC. In doing so, could you trim the list of authors to max 5 on the first page and make sure the e-mail addresses are all correct. Beyond that we are ready to go as we have knowledge of implementations. Thank you -m Le 05/05/2016 12:54, EXT Martin Vigoureux a écrit : Hello Working Group, Please read carefully, this e-mail contains new elements compared to other WG LCs. This email starts a Working Group Last Call on draft-ietf-bess-evpn-vpws-03 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *20th of May*. Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC. ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are listed as a document 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. Two IPR disclosures exist against previous revisions of this document [2]. ¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. Please inform the mailing list, the chairs, or only one of the chairs. ¤ Finally, if someone wishes to volunteer to be Document Shepherd for this document, please let us know. Thank you M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws [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] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
Hello Working Group, Please read carefully, this e-mail contains new elements compared to other WG LCs. This email starts a Working Group Last Call on draft-ietf-bess-evpn-vpws-03 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *20th of May*. Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC. ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are listed as a document 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. Two IPR disclosures exist against previous revisions of this document [2]. ¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. Please inform the mailing list, the chairs, or only one of the chairs. ¤ Finally, if someone wishes to volunteer to be Document Shepherd for this document, please let us know. Thank you M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)
Dear all, we took the opportunity of this IETF meeting to discuss with Sue, Joel and Benoit, and with Eric. Sue has had two requests: 1/ to add some text clarifying the encoding and processing of the Extended Communities this document is defining. Eric had already integrated this text in the document (v06) and more specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended Community) and 4.5 (for the Extranet Separation Extended Community). The text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the split. We have reviewed that with Sue and my understanding of our discussion is that this is acceptable. 2/ to add some text covering risks of mis-configurations Eric has added the paragraph quite soon in the document (the Overview section), such that the reader is aware. Following Thomas' suggestion to enhance that text with other cases of incorrect configurations, Eric has also added some text to the Security Considerations section. Since the document describes a tool-set, rather than trying to describe all the possible usages of these tools, the preferred approach was to give a form of warning on risks of misconf. Our understanding is that the addition of this paragraph would meet Sue's expectations. Version 07, which incorporates the above, is available. Sue, please review the changes and let us know if our understanding is correct or not, and thus if you consider your points addressed. Thank you all Best regards, Martin & Thomas Le 23/12/2015 16:13, Susan Hares a écrit : Eric: *To clear my objection to this draft*, please add these sections to make it clear what the content of the BGP values and their handling.We disagree on what the BGP registry document states, but that point is not worth holding up this document. People can find the type and sub-type fields in the registry. What is not in the registry is a clear description of the restrictions of the value field and handling. Placing the BGP Extended communities within the rest of the rules is just unclear. Please put these two sections in and give the details in this sections. As to the deployment section, you did not consider the text I offer below and the suggested insertion in the security section. Perhaps you can consider that text in your next email. On whether this deployment section is “DISCUSS” worthy, I am still communicating with Benoit and Joel. I wish you the peace and joy of the Christmas season, Sue Hares = Sections which must be added to clear my concerns *4.4.1 Extranet Source Extended Community * To facilitate this, we define a new Transitive Opaque Extended Community, the "Extranet Source" Extended Community. The value field of this extended community is all zeros. *Restrictions: *This value field MUST be set to zero upon origination, MUST be ignored upon reception and MUST be passed unchanged by intermediate routers. *Additional Restrictions: *A Route Reflector MUST NOT add/remove the Extranet Source Extended Community from the VPN-IP routes reflected by the Route Reflector, including the case where VPN-IP routes received via IBGP are reflected to EBGP peers (inter-AS option (c), see [RFC6513] Section 10). *4.4.2 Extranet Separation Extended community * ** We define a new Transitive Opaque Extended Community, the "Extranet Separation" Extended Community. This Extended Community is used only when extranet separation is being used. *Restrictions:* Its value field MUST be set to zero upon origination, MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers. * Restrictions on Adding/deleting this community:* ?? (Eric – please add something here). *Comments that could be put in a Security section: * ** Whenever a VPN is provisioned, there is a risk that provisioning errors will result in an unintended cross-connection of VPNs, which would create a security problem for the customers. Extranet can be particularly tricky, as it intentionally cross-connects VPNs, but in a manner that is intended to be strictly limited by policy. If one is connecting two VPNs that have overlapping address spaces, one has to be sure that the inter-VPN traffic isn't to/from the part of the address space that is in the overlap. The draft discusses a lot of the corner cases, and a lot of the scenarios in which things can go wrong. *From:*BESS [mailto:bess-boun...@ietf.org] *On Behalf Of *Eric C Rosen *Sent:* Tuesday, December 22, 2015 2:08 PM *To:* Susan Hares; 'Benoit Claise'; 'The IESG' *Cc:* draft-ietf-bess-mvpn-extra...@ietf.org; 'John G. Scudder'; aret...@cisco.com; bess-cha...@ietf.org; martin.vigour...@alcatel-lucent.com; bess@ietf.org *Subject:* Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) On 12/22/2015 12:51 PM, Susan Hares wrote: Eric: Thank you for revisions in version -05 of your d
Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02
All, this poll has ended. Although an IPR disclosure came during the poll I did not see any change wrt to the support of this document. We thus have a new WG document. Authors, please republish as draft-ietf-bess-service-chaining-00 Thank you Le 22/02/2016 17:58, EXT Martin Vigoureux a écrit : 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 on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other 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-fm-bess-service-chaining/ ___ 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] Buenos Aires meeting - please send your slides
All, the agenda for the BESS WG session is available here: https://www.ietf.org/proceedings/95/agenda/agenda-95-bess Speakers, please send your slides no later than Sunday the 3rd of April, midnight (local time). Thanks m&t ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Slots requests for BESS WG session - IETF 95 - Buenos Aires
All, the scheduling of our session has been confirmed Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send your requests for slots if you still have some. Thanks -m Le 07/03/2016 13:18, EXT Martin Vigoureux a écrit : All, it is time we start building the BESS WG agenda for Buenos Aires. The IETF agenda is available at: https://datatracker.ietf.org/meeting/95/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 20th of March Thank you M&T ___ 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-fm-bess-service-chaining-02
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 their position please do not hesitate to communicate a revised position, if desired, in light of this upcoming IPR disclosure. For the rest, please do comment on the list, as I'd like to read more comments/opinions from non-authors. Martin Le 07/03/2016 10:05, EXT Dhananjaya Rao (dhrao) a écrit : Hello Martin, WG, It came to our notice recently that there was an old IPR filing on an earlier related draft that had not been submitted to the IETF. An IPR statement has now been submitted and is in progress. This was an inadvertent oversight, and we apologize for the late disclosure. Regards, -Dhananjaya On 2/22/16, 8:58 AM, "BESS on behalf of Martin Vigoureux" wrote: 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 on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other 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-fm-bess-service-chaining/ ___ 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] Slots requests for BESS WG session - IETF 95 - Buenos Aires
All, it is time we start building the BESS WG agenda for Buenos Aires. The IETF agenda is available at: https://datatracker.ietf.org/meeting/95/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 7th of April, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating: draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 20th of March Thank you M&T ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Poll for adoption: draft-fm-bess-service-chaining-02
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 on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other 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-fm-bess-service-chaining/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02
WG, there is good support for the document and all authors have declared that they are not aware of any IPR that relates to this draft. So we have a new WG document Authors please resubmit as draft-ietf-bess-evpn-df-election-00 thank you -m Le 11/01/2016 10:07, Martin Vigoureux a écrit : Hello working group, This email starts a two-week poll on adopting draft-mohanty-bess-evpn-df-election-02 [1] as a working group item. Please state on the list if you support adoption or not (in the both cases, please also state the reasons). This poll runs until *the 25th of January*. Currently no IPR has been disclosed against this document. *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-mohanty-bess-evpn-df-election/ ___ 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] Conclusion on the "one implementation policy"
Working Group, Thomas and I have reviewed the comments expressed on the list since our first proposal on the subject. We consider that there is consensus to put in place the following (which is the amended proposal): At the same time we will issue a Working Group Last Call, we will ask for knowledge of existing implementations, and the more details provided at that time, the better. In the situation where an implementation exists we will proceed with submission to IESG. In the opposite situation, we will systematically ask the WG for reasoned opinions regarding whether we should nevertheless proceed with submission to IESG. We will gauge consensus on that aspect. In case consensus is in favour of proceeding with submission to IESG we will do so. In the opposite case, we will put the document in a "Waiting for implementation" state until information on an existing implementation is brought to our knowledge or of the WG. This is effective from now on. Thank you Martin and Thomas ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call for draft-ietf-bess-pta-flags-01
All, the WG LC deadline is now behind us. I have only seen support for this document. We will thus proceed with submitting it to IESG. -m Le 05/01/2016 15:48, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-pta-flags-01 [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, and send your comments to the list, no later than *12th of January*. 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-multicast-damping, 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-pta-flags-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ___ 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-pta-flags-01
This is a reminder Thank you Le 05/01/2016 15:50, Martin Vigoureux a écrit : Sorry, the deadline is the 19th, not the 12th. Thx -m Le 05/01/2016 15:48, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-pta-flags-01 [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, and send your comments to the list, no later than *12th of January*. 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-pta-flags-01, 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-pta-flags-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ___ 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
[bess] Poll for adoption: draft-mohanty-bess-evpn-df-election-02
Hello working group, This email starts a two-week poll on adopting draft-mohanty-bess-evpn-df-election-02 [1] as a working group item. Please state on the list if you support adoption or not (in the both cases, please also state the reasons). This poll runs until *the 25th of January*. Currently no IPR has been disclosed against this document. *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-mohanty-bess-evpn-df-election/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG Last Call for draft-ietf-bess-pta-flags-01
Sorry, the deadline is the 19th, not the 12th. Thx -m Le 05/01/2016 15:48, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-pta-flags-01 [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, and send your comments to the list, no later than *12th of January*. 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-multicast-damping, 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-pta-flags-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ___ 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] WG Last Call for draft-ietf-bess-pta-flags-01
Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-pta-flags-01 [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, and send your comments to the list, no later than *12th of January*. 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-multicast-damping, 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-pta-flags-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T [1] https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Introducing a one-implementation requirement before WG last calls
WG, we have reviewed the different comments posted on the list in response to our initial proposal. After thinking further about that, we'd like to propose the following as a way forward: At the same time we issue a Working Group Last Call we would ask for knowledge of existing implementations, and the more details provided at that time, the better. In the situation where an implementation would exist we would proceed with submission to IESG. In the opposite situation (no implementation exists), we would systematically ask the WG for reasoned opinions regarding whether we should nevertheless proceed with submission to IESG. We will gauge consensus on that aspect. In case consensus is in favour of proceeding with submission to IESG we will do so. In the opposite case, we will put the document in a "Waiting for implementation" state until information on an existing implementation is brought to our knowledge or of the WG. Please share your views on that. Thank you M&T Le 24/11/2015 10:03, Thomas Morin a écrit : Hello everyone, Following the positive feedback received during BESS meeting in Yokohama about introducing a one-implementation requirement in BESS, we propose to do the following for future WG last calls: As a prerequisite before doing a working group last call on a document, the chairs will ask the working group for known implementations of the specifications; a relatively detailed level of information will be required (e.g. "release x.y of solution z shipping date d", "all features implemented", "partial implementation only", etc.) and everyone will be invited to reply (not only co-authors of the specifications); the chairs will then do the working group last call if satisfying information was provided on at least one implementation. We are open for comments on this proposal until December 7th. Martin & Thomas ___ 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] Need reviews of bess-multicast-damping [Was: Re: WG Last Call for draft-ietf-bess-multicast-damping-01]
WG, we are reiterating the request below; we would highly appreciate reviews from the WG before moving forward. Thank you M&T Le 21/11/2015 01:29, Martin Vigoureux a écrit : WG This WG LC has ended some time ago but without any comment on the draft. It might not have any flaw but I'd like to have the evidence that the document has been reviewed. Please take a moment to read it and get back to this list to share your views. Thanks -m Le 13/10/2015 15:40, Martin Vigoureux a écrit : Hello Working Group, This email starts a Working Group Last Call on draft-ietf-bess-multicast-damping-01 [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, and send your comments to the list, no later than *27th of October*. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-multicast-damping, 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-multicast-damping-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T [1] https://tools.ietf.org/html/draft-ietf-bess-multicast-damping-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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Poll for adoption: draft-morin-bess-mvpn-fast-failover
WG, we have received all feedbacks regarding IPR on that draft and there is support to adopt it. Authors, please resubmit it as draft-ietf-bess-mvpn-fast-failover-00 Thank you Martin Le 02/10/2015 12:29, Martin Vigoureux a écrit : Hello working group, This email starts a two-week poll on adopting draft-morin-bess-mvpn-fast-failover [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 the *16th of October*. Currently there is no IPR disclosed against this document. *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-morin-bess-mvpn-fast-failover ___ 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] Introducing a one-implementation requirement before WG last calls
Hello Kireeti, thanks for your inputs. I understand the challenge that "release x.y @shipping date d" might pose. What we want, is to go beyond the "I am aware of an implementation" type of response. It might currently be sufficient with regards to the shepherd write-up question, but won't be any more if we introduce the requirement. We'd like to have tangible information. Giving "details on how much of the spec was implemented" is clearly going in that direction. -m Le 26/11/2015 02:26, Kireeti Kompella a écrit : Sounds like a good idea to me. One tweak: having an official "release x.y @shipping date d" is unlikely for a draft. The value of one implementation (vs more) is that it shows that a spec is implementable and reasonably complete. So, this should be the focus, with details on how much of the spec was implemented. Shipping plans should be totally optional. Note that even an experimental implementation takes effort, is likely to become official, and shows a degree of seriousness of the part of the implementor. Asking for greater commitment at WGLC is (imho) asking too much. Kireeti On Nov 24, 2015, at 01:03, Thomas Morin wrote: Hello everyone, Following the positive feedback received during BESS meeting in Yokohama about introducing a one-implementation requirement in BESS, we propose to do the following for future WG last calls: As a prerequisite before doing a working group last call on a document, the chairs will ask the working group for known implementations of the specifications; a relatively detailed level of information will be required (e.g. "release x.y of solution z shipping date d", "all features implemented", "partial implementation only", etc.) and everyone will be invited to reply (not only co-authors of the specifications); the chairs will then do the working group last call if satisfying information was provided on at least one implementation. We are open for comments on this proposal until December 7th. Martin & Thomas ___ 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] Introducing a one-implementation requirement before WG last calls
Andy, Loa, thanks for sharing your views. If there are valid reasons for pushing to iesg a non-implemented specification, we'd be ready to consider them. It would simply not be the default way of doing, nor the norm. If it was, if every draft was "really important", then none would really be, in fact. Also, Loa, I believe that the situations you describe would be solved thanks to the introduction of this requirement. -m Le 26/11/2015 06:35, Loa Andersson a écrit : Folks, I'm very much om the same page as Andy, having knowledge of implementations is a good thing. A "requirement" that we have an implementation before requesting that the document is published as an RFC is in most cases also good. The tricky part is when to be flexible. I've asked for implementations for every intended PS we requested publication for. I have more than once been in a situation there operators tell me that the have the draft deployed, but where the vendor does not respond to questions about implementations. I've also seen where two vendors asked for early allocation because they are implementing and doing interop tests. Again one or both vendors does not respond to the implementation poll. 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. In short, with a sufficient level of flexibility I support this. It would be good if we can have some type of report when some experience of the required implementation is at hand. /Loa On 2015-11-26 06:57, Andrew G. Malis wrote: Based on my experience on both the vendor and operator side, I see some practical problems with this approach: - There are some (many?) operators that won’t put drafts into an RFP, only RFCs. - There are some (many?) vendors that won’t implement a draft or RFC, no matter how good the quality, unless they have a customer that wants the feature. That could be an existing customer that needs the feature operationally (which could lead to early implementation), or it could be a prospective customer with an RFP. - Vendors, of course, prioritize their implementation plans, and they usually put RFCs ahead of drafts, since drafts could change before publication, requiring a change in the implementation. For all these reasons, unless there’s an existing customer that needs a draft’s features to fix an operational problem, it’s less common for vendors to implement drafts than RFCs. A better approach might be to do an implementation poll just prior to WG LC (including implementation plans). The WG can then take the results of the poll into consideration during WG LC to see if there’s a consensus to send it to the IESG. There could be a draft that everyone agrees is really important to get published, but for whatever reason hasn’t yet been implemented. Cheers, Andy On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux mailto:martin.vigour...@alcatel-lucent.com>> wrote: Adrian, Thanks. Please see my reactions in-line. -m Le 25/11/2015 01:13, Adrian Farrel a écrit : Yeah, thanks Martin. The slide has... ==Raising the bar?== . Some documents are being pushed to IESG but without any implementation (plan) to support them . We are thinking of "requiring" that at least one implementation exists before handing the document to IESG . Thoughts? The first bullet allows for a plan to implement, the second requires implementation. The use of quotes in the second bullet suggests that you may be considering that the requirement may be flexible. Obviously we have an opening for discussion, but I wonder how you would decide when to be flexible. Good question :-) Indeed, the intent is to not be blindly strict. But defining the margins of flexibility is the tricky part then. I am pretty sure that this will be on a case by case with the default being the 1 implem requirement. I'll take an example: draft-ietf-bess-pta-flags It defines 2 registries as well as a new BGP Extended Community together with the associated processing procedures. The latter is definitely subject to being implemented and as such subject to the requirement we are discussing. However, what this document really does is to define a mechanism in support of specific needs. So I think that this could be a case where we could skip the 1 implem requirement (but apply it to the specs that use pta-flags). The minutes are a good indication of the level of support you received in the room, but not a deep discussion :-) There seems to be some confusion in the discussion between expediting (or unblocking) I-Ds that have an implementa
Re: [bess] Introducing a one-implementation requirement before WG last calls
Adrian, Thanks. Please see my reactions in-line. -m Le 25/11/2015 01:13, Adrian Farrel a écrit : Yeah, thanks Martin. The slide has... ==Raising the bar?== . Some documents are being pushed to IESG but without any implementation (plan) to support them . We are thinking of "requiring" that at least one implementation exists before handing the document to IESG . Thoughts? The first bullet allows for a plan to implement, the second requires implementation. The use of quotes in the second bullet suggests that you may be considering that the requirement may be flexible. Obviously we have an opening for discussion, but I wonder how you would decide when to be flexible. Good question :-) Indeed, the intent is to not be blindly strict. But defining the margins of flexibility is the tricky part then. I am pretty sure that this will be on a case by case with the default being the 1 implem requirement. I'll take an example: draft-ietf-bess-pta-flags It defines 2 registries as well as a new BGP Extended Community together with the associated processing procedures. The latter is definitely subject to being implemented and as such subject to the requirement we are discussing. However, what this document really does is to define a mechanism in support of specific needs. So I think that this could be a case where we could skip the 1 implem requirement (but apply it to the specs that use pta-flags). The minutes are a good indication of the level of support you received in the room, but not a deep discussion :-) There seems to be some confusion in the discussion between expediting (or unblocking) I-Ds that have an implementation, and delaying (or blocking) I-Ds that don't have implementations. While, in a world of limited resources, the two things are related, ideally we are not significantly gating the progress of one I-D because we are busy processing another. I'd say there are different points of view rather than confusion. In a situation where implementations are not considered mandatory, having one might indeed be a criteria for moving faster through the process but I think this is one amongst several possible other criterion. Now, I really, really support your motivation, viz. to reduce the pointless, unreviewed, unnecessary, or substandard drafts being sent for publication. The question is how to achieve that. The primary intent here is to send to IESG only documents that have an implementation. It makes their case stronger, is a contribution to reducing the load on IESG's shoulders, and also it anyway makes little sense to push through the standardization process an implementable specification but for which no implementation exists. The moment to submit to iesg is definitely a good time (and the last possible from a chair's perspective) to think about that. Now, your two sentences above open the door to a broader set of potential actions that could be taken to reach the objective, actions which are relevant during the I-D life cycle within the WG. But I guess this is a broader discussion. Adrian (still thinking about this) -Original Message- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux Sent: 24 November 2015 23:17 To: bess@ietf.org Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls Hi Adrian, indeed, minutes should have been available sooner. situation has been corrected. The basic motivation for this is simply to avoid (over)loading the iesg with documents that have no (and could possibly never have an) implementation. Or, at least, if every spec gets implemented, it is to prioritize them. The discussion happened at the beginning of the meeting. It was on one of the slides I have presented as part of the WG status. -m Le 24/11/2015 17:07, Adrian Farrel a écrit : Hi Thomas, It's really hard to enter this discussion with any context. Could you post the minutes from the meeting and maybe summarise the points in favour of this approach? (Of course, I can listen to the audio when I have some spare time.) Thanks, Adrian ___ 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
