Re: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-services-02

Hello Matthew, Stéphane, Support as co-author. I’m not aware of non-disclosed IPR. Regards, --Bruno From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bo...@nokia.com] Sent: Friday, September 27, 2019 1:00 PM To: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org Subject: WG adoption and IPR

[bess] FW: IPR Disclosure Cisco's Statement about IPR related to draft-dawra-bess-srv6-services

FYI -Original Message- From: IETF Secretariat [mailto:ietf-...@ietf.org] Sent: Tuesday, October 1, 2019 7:59 PM To: draft-dawra-bess-srv6-servi...@ietf.org Cc: ipr-annou...@ietf.org Subject: IPR Disclosure Cisco's Statement about IPR related to draft-dawra-bess-srv6-services Dear Gaurav

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Matthew, Stephane, I'm not aware of non-disclosed IPR. As a co-author, I support publishing this draft as a standards track RFC. Regards, --Bruno From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bo...@nokia.com] Sent: Monday, November 30, 2020 6:16 PM To: draft-ietf-bess-srv6-servi...@ietf.org;

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Hi Stéphane, authors, I have not followed the discussions on this document, but I'll nonetheless raise one point regarding the bandwidth community (better safe than sorry). - why has [BGP-LINK-BW] been moved to informational reference while its reading seem mandatory? - A new EVPN Link Bandwidt

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Hi Neeraj, Thanks for considering my comments. Much better from my perspective. Thank you. I have two comments on the changes: - Regarding deployments §4.1 allows two rather incompatible encodings/usages with no way to detect which one is used: some PE could advertise the bandwidth in bytes, whi

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Hi Jorge, Thanks for the feedback. Regarding the first point, I can live with the current text. But I think I would prefer that the text favour one option, and leave it to the responsibility of the SP for others usages. E.g. OLD: EVPN Link Bandwidth Extended Community value field is to be trea

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

Hi John, Personally, I would prefer that the text indicates the default/standardized usage, such that by default, if all operators follow this, this just works. Proposing no default and that everyone be free to pick his own unit seem to me a path for domain1/AS1/VPN1 picks unit 1 and domain2/AS2

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John, > It's *not* all egress PEs, it's only the multi-homed PEs attached to the same > ES that need to be configured consistently Agreed. But step by step consistency becomes nice to have on all PEs: on a given PE, you probably don't want to mix and match different units on a per ES basis. So

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John, My comment is limited to specifying the default unit which provides consistency by default. I had proposed some text, but others word along this line works for me. Your below text goes beyond this and proposes to additionally change the unit and the syntax. That's your proposal, not mine

Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

John, Those bits are transmitted in the community/BGP in all cases (whether transmitted as 0 or as significant bits) and probably needs to be locally stored in case the BGP routes needs to be re-advertised to another BGP peer. So we are talking about integer computation... I was just saying tha

Re: [bess] draft-rosen-idr-rfc3107bis-00

Hi Eric, Thanks for the draft. I read it and it looks good and useful to me. I have mostly 1 comment: > - RFC 3107 provides an encoding that allows BGP to assign multiple labels Upfront, the current issue is that implementations, which claim compliance with RFC 3107, are just non-compliant. So

Re: [bess] draft-rosen-mpls-rfc3107bis

Hi Eric, Thanks for your reply. Very much appreciated. Sorry for the delay in responding, but I wanted more time to think about it. I'm fine with all your point, except one. Please see inline [Bruno]. > From: Eric C Rosen [mailto:ero...@juniper.net] > Sent: Friday, January 15, 2016 7:01 PM >

Re: [bess] draft-rosen-mpls-rfc3107bis

> From: Eric C Rosen [mailto:ero...@juniper.net] > Sent: Thursday, March 24, > 2016 7:14 PM > On 3/24/2016 11:17 AM, bruno.decra...@orange.com wrote: > > I don't see why the IETF would want to create a bis which is not > compatible with the original RFC, > > It's typical in a bis draft to remov

Re: [bess] draft-rosen-mpls-rfc3107bis

> From: Eric C Rosen [mailto:ero...@juniper.net] > Sent: Friday, April 01, 2016 1:44 PM > > On 3/25/2016 7:25 AM, bruno.decra...@orange.com wrote: > >> I'm quite sure you have deployed implementations, from several > >> prominent vendors, that will not properly handle this case. > > I'm waiting f

Re: [bess] draft-rosen-mpls-rfc3107bis

Please see 1 comment inline [Bruno] From: Eric C Rosen [mailto:ero...@juniper.net] On 4/4/2016 5:28 PM, bruno.decra...@orange.com wrote: > My issue is how do we prove that_nobody_ is using it? Proving the negative > is hard, and silence is not part of the p

[bess] draft-rosen-mpls-rfc3107bis

Eric, Could the draft clarifies the BGP Route Reflector behavior when reflecting a route received from a buggy 3107 implementation with S=0? a) One may argue that the RR should not modify the NLRI and hence reflect the route with S=0 b) One may argue that the RR should reflect the route after se

[bess] draft-rosen-mpls-rfc3107bis-00

Hi Eric, - Do you think that it may be useful to have a sentence about Carrier's Carrier IP VPN? I fear that some implementation may allow multiple labels for SAFI 4 (labelled IP) but not for SAFI 128 (VPN) and would not be capable of translating/swapping from N labels on the PE-CE (SAFI 4) sid

Re: [bess] draft-rosen-mpls-rfc3107bis

From: Eric C Rosen [mailto:ero...@juniper.net] > the "day 1" bugs do exist Do we really have implementation not setting the S bit on the sending side?? I don't see how this could be per design, as I fail to see a reason: - sending with S=1 or S=0 has the same cost from an implementation perspecti

Re: [bess] draft-rosen-mpls-rfc3107bis

Sorry for the late answer and for breaking the email thread. (my laptop hard drive failed during the IETF week). Please see 2 comments inline [Bruno] And as already expressed, I support the adoption of this document. From: Eric C Rosen [mailto:ero...@juniper.net] Right now, we're arguing abo

Re: [bess] IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior to adoption of CAR/CT solutions

Hi all, I'm not aware of non-disclosed IPR. Regards, --Bruno Orange Restricted From: Susan Hares Sent: Thursday, March 3, 2022 8:54 PM To: bess@ietf.org; i...@ietf.org Cc: spring-cha...@ietf.org Subject: IPR call for draft-dskc-bess-bgp-car-03 (3/4 to 3/10) - Prior to adoption of CAR/CT solu