Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Jorge, Please see my replies below with [Ali]. From: "Rabadan, Jorge (Nokia - US/Mountain View)" Date: Tuesday, September 3, 2019 at 10:45 AM To: Cisco Employee , Siddhesh Dindorkar Cc: Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi Ali, Thanks for your comments. Please see some more comments and questions in-line with [JORGE]. Thx Jorge From: BESS on behalf of "Ali Sajassi (sajassi)" Date: Thursday, August 29, 2019 at 9:02 PM To: Siddhesh Dindorkar Cc: Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi Siddhesh, wrt point #3, my point is that there is no guarantee that a given RR vendor implement/support this opaque route. Even if they do, it will take an update to get this feature. For the update of RR, the provider (cloud, sp, Enterprise) has a process in place. This same process that is used for RR upgrade to support this opaque route, can be used to support new routes. I understand that with the opaque route, you upgrade once and the subsequent new routes can be supported transparently but how often do you we introduce new routes. Furthermore, it is better to have a new routes that has multi-vendor interop support than the one that doesn’t have. Do you know of any providers that says I am OK with vendor lock-in? [JORGE] the use of vendor specific types or extensions is not new in IETF. For instance, see ORF vendor specific types, or LDP TLV types, etc. Also, as you mention, the benefit is a single upgrade on RRs to be able to propagate these routes. We can discuss the details of the route format itself, regardless, reserving type 255 is a good practice. [Ali] Wrt ORF, are you aware of any ORF vendor specific type interoperability between a PE and a RR from different vendors? I am not! Wrt LDP TLV types, no RR is involved and if it is targeted LDP, it is purely between two PEs that have implemented proprietary feature and understand each other – i.e., no other devices is involved. There is a difference between reserving a type for a feature confined to two devices from the same vendor versus reserving a type for a feature between two devices from different vendors. What you are asking is unprecedented AFAIK. If you think otherwise, please give specific example. If you look at the history here, we have done pretty well with collaborating together and coming up with the new routes that has multiple vendor support from the beginning. All EVPN route types from RT-5 onward fall into this category. [JORGE] Sure, and this is not against the process of standardizing new route types. New routes that are relevant to multiple vendors and for the industry in general should get a new type. [Ali] So, you don’t plan to ever standardize these routes. If so, then RR is only the first hurdle. All providers and customers that I know, they don’t want vendor lock-in for PEs. If you know of someone who wants vendor lock-in, then it would be good for them to chime-in. But if your intention is to eventually standardize the routes, then the sooner is the better as we have done in the past. With SD-WAN related stuff, you can come with a single extensible route that is future proof (in terms of RR). [JORGE] Can you please elaborate on this? [Ali] Instead of having complete opaque route, one can define a route with fixed portion and variable portion; where fixed portion is part of the BGP route key processing and variable portion is extensible. However, we get into the some basic fundamental here as to why not use existing tunnel attribute for this purpose? What info are you trying to pass that you think it is better suited as BGP route as opposed to BGP attribute? I am just concern that introduction of opaque route will open a Pandora’s box that cannot be closed. [JORGE] Could you please elaborate on the issues you see? Please see more below along your first email. [Ali] Having an opaque route makes our process opaque as well! We don’t know what and why a vendor wants to use this route for and whether the use of BGP machinery is the best option. I much prefer we do things based on technical merit and have complete transparency. On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) mailto:saja...@cisco.com>> wrote: Hi Jorge, I will support this draft if it is modified to specify the routes for SD-WAN application specifically as opposed to have an opaque route. My concerns are the following: 1. The main idea of standardization is interoperability among vendors and this draft doesn’t give us that. 2. Also I don’t think having such a draft can facilitate prototyping. This draft has been around for several years and your prototyping should have been independent of this draft since I am not aware of any other major vendo
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi WG, The poll has ended. Some concerns have been raised on having this opaque route. More discussion is required before adopting the document. Stephane From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Stephane Litkowski Sent: Monday, August 19, 2019 16:32 To: bess@ietf.org Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ _ 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
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Ali, Thanks for your comments. Please see some more comments and questions in-line with [JORGE]. Thx Jorge From: BESS on behalf of "Ali Sajassi (sajassi)" Date: Thursday, August 29, 2019 at 9:02 PM To: Siddhesh Dindorkar Cc: Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi Siddhesh, wrt point #3, my point is that there is no guarantee that a given RR vendor implement/support this opaque route. Even if they do, it will take an update to get this feature. For the update of RR, the provider (cloud, sp, Enterprise) has a process in place. This same process that is used for RR upgrade to support this opaque route, can be used to support new routes. I understand that with the opaque route, you upgrade once and the subsequent new routes can be supported transparently but how often do you we introduce new routes. Furthermore, it is better to have a new routes that has multi-vendor interop support than the one that doesn’t have. Do you know of any providers that says I am OK with vendor lock-in? [JORGE] the use of vendor specific types or extensions is not new in IETF. For instance, see ORF vendor specific types, or LDP TLV types, etc. Also, as you mention, the benefit is a single upgrade on RRs to be able to propagate these routes. We can discuss the details of the route format itself, regardless, reserving type 255 is a good practice. If you look at the history here, we have done pretty well with collaborating together and coming up with the new routes that has multiple vendor support from the beginning. All EVPN route types from RT-5 onward fall into this category. [JORGE] Sure, and this is not against the process of standardizing new route types. New routes that are relevant to multiple vendors and for the industry in general should get a new type. With SD-WAN related stuff, you can come with a single extensible route that is future proof (in terms of RR). [JORGE] Can you please elaborate on this? I am just concern that introduction of opaque route will open a Pandora’s box that cannot be closed. [JORGE] Could you please elaborate on the issues you see? Please see more below along your first email. Cheers, Ali From: Siddhesh Dindorkar Date: Wednesday, August 28, 2019 at 2:43 PM To: Cisco Employee Cc: Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi Ali, thanks for the detailed comments. We understand your view and those were the discussion points within us as well. However, in reference to your RR point #3, one of the reason for a vendor specific evpn route type is to be able to do prototyping within small scale deployements which use other vendor RRs. Even if we have RFCs for new route types, other vendors may not implement them if they dont need those usecases and/or is not a release priority. Hence again comes the restriction in using other vendor RR until the new route type is implemented by the RR vendor. Best, Siddhesh On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) mailto:saja...@cisco.com>> wrote: Hi Jorge, I will support this draft if it is modified to specify the routes for SD-WAN application specifically as opposed to have an opaque route. My concerns are the following: 1. The main idea of standardization is interoperability among vendors and this draft doesn’t give us that. 2. Also I don’t think having such a draft can facilitate prototyping. This draft has been around for several years and your prototyping should have been independent of this draft since I am not aware of any other major vendor implemented or deployed this draft. [JORGE] As discussed, our view is that standardization is still relevant since there are BGP speakers that do not need to understand the content of the route, but do need to make basic checks before propagating the route. 3. Even if this draft becomes an RFC, there is no guarantee that in a given network the RR will be compliant with it as we have experienced such things first hand in the field [JORGE] Sure, however standardizing this will help. 4. Making dependency of an IETF draft on IEEE process is not a good thing – i.e., an new vendor that wants to implement it now needs to apply for an IEEE OUI. OUI gets allocated to the vendor with Ethernet PHY for MAC addresses and not as route distinguisher. I am not sure how IEEE will look at this. Have you discussed your application with them (e.g., OUI for non-related Ethernet PHY/MAC) [JORGE] Requesting an OUI to IEEE is pretty straight forward and a lot of vendors have OUIs that can reuse here since this is NOT used in the data plane. The OUI is an easy way to avoid clashing among vendors, but as discussed with Jeff, we are open to add a generic or “wildcard OUI” or any other identifier here if the use of
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Siddhesh, wrt point #3, my point is that there is no guarantee that a given RR vendor implement/support this opaque route. Even if they do, it will take an update to get this feature. For the update of RR, the provider (cloud, sp, Enterprise) has a process in place. This same process that is used for RR upgrade to support this opaque route, can be used to support new routes. I understand that with the opaque route, you upgrade once and the subsequent new routes can be supported transparently but how often do you we introduce new routes. Furthermore, it is better to have a new routes that has multi-vendor interop support than the one that doesn’t have. Do you know of any providers that says I am OK with vendor lock-in? If you look at the history here, we have done pretty well with collaborating together and coming up with the new routes that has multiple vendor support from the beginning. All EVPN route types from RT-5 onward fall into this category. With SD-WAN related stuff, you can come with a single extensible route that is future proof (in terms of RR). I am just concern that introduction of opaque route will open a Pandora’s box that cannot be closed. Cheers, Ali From: Siddhesh Dindorkar Date: Wednesday, August 28, 2019 at 2:43 PM To: Cisco Employee Cc: Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi Ali, thanks for the detailed comments. We understand your view and those were the discussion points within us as well. However, in reference to your RR point #3, one of the reason for a vendor specific evpn route type is to be able to do prototyping within small scale deployements which use other vendor RRs. Even if we have RFCs for new route types, other vendors may not implement them if they dont need those usecases and/or is not a release priority. Hence again comes the restriction in using other vendor RR until the new route type is implemented by the RR vendor. Best, Siddhesh On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) mailto:saja...@cisco.com>> wrote: Hi Jorge, I will support this draft if it is modified to specify the routes for SD-WAN application specifically as opposed to have an opaque route. My concerns are the following: 1. The main idea of standardization is interoperability among vendors and this draft doesn’t give us that. 2. Also I don’t think having such a draft can facilitate prototyping. This draft has been around for several years and your prototyping should have been independent of this draft since I am not aware of any other major vendor implemented or deployed this draft. 3. Even if this draft becomes an RFC, there is no guarantee that in a given network the RR will be compliant with it as we have experienced such things first hand in the field 4. Making dependency of an IETF draft on IEEE process is not a good thing – i.e., an new vendor that wants to implement it now needs to apply for an IEEE OUI. OUI gets allocated to the vendor with Ethernet PHY for MAC addresses and not as route distinguisher. I am not sure how IEEE will look at this. Have you discussed your application with them (e.g., OUI for non-related Ethernet PHY/MAC) 5. RR can be used as store and forward mechanism for data that didn’t use BGP before. I have already seen that some people want to use BGP for passing configuration, stats, diagnostics info, etc. With now defining an opaque route, there will be no check on the contents of the route and anyone can put anything they want even if it is not best suited to do them in BGP. So, frankly, I don’t see any positives here but just negatives. Can you replace the opaque route with the actual routes. At the end of the day, we have to do it for multi-vendor interop anyway. So, the sooner, the better. If single-vendor deployment is sufficient which is typically the case for Enterprises, then there is no need to standardize such draft. Cheers, Ali From: BESS mailto:bess-boun...@ietf.org>> on behalf of Stephane Litkowski mailto:slitkows.i...@gmail.com>> Date: Tuesday, August 20, 2019 at 2:16 AM To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Ali, thanks for the detailed comments. We understand your view and those were the discussion points within us as well. However, in reference to your RR point #3, one of the reason for a vendor specific evpn route type is to be able to do prototyping within small scale deployements which use other vendor RRs. Even if we have RFCs for new route types, other vendors may not implement them if they dont need those usecases and/or is not a release priority. Hence again comes the restriction in using other vendor RR until the new route type is implemented by the RR vendor. Best, Siddhesh On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) wrote: > Hi Jorge, > > > > I will support this draft if it is modified to specify the routes for > SD-WAN application specifically as opposed to have an opaque route. My > concerns are the following: > > > >1. The main idea of standardization is interoperability among vendors >and this draft doesn’t give us that. >2. Also I don’t think having such a draft can facilitate prototyping. >This draft has been around for several years and your prototyping should >have been independent of this draft since I am not aware of any other major >vendor implemented or deployed this draft. >3. Even if this draft becomes an RFC, there is no guarantee that in a >given network the RR will be compliant with it as we have experienced such >things first hand in the field >4. Making dependency of an IETF draft on IEEE process is not a good >thing – i.e., an new vendor that wants to implement it now needs to apply >for an IEEE OUI. OUI gets allocated to the vendor with Ethernet PHY for >MAC addresses and not as route distinguisher. I am not sure how IEEE will >look at this. Have you discussed your application with them (e.g., OUI for >non-related Ethernet PHY/MAC) >5. RR can be used as store and forward mechanism for data that didn’t >use BGP before. I have already seen that some people want to use BGP for >passing configuration, stats, diagnostics info, etc. With now defining an >opaque route, there will be no check on the contents of the route and >anyone can put anything they want even if it is not best suited to do them >in BGP. > > > > So, frankly, I don’t see any positives here but just negatives. Can you > replace the opaque route with the actual routes. At the end of the day, we > have to do it for multi-vendor interop anyway. So, the sooner, the better.. > If single-vendor deployment is sufficient which is typically the case for > Enterprises, then there is no need to standardize such draft. > > > > Cheers, > > Ali > > > > > > *From: *BESS on behalf of Stephane Litkowski < > slitkows.i...@gmail.com> > *Date: *Tuesday, August 20, 2019 at 2:16 AM > *To: *"bess@ietf.org" > *Subject: *[bess] WG adoption call and IPR poll for > draft-rabadan-bess-vendor-evpn-route-07 > > > > Hi, > > > > This email begins a two-weeks WG adoption poll > for draft-rabadan-bess-vendor-evpn-route-07 [1] > > Please review the draft and post any comments to the BESS working group > list. > > > > We are also polling for knowledge of any undisclosed IPR that applies to > this Document, to ensure that IPR has been disclosed in compliance with > IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as an author or a contributor of this document, please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR, copying the BESS mailing list. The document won't > progress without answers from all the authors and contributors. > > Currently, there are no IPR disclosures against this document. > > > > If you are not listed as an author or a contributor, then please > explicitly respond only if you are aware of any IPR that has not yet been > disclosed in conformance with IETF rules. > > > > This poll for adoption closes on 2nd September 2019. > > > > Regards, > > Stephane and Matthew > > > > [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Support Thanks Roberto From: BESS on behalf of "UTTARO, JAMES" Date: Tuesday, August 27, 2019 at 8:37 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" , Stephane Litkowski , "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Support for WG adoption.. Thanks, Jim Uttaro From: BESS On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Saturday, August 24, 2019 6:41 AM To: Stephane Litkowski ; bess@ietf.org Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 As a co-author, I support this document for WG adoption. I’m not aware of any IPR relevant to this document. Thanks. Jorge From: BESS mailto:bess-boun...@ietf.org>> on behalf of Stephane Litkowski mailto:slitkows.i...@gmail.com>> Date: Tuesday, August 20, 2019 at 11:15 AM To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drabadan-2Dbess-2Dvendor-2Devpn-2Droute_=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=FCsSBcbdid_AXLD6cjr7WEpXXkEnUUioaejhrgt2vfk=-yheh5LqW8rMhLTXFWAyBEee1YJLMR4pE-odvL1toDQ=> ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Support for WG adoption.. Thanks, Jim Uttaro From: BESS On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Saturday, August 24, 2019 6:41 AM To: Stephane Litkowski ; bess@ietf.org Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 As a co-author, I support this document for WG adoption. I’m not aware of any IPR relevant to this document. Thanks. Jorge From: BESS mailto:bess-boun...@ietf.org>> on behalf of Stephane Litkowski mailto:slitkows.i...@gmail.com>> Date: Tuesday, August 20, 2019 at 11:15 AM To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>> Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drabadan-2Dbess-2Dvendor-2Devpn-2Droute_=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=FCsSBcbdid_AXLD6cjr7WEpXXkEnUUioaejhrgt2vfk=-yheh5LqW8rMhLTXFWAyBEee1YJLMR4pE-odvL1toDQ=> ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Support to adopt. I think this work is useful for the WG and the industry to progress. Brgds, G/ From: BESS On Behalf Of Stephane Litkowski Sent: Monday, August 19, 2019 21:32 To: bess@ietf.org Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Not aware of any undisclosed IPR. -m Le 2019-08-19 à 16:32, Stephane Litkowski a écrit : > Hi, > > > This email begins a two-weeks WG adoption poll > for draft-rabadan-bess-vendor-evpn-route-07 [1] > > Please review the draft and post any comments to the BESS working group > list. > > We are also polling for knowledge of any undisclosed IPR that applies to > this Document, to ensure that IPR has been disclosed in compliance with > IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as an author or a contributor of this document, please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR, copying the BESS mailing list. The document > won't progress without answers from all the authors and contributors. > > Currently, there are no IPR disclosures against this document. > > If you are not listed as an author or a contributor, then please > explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules. > > This poll for adoption closes on 2nd September 2019. > > Regards, > > Stephane and Matthew > > [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ > > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Stephane, It is not a security key. As you say it could be used to encode multiple sub-types with different vendor specific info, but we wanted to define it flexible/open enough for the individual vendor to decide. We can add a sentence stating that.. Thank you! Jorge From: BESS on behalf of "stephane.litkow...@orange.com" Date: Wednesday, August 21, 2019 at 10:29 AM To: "bess@ietf.org" Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, Speaking as individual, what is the goal of the vendor key ? Is it to allow a vendor to encode multiple “sub-types” with different vendor specific info ? Or is it a security key ? That would be great to mention how a vendor should use it. Thanks ! From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Stephane Litkowski Sent: Monday, August 19, 2019 16:32 To: bess@ietf.org Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ _ 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
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
As a co-author, I support this document for WG adoption. I’m not aware of any IPR relevant to this document. Thanks. Jorge From: BESS on behalf of Stephane Litkowski Date: Tuesday, August 20, 2019 at 11:15 AM To: "bess@ietf.org" Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi Jeff, Thank you very much for your feedback. The idea was that a vendor using this route type could use a value unique to them. In case of not having an OUI, the registration of a new one with the IEEE should be pretty straight forward. We’ll add the informal reference that you mention, thanks. If needed, we are also open to use a generic OUI value that anyone can use. Thanks. Jorge From: BESS on behalf of Jeff Tantsura Date: Tuesday, August 20, 2019 at 7:24 PM To: "bess@ietf.org" , Stephane Litkowski Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 In general I support the adoption. Could the authors please clarify how a company that doesn’t have OUI assigned should populate the OUI field and how interdependency between IEEE registration and EVPN implementation would be handled. Informal references for IEEE OUI handling process would be useful too, perhaps this one - https://standards.ieee.org/products-services/regauth/tut/index.html Cheers, Jeff On Aug 20, 2019, 5:15 AM -0400, Stephane Litkowski , wrote: Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document.. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Hi, Speaking as individual, what is the goal of the vendor key ? Is it to allow a vendor to encode multiple “sub-types” with different vendor specific info ? Or is it a security key ? That would be great to mention how a vendor should use it. Thanks ! From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Stephane Litkowski Sent: Monday, August 19, 2019 16:32 To: bess@ietf.org Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ _ 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
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Could the authors provide further insight on the following.. “ The intend of this new Type is to allow operators and vendors to design rapidly new EVPN applications/prototypes and experiment with them in deployed networks before standardizing the specific application. Software Defined Networks (SDN) are evolving fast and the flexibility allowed by this new Route Type will contribute to the SDN control plane evolution.” Thanks, Jim Uttaro From: BESS On Behalf Of Jeff Tantsura Sent: Tuesday, August 20, 2019 1:24 PM To: bess@ietf.org; Stephane Litkowski Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07 In general I support the adoption. Could the authors please clarify how a company that doesn’t have OUI assigned should populate the OUI field and how interdependency between IEEE registration and EVPN implementation would be handled. Informal references for IEEE OUI handling process would be useful too, perhaps this one - https://standards.ieee.org/products-services/regauth/tut/index.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__standards.ieee.org_products-2Dservices_regauth_tut_index.html=DwQFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=MYuiLReJlALiFwDrRezkBWP2u4ggWRWeN0eIP5w7al8=XUVcfVx2JQIwaW8F6JwTZo3uoNsUuvw6Eh80onubSKg=> Cheers, Jeff On Aug 20, 2019, 5:15 AM -0400, Stephane Litkowski mailto:slitkows.i...@gmail.com>>, wrote: Hi, This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1] Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document.. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on 2nd September 2019. Regards, Stephane and Matthew [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drabadan-2Dbess-2Dvendor-2Devpn-2Droute_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=MYuiLReJlALiFwDrRezkBWP2u4ggWRWeN0eIP5w7al8=3J4-0GVkpzaHtSWBVIB1M27NrF9hWg4vgc00q896Bvo=> ___ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess=DwQFaQ=LFYZ-o9_HUMeMTSQicvjIg=s7ZzB4JbPv3nYuoSx5Gy8Q=MYuiLReJlALiFwDrRezkBWP2u4ggWRWeN0eIP5w7al8=7DyN6_vPh_Mrdl3tDhi4_pFpdiiKFTL8LBLzX38CLDs=> ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
In general I support the adoption. Could the authors please clarify how a company that doesn’t have OUI assigned should populate the OUI field and how interdependency between IEEE registration and EVPN implementation would be handled. Informal references for IEEE OUI handling process would be useful too, perhaps this one - https://standards.ieee.org/products-services/regauth/tut/index.html Cheers, Jeff On Aug 20, 2019, 5:15 AM -0400, Stephane Litkowski , wrote: > Hi, > > This email begins a two-weeks WG adoption poll for > draft-rabadan-bess-vendor-evpn-route-07 [1] > Please review the draft and post any comments to the BESS working group list. > > We are also polling for knowledge of any undisclosed IPR that applies to this > Document, to ensure that IPR has been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as an author or a contributor of this document, please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR, copying the BESS mailing list. The document won't > progress without answers from all the authors and contributors. > Currently, there are no IPR disclosures against this document. > > If you are not listed as an author or a contributor, then please explicitly > respond only if you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > This poll for adoption closes on 2nd September 2019. > > Regards, > Stephane and Matthew > > [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/ > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
