Re: [GROW] [IANA #1292473] [Errata Verified] RFC7854 (7703)
Hi Amanda, Yes, it would indeed be useful. -- Regards, Dhananjay From: Amanda Baber via RT Date: Thursday, 14 December 2023 at 5:49 AM To: rfc-edi...@rfc-editor.org Cc: war...@kumari.net , sstu...@google.com , Rex Fernando (rex) , j...@juniper.net , grow@ietf.org , Dhananjay Patki (dhpatki) Subject: [IANA #1292473] [Errata Verified] RFC7854 (7703) Hi all, Should this errata report be listed as an additional reference for the "L Flag" registration in the "BMP Peer Flags for Peer Types 0 through 2" registry? See https://www.iana.org/assignments/bmp-parameters thanks, Amanda Baber IANA Operations Manager On Mon Dec 11 16:51:10 2023, rfc-edi...@rfc-editor.org wrote: > The following errata report has been verified for RFC7854, > "BGP Monitoring Protocol (BMP)". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7703 > > -- > Status: Verified > Type: Technical > > Reported by: Dhananjay S. Patki > Date Reported: 2023-11-16 > Verified by: Warren Kumari (Ops AD) (IESG) > > Section: 4.2 > > Original Text > - > * The L flag, if set to 1, indicates that the message reflects >the post-policy Adj-RIB-In (i.e., its path attributes reflect >the application of inbound policy). It is set to 0 if the >message reflects the pre-policy Adj-RIB-In. Locally sourced >routes also carry an L flag of 1. See Section 5 for further >detail. This flag has no significance when used with route >mirroring messages (Section 4.7). > > Corrected Text > -- > * The L flag, if set to 1, indicates that the message reflects >the post-policy Adj-RIB-In (i.e., its path attributes reflect >the application of inbound policy). It is set to 0 if the >message reflects the pre-policy Adj-RIB-In. Locally sourced >routes also carry an L flag of 1. See Section 5 for further >detail. This flag has significance only when used with Route >Monitoring messages. > > Notes > - > The L flag is used to indicate whether the route monitoring update > reflects Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB- > Out pre-policy or post-policy (RFC 8671). It does not apply to any > message other than the Route Monitoring message. > > > -- > RFC7854 (draft-ietf-grow-bmp-17) > -- > Title : BGP Monitoring Protocol (BMP) > Publication Date: June 2016 > Author(s) : J. Scudder, Ed., R. Fernando, S. Stuart > Category: PROPOSED STANDARD > Source : Global Routing Operations > Area: Operations and Management > Stream : IETF > Verifying Party : IESG ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] [IANA #1292473] [Errata Verified] RFC7854 (7703)
Hi all, Should this errata report be listed as an additional reference for the "L Flag" registration in the "BMP Peer Flags for Peer Types 0 through 2" registry? See https://www.iana.org/assignments/bmp-parameters thanks, Amanda Baber IANA Operations Manager On Mon Dec 11 16:51:10 2023, rfc-edi...@rfc-editor.org wrote: > The following errata report has been verified for RFC7854, > "BGP Monitoring Protocol (BMP)". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7703 > > -- > Status: Verified > Type: Technical > > Reported by: Dhananjay S. Patki > Date Reported: 2023-11-16 > Verified by: Warren Kumari (Ops AD) (IESG) > > Section: 4.2 > > Original Text > - > * The L flag, if set to 1, indicates that the message reflects >the post-policy Adj-RIB-In (i.e., its path attributes reflect >the application of inbound policy). It is set to 0 if the >message reflects the pre-policy Adj-RIB-In. Locally sourced >routes also carry an L flag of 1. See Section 5 for further >detail. This flag has no significance when used with route >mirroring messages (Section 4.7). > > Corrected Text > -- > * The L flag, if set to 1, indicates that the message reflects >the post-policy Adj-RIB-In (i.e., its path attributes reflect >the application of inbound policy). It is set to 0 if the >message reflects the pre-policy Adj-RIB-In. Locally sourced >routes also carry an L flag of 1. See Section 5 for further >detail. This flag has significance only when used with Route >Monitoring messages. > > Notes > - > The L flag is used to indicate whether the route monitoring update > reflects Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB- > Out pre-policy or post-policy (RFC 8671). It does not apply to any > message other than the Route Monitoring message. > > > -- > RFC7854 (draft-ietf-grow-bmp-17) > -- > Title : BGP Monitoring Protocol (BMP) > Publication Date: June 2016 > Author(s) : J. Scudder, Ed., R. Fernando, S. Stuart > Category: PROPOSED STANDARD > Source : Global Routing Operations > Area: Operations and Management > Stream : IETF > Verifying Party : IESG ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Call for draft-pels-grow-yang-bgp-communities (start 06/Dec/2023 end 06/Jan/2024)
Thus spake Job Snijders (job=40fastly@dmarc.ietf.org) on Wed, Dec 06, 2023 at 04:42:05PM +0100: > Dear GROW, > > The author of draft-pels-grow-yang-bgp-communities asked whether the > GROW working group could consider adoption of their internet-draft. > > This message is a request to the group for feedback on whether this > internet-draft should be adopted. > > Title: YANG Module for BGP Communities > Abstract: > This document provides a YANG module for describing BGP communities. > > The Internet-Draft can be found here: > https://www.ietf.org/archive/id/draft-pels-grow-yang-bgp-communities-00.html > > Please share with the mailing list if you would like this work to be > adopted by GROW, are willing to review and/or otherwise contribute to > this draft! > > WG Adoption call ends January 6th, 2024. I think it is an interesting approach to a real problem, and worthy of group adoption. An overall question I have is with so many nominally unstructured string fields, does that just push the problem out further? For example, in the presentation at IETF, it was mentioned some communities are informational and some are actions. Should there be enumerated fields in the model denoting this? Things in my mind to consider are not just throwing semi-structured data out there for use cases like annotating looking glasses, but could this also help with having a defined format that could help the discoverability of actions for automation systems to use without a human having to read through arbitrary string fields? I realize this could be daunting and potentially delay progress, but there are probably enough usual suspects (like do-not-send-to-xxx and prepend-x-times, etc) that they could be enumerated? Having done some yang stuff on the provisioning end of things, I would emphasize Tom Petch's note to consider typedef's already defined whenever reasonable. For example, RFC 6991 defines 'uri', 'email-address', 'as-number' (of course this will be 4-byte...). There may be more instances like this. >From an ecosystem perspective, we should be thinking about where these would get (linted and) published. Or do we just settle on yang-o-rama.sobornost.net now. ;-) Dale ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Call for draft-pels-grow-yang-bgp-communities (start 06/Dec/2023 end 06/Jan/2024)
Job, I support adoption for this draft and will be trying to proactively work with the author(s) on the content. It's a valuable mechanism to be developed. It likely should also be paired with a mechanism for consistent publication of the data. -- Jeff > On Dec 6, 2023, at 10:42 AM, Job Snijders > wrote: > The author of draft-pels-grow-yang-bgp-communities asked whether the > GROW working group could consider adoption of their internet-draft. > > This message is a request to the group for feedback on whether this > internet-draft should be adopted. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Call for draft-pels-grow-yang-bgp-communities (start 06/Dec/2023 end 06/Jan/2024)
On Wed, 6 Dec 2023, Job Snijders wrote: Please share with the mailing list if you would like this work to be adopted by GROW, are willing to review and/or otherwise contribute to this draft! I support adoption of this draft. It's useful to have standardised representations of this kind of data. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)
Hi, > -Original Message- > From: Dale W. Carder > Sent: Tuesday, December 12, 2023 11:28 PM > To: gengnan > Cc: Job Snijders ; grow@ietf.org > Subject: Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd > (start 06/Dec/2023 end 06/Jan/2024) > > Thus spake gengnan (gengnan=40huawei@dmarc.ietf.org) on Tue, Dec 12, > 2023 at 09:30:06AM +: > > Hi, > > > > I support the adoption of the draft. Some comments that may need to be > considered: > > > > 1. The draft was proposed to GROW WG, but the wg info on the top of the > first page of the draft is opsec. > > > > 2. The meanings of "upstream" in this draft and the ASPA draft are > > different. > According to the term definition in this draft, the ASPA upstream verification > should be conducted for the routes from *downstream* or peer. > > In section 3: " > > Upstream: > > In a direct relationship between two ASes the one providing > > upstream to the other. (See: [RFC9234], also known as the > > provider in a customer-provider relationship.) " > > In section 7.2.2: " > > In [I-D.ietf-sidrops-aspa-verification], see following sections based > >on the neighbor relationship: > > > >* Section 6.1 for routes received from upstreams and lateral peers. > > > >* Section 6.2 for routes received from downstreams and mutual- > > transits. > > " > > > > 3. The term "Mutual Upstream" is not used. It should be "mutual transit" or > "sibling". Also, some terms should be unified, e.g., "upstream" "upstream > provider"; "Internet peer" "lateral peer" "peer"; etc. > > > > 4. In my understanding, some recommended operations have overlapped > protections/functions. For example, both OTC RFC 9234 and RPKI-ASPA can > detect route leaks. Should an operator deploy both techniques or just one of > them (under which conditions)? > > Both! See section 7.2 of draft-ietf-sidrops-aspa-verification > >While the ASPA-based AS_PATH verification method (Section 7.1) >detects and mitigates route leaks that were created by preceding ASes >listed in the AS_PATH, it lacks the ability to prevent route leaks >from occuring at the local AS. The use of the Only to Customer (OTC) >Attribute [RFC9234] fills in that gap. > Thanks. I'd like to say (out of the scope of the draft): it would be better if one kind of problems can be solved by one technique. But here it seems that two techniques are needed for complete protection. > > Dale ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
