[bess] IDR Interim meeting 23 September, 2024 (was [Idr] Four IDR Interims planned prior to IETF-121 in Dublin)

BESS Working Group, IDR will be holding an interim meeting this coming Monday. Two bess WG documents covering the BGP link bandwidth functionality are on the agenda to be discussed. We hope to see you at the meeting next week. -- Jeff > Begin forwarded message: > > From: Jef

[bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

Jorge, > On Jun 24, 2024, at 10:14 AM, Jorge Rabadan (Nokia) > wrote: >> How do you tell if the PE is "non-upgraded"? >> >> Note that such considerations were part of the reason I urged the dpath >> authors towards a BGP capability. :-) >> > > Note that this is for layer 2 routes that ar

[bess] Re: Review of draft-ietf-bess-evpn-ipvpn-interworking-10

Jorge, > On Jun 24, 2024, at 8:01 AM, Jorge Rabadan (Nokia) > wrote: > > Hi Jeff, > > We really appreciate your insights. Version 11 has just been published > addressing all your comments. Thanks. The contents of the diff between 10 and 11 look good. I have no further comments on this ve

[bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

Jorge, > On Jun 24, 2024, at 8:04 AM, Jorge Rabadan (Nokia) > wrote: >> I understand that for this D-PATH feature that the providers should be >> "mutually cooperating" and thus this may be a trivial or even silly concern. >> But if it ever becomes competing providers, this becomes a conversati

[bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

Jorge, I'm responding to the second part of the point since it covers my concern: On Tue, Jun 18, 2024 at 01:35:09PM +, Jorge Rabadan (Nokia) wrote: > > In section 4.1, the cited rules for route selection change are: > > > > :If none of the tie-breaking rules up to (and including) rule

[bess] Re: Review of draft-ietf-bess-evpn-ipvpn-interworking-10

Jorge, On Mon, Jun 17, 2024 at 08:19:49PM +, Jorge Rabadan (Nokia) wrote: > > Having reviewed the full document for the procedure, there's discussion that > > Domains are prepended to the D-PATH similar to the AS_PATH. However, part > > of > > BGP's procedures for AS_PATH effectively is how

[bess] Questions about route selection in draft-ietf-bess-evpn-dpath-00

Authors, As part of reviewing ipvpn interworking, I also have done a higher level review of the new dpath document below. In section 4.1, the cited rules for route selection change are: :If none of the tie-breaking rules up to (and including) rule 5 :produces a single route, the router c

Re: [bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-10

On Thu, Apr 25, 2024 at 10:08:19AM -0400, Jeffrey Haas wrote: > ipvpn authors. A small addendum: The use of D-PATH Domain IDs for loop detection purposes are split in the document. Section 4.d which defines D-PATH mentions two properties: 1. When a looped entry, having been received, may

[bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-10

ipvpn authors. Here is my long delayed review for draft-ietf-bess-evpn-ipvpn-interworking using version 10. To aid in review, I'm using the idnits output for this version of the draft to help identify line numbers. Note, idnits is flagging the following, which needs expansion to make the RFC Edi

Re: [bess] Please send slot request for IETF 118

Mankamana, I'm not seeing an active agenda in the datatracker. However, if there's 10 minutes available (low priority) in the schedule, I'd like to present the BGP attribute escape document to the bess working group: https://datatracker.ietf.org/doc/html/draft-haas-idr-bgp-attribute-escape-00

Re: [bess] WG Last Call on draft-ietf-idr-bgp-model-16

As a correction, the proper URL for the WGLC is here: https://mailarchive.ietf.org/arch/msg/idr/263_yrn_ZnNRokmUwgye7Id5mHo/ -- Jeff (also processing WGLC in BFD) > On Apr 11, 2023, at 10:24 AM, Jeffrey Haas wrote: > > BESS WG, > > The BGP YANG model is starting its Working Gro

[bess] Fwd: WG Last Call on draft-ietf-idr-bgp-model-16

BESS WG, The BGP YANG model is starting its Working Group Last Call in IDR. Since this model not only provides operational visibility into BGP, but provides many base definitions for BGP that are likely to be utilized across other IETF BGP technology YANG models, your review would be greatly a

Re: [bess] [Idr] Review request for draft-ietf-bess-srv6-services-11

Matthew, A few short summary notes before my detailed comments: I have concerns that this feature relies on scoping properties to restrict distribution of the Prefix SID Path Attribute, or the new TLVs in this document, that aren't strictly enforceable during incremental deployment. In some circum

Re: [bess] [Idr] IDR WG last call for draft-ietf-idr-bgp-ext-com-registry-01 (3/11 to 3/25/2021)

On Thu, Mar 11, 2021 at 07:11:30AM -0500, Susan Hares wrote: > This begins a 2 week WG last call for > > draft-ietf-idr-bgp-ext-com-registry-01 from 3/11 to 3/25. > > > > You can find the draft at: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ext-com-registry/ > > > > This d

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

Greg, On Mon, Dec 21, 2020 at 01:08:26PM -0800, Greg Mirsky wrote: > > If the intent was to permit more than one type, the BFD Mode would be > > followed by a length field - likely 2 octets long. > > > GIM2>> At this time I don't see a use case for the same BGP speaker > advertising more than one

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

Álvaro, On Mon, Dec 21, 2020 at 08:00:35AM -0800, Alvaro Retana wrote: > From your replies, I'm not sure if you think the BFD WG should have > been involved more, or if you agree that it may be better to have a > general purpose attribute like this one developed in BFD, or if you > are ok with the

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

Greg, On Sun, Dec 20, 2020 at 04:25:21PM -0800, Greg Mirsky wrote: > GIM>> In Section 7.2 we're requesting IANA to create a new sub-registry. > New types of a BFD session can be bootstrapped using the BGP BFD > Discriminator attribute. For example, draft-ietf-bess-evpn-bfd >

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

Alvaro, Thanks for drawing our attention to this document. On Tue, Dec 15, 2020 at 03:09:54PM -0800, Alvaro Retana via Datatracker wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-bess-mvpn-fast-failover-13: Discuss > > When responding, please keep the subject

Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

Neeraj, Thanks for reminding me to comment on the draft's Link Bandwidth procedures. The existing link bandwidth feature, defined in an expired Internet-Draft, is a non-transitive extended community. Part of the comments I'd given at prior BESS sessions at the microphone was that Juniper has u

Re: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

On Thu, May 09, 2019 at 06:46:02PM +, Mankamana Mishra (mankamis) wrote: > On May 9, 2019, at 11:42 AM, Jeffrey Haas > mailto:jh...@pfrc.org>> wrote: > > Section 7.1: > > The lengths of the various fields and their consistency should be spelled > > out in more d

[bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

I have a few comments on this draft, in particular on the BGP PDU encoding procedures: Section 7.1: The lengths of the various fields and their consistency should be spelled out in more detail. For example, a source could be 0 for (*,G), or should be the length of an IPv4 or IPv6 host address (

[bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited

BESS Working Group members, https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 BFD has finished working group last call on BFD for Vxlan and is about ready to request publication as an RFC. A last minute comment suggested that we should consider inviting comment from your working group for expe

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

On Wed, Apr 13, 2016 at 11:32:40AM +, bruno.decra...@orange.com wrote: > 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 > r