Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, draft-liu-grow-bmp-stats-reports-00

[Job Snijders]

Dear Mukul,

Thanks for posting a new version of the document.

Can you expand the "IANA Considerations" section a bit more?

Precise instructions from which sub-registries exactly codepoints need
to be allocated with what names would be good.

Right now the section reads: "This document requests that IANA assign
the following new parameters to the BMP parameters name space."

So it seems some piece is missing

Kind regards,

Job

On Tue, Apr 30, 2024 at 04:36:32PM +, Mukul Srivastava wrote:
> Hi All
> 
> All comments have been addressed and the new doc has been posted. Feel free 
> to review and provide comments.
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-02
> 
> @grow-cha...@ietf.org
> 
> I am looking for early code point assignment. Pls help in the assignment.
> 
> @lijinm...@chinamobile.com
> Let me know if you want to combine your work with my draft.
> 
> Thanks
> Mukul
> 
> 
> 
> Juniper Business Use Only
> From: GROW  on behalf of Mukul Srivastava 
> 
> Date: Friday, March 22, 2024 at 9:43 AM
> To: thomas.g...@swisscom.com , grow@ietf.org 
> , liuyis...@chinamobile.com , 
> linchangwang.04...@h3c.com , 
> lijinm...@chinamobile.com 
> Cc: pa...@pmacct.net 
> Subject: Re: [GROW] IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, 
> draft-liu-grow-bmp-stats-reports-00
> [External Email. Be cautious of content]
> 
> Hi Thomas
> 
> All good points and I appreciate your feedback. I will update the doc with 
> your comment.
> 
> Jinming, I think we should connect to combine both docs in one.
> 
> Thanks
> Mukul
> 
> 
> 
> Juniper Business Use Only
> 
> 
> Juniper Business Use Only
> From: thomas.g...@swisscom.com 
> Date: Tuesday, March 19, 2024 at 9:04 PM
> To: grow@ietf.org , liuyis...@chinamobile.com 
> , linchangwang.04...@h3c.com 
> , lijinm...@chinamobile.com 
> , Mukul Srivastava 
> Cc: ahmed.elhass...@swisscom.com , 
> pa...@pmacct.net 
> Subject: IETF 119, GROW, draft-ietf-grow-bmp-bgp-rib-stats-01, 
> draft-liu-grow-bmp-stats-reports-00
> 
> Dear Mukul and Jinming,
> 
> 
> 
> I have reviewed both documents and have a few comments. Speaking as a network 
> operator, first of all I believe as previous stated it is very much valued 
> that you intend not only to update existing BMP statistics but also much 
> needed new statistics. Thank you very much for this. I agree that it would be 
> helpful if both documents could be merged into 1 before the working group 
> adoption.
> 
> 
> 
> 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-01#section-2.1
> 
> 
> 
> TBD1, TBD2, TBD3 and TBD4: I appreciate that you are changing from counter to 
> gauge, having statistics for pre and post policy in adj-rib as a summary for 
> all address families and for each address family. I value this granularity.
> 
> TBD5, TBD6 and TBD11: This gives visibility in how many routes have been 
> accepted or dropped by the route policy. I value that you changed from 
> counter to gauge since an operator is typically not interested in the route 
> event count, they are interested in the amount of routes within the rib.
> 
> TBD7: The term "active route" is not well defined to my understanding. I 
> suggest to align to 
> https://datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv-12#section-2.1
>  and define a gauge for primary and backup path.
> 
> TBD8: I suggest to use the term " Suppressed" instead of "Dampened" and make 
> a reference to 
> https://www.rfc-editor.org/rfc/rfc2439#section-2.2
>  to be aligned with 
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1
> 
> TBD9. I suggest to be more specific with the reference to 
> https://www.rfc-editor.org/rfc/rfc4724.html#section-4.1
>  to be aligned with 
> 

[GROW] Working Group Call for Adoption for draft-hmntsharma-bmp-tcp-ao (start 29/Apr/2024 end 15/May/2024)

[Job Snijders]

Dear GROW,

The author of draft-hmntsharma-bmp-tcp-ao 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: TCP-AO Protection for BGP Monitoring Protocol
Abstract:
  This document outlines the utilization of the TCP Authentication
  Option (TCP-AO), as specified in RFC5925, for the authentication of
  BGP Monitoring Protocol (BMP) sessions, as specified in RFC7854.
  TCP-AO provides for the authentication of BMP sessions established
  between routers and BMP stations at the TCP layer.
 
The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/html/draft-hmntsharma-bmp-tcp-ao

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 May 15th, 2024.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peering API side meeting 2024-03-21 minutes

[Job Snijders]

Thanks Tom!

Looks like it was a good meeting.

I’ll wait for a next revision before issuing the call for the working group
adoption.

Kind regards,

Job
Co-chair GROW

On Thu, 21 Mar 2024 at 16:41, Tom Strickx  wrote:

> Dear grow members, please find the minutes of the Peering API side meeting
> below:
>
> Attendees: Aussie Broadband, Amazon, Workonline, Huawei, APNIC, Telstra,
> Meta, Cloudflare (12 attendees)
>
> 1. Brief walkthrough of PeeringAPI.
> 2. Open questions: PNIs: who issues LOAs, who orders XCs, exchanging
> preferences (redundant links, who unfilters first, ...). PeeringDB is not
> good enough. RPKI signed checklists could be worth it. Provisioning Finite
> State Machine.
>
> 3. Work with Peering Manager to implement the API to advance adoption.
> 4. Aussie agrees this is a good idea. Great for an eyeball network.
> Reduces complexity, single pane of glass.
> 5. 2 Types of business logic: peering logic and business logic that goes
> in the provisioning. The second one is what needs modelling.
> 6. IXP Manager integration?
> 7. Are there any additional security considerations?
> 8. Ben Maddison explains RSC. Signatures over arbitrary blobs of data.
> Rough workflow: each party issues a challenge. Sign the challenge. Provide
> signed blob back over the API (inband).
> PeeringDB is good enough for now, but baking it into the protocol as a
> first-class citizen might be a mistake. Make RSC a first-class citizen, and
> machine-to-machine OATH as a fallback. Similar to the key negotiation
> within SSH: Offer list of IdPs, receive list of IdPs. Ordering is not
> important, as long as you pick an IdP that is trusted. No need to use the
> same IdP in both directions.
> 9. Don't roundtable the FSM. Might need a workflow negotiation system.
> Might be good to communicate operational state. Get a feedback loop going.
> 2 classes of state transition: 1 that requires coordination, 1 that
> doesn't. To what extent do we expose "hygiene" of turnup testing. Protocol
> coordination will need to happen for ordering-of-actions. Might need a
> deadlock state.
> What are the preferences we should care about? Provide a human address for
> "escalation" in case of deadlock.
> Tie-break decision algorithms?
> Make the errors more expressive, but structured text. ENUM for the most
> frequent ones, but allow extendability. Look to YANG?
> Allow for resumption through the FSM once deadlocks have been resolved. If
> data-leaf is not provided, block state transition, and progress once that's
> there. Coordinated data-collection exercise.
> Route-server sessions?
>
> Next steps: We'll work on adding a section on the RSC challenge-response
> proposed authorization and authentication workflow. Work will also start on
> a minimal provisioning FSM. We want to thank all the contributors of
> today's meeting, and look forward to working with the Working Group in
> advancing this draft.
>
> --
> Tom Strickx
> Principal Network Engineer
> AS13335 - Cloudflare
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WGADOPTION - draft-spaghetti-grow-bcp-ext-comms - ENDS 04/08/2024 - Apr 8th 2024

[Job Snijders]

On Sat, Mar 16, 2024 at 08:19:42PM -0400, Jeffrey Haas wrote:
> > Moreover, we know at least another IXP that dropped support for
> Extended Communities 2 years ago with big success, thus adopting
> such a practice from other fellow IXPs shouldn’t be of
> an issue as long as support for Large Communities is in place.
> 
> So, this includes things like RPKI validation signaled by RFC 8097 done by
> the IXP RS?

The RFC 8097 communities are non-transitive, right? It would seem
strange to ingest those via an EBGP session from the Route Server?

Additionally, I think there are issues with signaling RPKI validation states
via EBGP, it can cause needless churn. We tried to capture that here:
https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-avoid-rpki-state-in-bgp

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Submission of draft-spaghetti-grow-bcp-ext-comms-01

[Job Snijders]

Dear all,

Thank you all for the feedback so far!

I posted a small revision to clarify the scope of the document

https://author-tools.ietf.org/iddiff?url1=draft-spaghetti-grow-bcp-ext-comms-00=draft-spaghetti-grow-bcp-ext-comms-01=--html

Kind regards,

Job
co-author / not in chair capacity

On Mon, Mar 11, 2024 at 07:51:55PM +, Stavros Konstantaras wrote:
> Dear colleagues of GROW-WG,
> 
> We (Stavros Konstantaras, Job Snijders and Moyaze Shivji) have submitted the 
> draft-spaghetti-grow-bcp-ext-comms-00, which you can find it in the following 
> URL: https://datatracker.ietf.org/doc/draft-spaghetti-grow-bcp-ext-comms/
> 
> In this draft, we introduce a recommendation to avoid the use of BGP Extended 
> Communities at the Route Servers of Internet Exchange points. Hence,  we 
> would like to request from the community and the GROW chairs to adopt  the 
> draft as a WG item. We welcome your review and any possible constructive 
> feedback either in this e-mail thread or in private messages.
> 
> 
> Thank you in advance,
> 
> 
> Stavros Konstantaras | Sr. Network Engineer | AMS-IX
> Frederiksplein 42, 1017 XN Amsterdam, The Netherlands
> M +31 (0) 620 89 51 04
> ams-ix.net<http://ams-ix.net>
> Stavros Konstantaras
> 
> 

> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WGADOPTION - draft-spaghetti-grow-bcp-ext-comms - ENDS 04/08/2024 - Apr 8th 2024

[Job Snijders]

Hi Jeff,



On Thu, Mar 14, 2024 at 10:54:54PM -0400, Jeff Haas wrote:
> I’m at least 90%, “Meh, whatever “ for the
> proposal as long as it doesn’t become a recommendation to filter
> the extended communities by default.  For purposes of the adoption poll,
> consider this a conditional abstention. 
> 
> The last 10% of my opinion is formed by the fact that extended communities
> have built-in scoping whereas large communities do not. 
> 
> There’s room for legitimate griping about policy tools to use
> extended communities, but those are implementation details. 


Re-reading the abstract, I can imagine the scope maybe appearing wider
than the authors perhaps intended.

The draft guidance is intended to be narrow: please avoid use of &
filter extended communities *at IXP Route Servers*. The target audience
of this draft BCP are IXP Route Server operators.

Does the above change your position in any way?

Kind regards,

Job



> 
> Jeff. 
> 
> Sent from my iPad
> 
> > On Mar 11, 2024, at 15:13, Christopher Morrow 
> >  wrote:
> > 
> > Howdy WG folks!
> > The authors of: draft-spaghetti-grow-bcp-ext-comms
> >  (https://datatracker.ietf.org/doc/draft-spaghetti-grow-bcp-ext-comms/)
> > 
> > are interested in seeking WG Adoption for their new missive. The
> > abstract is included here-in:
> > 
> >  "This document outlines a recommendation to the Internet operational
> >   community to avoid the use of BGP Extended Communities in BGP
> >   announcements.  It includes guidance for both Internet Service
> >   Provider networks and Internet Exchange Points (IXPs).  This approach
> >   aims to help the global Internet routing system's performance and
> >   help protect Route Server participants against misconfigurations."
> > 
> > Please give this document a read and consider if it should be adopted
> > for further work/use/revision/happy-fun-balling in our working-group.
> > 
> > Ideally we'll close this adoption call out 4/8/2024 (the 8th day of
> > the 4th month of the year 2 thousand and twenty 4)
> > 
> > Thanks!
> > -chris
> > co-chair N of M
> > 
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Call for agenda items for GROW @ IETF 119

[Job Snijders]

On Thu, Mar 07, 2024 at 10:42:26AM -0500, Jeffrey Haas wrote:
> On Mon, Jan 22, 2024 at 08:34:58PM +0100, Job Snijders wrote:
> > Dear GROW working group,
> > 
> > The IETF 119 meeting in Brisbane, "Down Under" is approaching!
> > 
> > Through this email we'd like to ask the GROW working group for agenda
> > items. We should have a 90 minute slot this time around.
> > 
> > Please email your presentation proposal to grow-cha...@ietf.org if you'd
> > like to present an update on an existing Internet-Draft, or would like
> > to bring new material to the working group for consideration.
> 
> A bit on the last minute side, but could we have a 5 minute slot made
> available to discuss draft-hmntsharma-bmp-tcp-ao?
> 
> TL;DR: BMP says TCP and maybe you can use ipsec.  Getting support stated in
> the RFC series for other transports is the goal of the discussion.
> 
> Hemant is new to IETF and won't be attending the upcoming session.  I've
> agreed to present for him to the working group and help him shepherd the
> draft if that's how the WG cares to move it forward.

Sure thing, done!

The latest version of the GROW agenda is here 
https://datatracker.ietf.org/doc/agenda-119-grow/

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-peer-up (start 22/Jan/2024 end 6/Feb/2024)

[Job Snijders]

Dear all,

The WGLC has concluded. A few people spoke out in favor of publication,
no objections were raised. I'll work on the shepherd write-up.

Thanks!

Kind regards,

Job

On Mon, Jan 22, 2024 at 08:20:36PM +0100, Job Snijders wrote:
> Dear all,
> 
> As requested during the IETF 118 GROW session in Prague, Czechia, a
> "Working Group Last Call" is now issued for draft-ietf-grow-bmp-peer-up.
> This phase will last about 2 weeks. We'd love to hear from you,
> especially from BMP implementers!
> 
> Please review the document, consider whether it should advance in the
> publication pipeline, and provide feedback! ... before February 6th,
> please :-) 
> 
> The abstract for draft-ietf-grow-bmp-peer-up:
> 
> """
> RFC 7854, BMP, uses different message types for different purposes.
> Most of these are Type, Length, Value (TLV) structured. One message
> type, the Peer Up message, lacks a set of TLVs defined for its use,
> instead sharing a namespace with the Initiation message. Subsequent
> experience has shown that this namespace sharing was a mistake, as
> it hampers the extension of the protocol.
> 
> This document updates RFC 7854 by creating an independent namespace
> for the Peer Up message. It also updates RFC 8671 and RFC 9069 by
> moving the defined codepoints in the newly introduced registry. The
> changes in this document are formal only, compliant implementations
> of RFC 7854, RFC 8671 and RFC 9069 also comply with this
> specification.
> """
> 
> The internet-draft itself and associated information are available at:
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-peer-up/
> 
> Kind regards,
> 
> Job
> GROW co-chair

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

[Job Snijders]

On Tue, Feb 06, 2024 at 09:11:12PM -0600, David Farmer wrote:
> If you keep it as updating RFC 7454, I believe you need to say it does
> so in the abstract. Also, somewhere in the document, probably in the
> introduction, you need to explain how it updates RFC 7454, that is how
> this document relates to RFC 7454.

Thanks David, that's how I understand the process too.

If the contents of draft-ietf-grow-as-path-prepending actually update
7454 (which currently doesn't seem the case), the working group has to
think about how that aligns with the 'big update' of 7454 happening in
https://datatracker.ietf.org/doc/draft-ietf-grow-bgpopsecupd/

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

[Job Snijders]

Dear Michael,

Perhaps a question was taken as a suggestion, but the draft doesn’t
describe how it updates either RFC.

Removing the updates section indeed is an option!

Kind regards,

Job

On Tue, 6 Feb 2024 at 21:09, Michael McBride 
wrote:

> Hi Job,
>
> That is based on a list comment from a few years ago:
>
> "Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
> Michael McBride  Fri, 19 March 2021 03:36
> UTCShow header
>
> >Is this going to update BCP194/RFC7454? I don't see any reference in the
> draft.
>
> We probably should. Good suggestion. I was thinking updating 8195 but 7454
> appears more appropriate.
>
> We will update the draft, based upon comments from last week, and add 7454
> unless we hear otherwise."
>
>
> We didn't hear otherwise. We can remove the updates section if it doesn't
> make sense.
>
> Thanks,
> mike
>
> -Original Message-
> From: Job Snijders 
> Sent: Tuesday, February 6, 2024 11:13 AM
> To: Michael McBride 
> Cc: grow@ietf.org
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt
>
> Dear Michael,
>
> Before we proceed, can you clarify how exactly
> draft-ietf-grow-as-path-prepending updates RFC 7454 and RFC 8195?
>
> In relationship to 8195, the only sentence I see is "AS Path Prepending is
> discussed in Use of BGP Large Communities [RFC8195]." - which is true
> (8915 contains an example about prepending once), however the rest of the
> text in draft-ietf-grow-as-path-prepending-10 doesn't seem an 'update' in
> IETF document logistics parlance?
>
> Kind regards,
>
> Job
>
> On Tue, Feb 06, 2024 at 06:23:13PM +, Michael McBride wrote:
> > Hello grow chairs,
> >
> > Any chance we can get a wglc started on this draft after this latest
> > round of edits? The authors have felt it's ready for quite some time.
> > It's going on four years now. Please consider.
> >
> > Thanks,
> > mike
> >
> >
> > -Original Message-
> > From: GROW  On Behalf Of Michael McBride
> > Sent: Tuesday, January 16, 2024 11:21 PM
> > To: Martin Pels ; grow@ietf.org
> > Subject: Re: [GROW] I-D Action:
> > draft-ietf-grow-as-path-prepending-09.txt
> >
> > Hi Martin,
> >
> > I just submitted a new version to address your (and Alejandro's)
> comments. See my comments in line (MM):
> >
> >
> > -Original Message-
> > From: GROW  On Behalf Of Martin Pels
> > Sent: Tuesday, January 9, 2024 1:00 AM
> > To: grow@ietf.org
> > Subject: Re: [GROW] I-D Action:
> > draft-ietf-grow-as-path-prepending-09.txt
> >
> > Hi,
> >
> > Some comments
> > -
> >
> > Section 3.1 and 4:
> > As has been mentioned before on this list, I think using the term "route
> leak" in this scenario is confusing. Something like "suboptimal" or
> "unintended" routing would be a better fit.
> >
> > MM: Done. Used both terms in place of route leak.
> >
> > 3.2 and 3.3:
> > These do not appear to be separate problems, but rather two examples of
> the same problem (a malicious, shorter route being preferred over a
> legitimate, prepended route).
> >
> > MM: I think it is ok to describe two similar problems.
> >
> > 7:
> > This only mentions the sending side. There is also security advice to be
> given to the accepting side (see section 3.5 and 3.6). Something like
> "Accepting routes with extremely long AS_PATHs may cause increased memory
> usage and possibly router crashes."
> >
> > MM: I inserted exactly that sentence.
> >
> > A reference to ASPA may also be useful in this section, since this could
> help mitigate the effects of the route leaks described in 3.2 and 3.3.
> >
> > MM: Good idea, I added a sentence on ASPA.
> >
> > Text nits
> > -
> >
> > Abstract:
> > AS_Path attribute -> AS_PATH attribute
> >
> > MM: Done
> >
> > multiple entries of an AS -> multiple entries of an ASN
> >
> > MM: Done
> >
> > This document provides guidance with -> This document provides
> > guidance for
> >
> > MM: Done
> >
> > 1:
> > the AS_PATH attribute which -> the AS_PATH attribute, which
> >
> > MM: Done
> >
> > 2:
> > today including -> today, including
> >
> > MM: Done
> >
> > 4:
> > more then 1 -> more than 1
> >
> > MM: Done
> >
> > Thank you! I also added you and Alejandro to the acknowledgements.
> > Mike

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt

[Job Snijders]

Dear Michael,

Before we proceed, can you clarify how exactly
draft-ietf-grow-as-path-prepending updates RFC 7454 and RFC 8195?

In relationship to 8195, the only sentence I see is "AS Path Prepending
is discussed in Use of BGP Large Communities [RFC8195]." - which is true
(8915 contains an example about prepending once), however the rest of
the text in draft-ietf-grow-as-path-prepending-10 doesn't seem an
'update' in IETF document logistics parlance?

Kind regards,

Job

On Tue, Feb 06, 2024 at 06:23:13PM +, Michael McBride wrote:
> Hello grow chairs,
> 
> Any chance we can get a wglc started on this draft after this latest
> round of edits? The authors have felt it's ready for quite some time.
> It's going on four years now. Please consider.
> 
> Thanks,
> mike
> 
> 
> -Original Message-
> From: GROW  On Behalf Of Michael McBride
> Sent: Tuesday, January 16, 2024 11:21 PM
> To: Martin Pels ; grow@ietf.org
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt
> 
> Hi Martin,
> 
> I just submitted a new version to address your (and Alejandro's) comments. 
> See my comments in line (MM):
> 
> 
> -Original Message-
> From: GROW  On Behalf Of Martin Pels
> Sent: Tuesday, January 9, 2024 1:00 AM
> To: grow@ietf.org
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt
> 
> Hi,
> 
> Some comments
> -
> 
> Section 3.1 and 4:
> As has been mentioned before on this list, I think using the term "route 
> leak" in this scenario is confusing. Something like "suboptimal" or 
> "unintended" routing would be a better fit.
> 
> MM: Done. Used both terms in place of route leak.
> 
> 3.2 and 3.3:
> These do not appear to be separate problems, but rather two examples of the 
> same problem (a malicious, shorter route being preferred over a legitimate, 
> prepended route).
> 
> MM: I think it is ok to describe two similar problems.
> 
> 7:
> This only mentions the sending side. There is also security advice to be 
> given to the accepting side (see section 3.5 and 3.6). Something like 
> "Accepting routes with extremely long AS_PATHs may cause increased memory 
> usage and possibly router crashes."
> 
> MM: I inserted exactly that sentence.
> 
> A reference to ASPA may also be useful in this section, since this could help 
> mitigate the effects of the route leaks described in 3.2 and 3.3.
> 
> MM: Good idea, I added a sentence on ASPA.
> 
> Text nits
> -
> 
> Abstract:
> AS_Path attribute -> AS_PATH attribute
> 
> MM: Done
> 
> multiple entries of an AS -> multiple entries of an ASN
> 
> MM: Done
> 
> This document provides guidance with -> This document provides guidance for
> 
> MM: Done
> 
> 1:
> the AS_PATH attribute which -> the AS_PATH attribute, which
> 
> MM: Done
> 
> 2:
> today including -> today, including
> 
> MM: Done
> 
> 4:
> more then 1 -> more than 1
> 
> MM: Done
> 
> Thank you! I also added you and Alejandro to the acknowledgements.
> Mike
> 
> 
> 
> Kind regards,
> Martin
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 119

[Job Snijders]

Dear GROW working group,

The IETF 119 meeting in Brisbane, "Down Under" is approaching!

Through this email we'd like to ask the GROW working group for agenda
items. We should have a 90 minute slot this time around.

Please email your presentation proposal to grow-cha...@ietf.org if you'd
like to present an update on an existing Internet-Draft, or would like
to bring new material to the working group for consideration.

We already noted a slot request for draft-ramseyer-grow-peering-api.

Hope to see you all in Brisbane, the capital of Queensland!

Kind regards,

Job & Chris
GROW co-chairs


   .'\   /`..'\   /\.
 .'.-.`-'.-.`..'.-.`-'.-.`.
..._:   .-. .-.   :_...  ..._:   .-. .-.   :_...
  .''-.( o) ( o).-'`.  .''-.(o ) (o ).-'`.
 :  __ _`~(_)~`_ __  ::  __ _`~(_)~`_ __  :
:  /:   ' .-=_   _=-. `   ;\  :  :  /:   ' .-=_   _=-. `   ;\  :
:   :|-.._  ' `  _..-|:   :  :   :|-.._  ' `  _..-|:   :
 :   `:| |`:-:-.-:-:'| |:'   ::   `:| |`:-:-.-:-:'| |:'   :
  `.   `.| | | | | | |.'   .'  `.   `.| | | |   | |.'   .'
`.   `-:_| | |_:-'   .'  `.   `-:_| | ._:-'   .'
 jgs  `-._   _.-'  `-._   _.-'
  ``---''  ``---''

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Last Call (WGLC) for draft-ietf-grow-bmp-peer-up (start 22/Jan/2024 end 6/Feb/2024)

[Job Snijders]

Dear all,

As requested during the IETF 118 GROW session in Prague, Czechia, a
"Working Group Last Call" is now issued for draft-ietf-grow-bmp-peer-up.
This phase will last about 2 weeks. We'd love to hear from you,
especially from BMP implementers!

Please review the document, consider whether it should advance in the
publication pipeline, and provide feedback! ... before February 6th,
please :-) 

The abstract for draft-ietf-grow-bmp-peer-up:

"""
RFC 7854, BMP, uses different message types for different purposes.
Most of these are Type, Length, Value (TLV) structured. One message
type, the Peer Up message, lacks a set of TLVs defined for its use,
instead sharing a namespace with the Initiation message. Subsequent
experience has shown that this namespace sharing was a mistake, as
it hampers the extension of the protocol.

This document updates RFC 7854 by creating an independent namespace
for the Peer Up message. It also updates RFC 8671 and RFC 9069 by
moving the defined codepoints in the newly introduced registry. The
changes in this document are formal only, compliant implementations
of RFC 7854, RFC 8671 and RFC 9069 also comply with this
specification.
"""

The internet-draft itself and associated information are available at:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-peer-up/

Kind regards,

Job
GROW co-chair

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peering API: Internet Draft submission

[Job Snijders]

On Wed, Jan 17, 2024 at 09:08:00PM +, Jenny Ramseyer wrote:
> I would like to request a talking slot at the upcoming GROW meeting at
> IETF 119 to discuss the draft.  Please let me know if you think this
> draft might meet your charter, and if it would be possible to discuss
> at the next GROW meeting.

I've added a talking slot for you to the agenda for the next meeting!

Kind regards,

Job
GROW co-chair

___
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 Snijders]

On Mon, Jan 08, 2024 at 10:44:26AM +0100, Job Snijders wrote:
> Dear Working Group,
> 
> Thank you all for your comments and feedback. The
> draft-fiebig-grow-bgpopsecupd document has been adopted by the GROW
> working group.


Apologies, the above sentence should of course read "The
draft-pels-grow-yang-bgp-communities document has been adopted by the
GROW working group".

- Job



> 
> Martin, please re-submit as 'draft-ietf-grow-yang-bgp-communities-00'
> 
> Kind regards,
> 
> Job
> GROW co-chair
> 
> 
> On Wed, Dec 06, 2023 at 04:42:05PM +0100, Job Snijders wrote:
> > 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.
> > 
> > Kind regards,
> > 
> > Job / Chris
> > GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Job Snijders]

Dear Working Group,

Thank you all for your comments and feedback. The
draft-msri-grow-bmp-bgp-rib-stats document has been adopted by the GROW
working group.

Mukul, please re-submit as 'draft-ietf-grow-bmp-bgp-rib-stats-00'

Additionally, we can work on IANA Early Allocation for codepoints.

Kind regards,

Job
GROW co-chair


On Wed, Dec 06, 2023 at 04:48:32PM +0100, Job Snijders wrote:
> Dear GROW,
> 
> The author of draft-msri-grow-bmp-bgp-rib-stats 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: Definition For New BMP Statistics Type
> Abstract:
>   RFC 7854 defined different BMP statistics messages types to observe
>   interesting events that occur on the router.  This document updates
>   RFC 7854 by adding new statistics type. 
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.html
> 
> *** NOTE *** This draft has nothing other than BMP code point requests
> for counters. If adoption fails, the authors can go off an request FCFS
> instead.
> 
> 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.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs

___
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 Snijders]

Dear Working Group,

Thank you all for your comments and feedback. The
draft-fiebig-grow-bgpopsecupd document has been adopted by the GROW
working group.

Martin, please re-submit as 'draft-ietf-grow-yang-bgp-communities-00'

Kind regards,

Job
GROW co-chair


On Wed, Dec 06, 2023 at 04:42:05PM +0100, Job Snijders wrote:
> 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.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs

___
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)

[Job Snijders]

Dear Working Group,

Thank you all for your comments and feedback. The
draft-fiebig-grow-bgpopsecupd document has been adopted by the GROW
working group.

Tobias, please re-submit as 'draft-ietf-grow-bgpopsecupd-00'

Kind regards,

Job
GROW co-chair

On Wed, Dec 06, 2023 at 04:45:20PM +0100, Job Snijders wrote:
>  Wed, Dec 06, 2023 at 04:42:05PM +0100, Job Snijders wrote:
> Dear GROW,
> 
> The author of draft-fiebig-grow-bgpopsecupd 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: Updated BGP Operations and Security
> Abstract:
>   The Border Gateway Protocol (BGP) is the protocol almost exclusively
>   used in the Internet to exchange routing information between network
>   domains. Due to this central nature, it is important to understand the
>   security and reliability measures that can and should be deployed to
>   prevent accidental or intentional routing disturbances.
>   ... [abstract snipped for brevity] ...
> 
> This internet-draft aims to update RFC7454 / BCP 194.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-fiebig-grow-bgpopsecupd-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.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs

___
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 Snijders]

Dear Tom,

Did you watch the presentation on this topic in the IETF 118 GROW
session? https://youtu.be/vkU8qYzSt1c?si=zWKpMPfo0kW0DUgv=262

Kind regards,

Job

On Wed, Dec 06, 2023 at 05:05:53PM +, tom petch wrote:
> From: GROW  on behalf of Job Snijders 
> 
> Sent: 06 December 2023 15:42
> 
> 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.
> 
> 
> 
> Well, no, it is not aYANG module and I am not clear why it should be.
> 
> It is a data model that uses some of the constructs of RFC7950 but then 
> re-invents the wheel where the YANG community has already provided additional 
> data types for common types that appear in the work of the IETF.
> 
> A YANG data model is for operations, management, monitoring and I do not see 
> why and when such actions are needed for a BGP community.
> 
> I do not see a problem for which this is a solution; I wonder if those 
> reading this I-D will each project their own specific ideas onto this model 
> rendering it difficult, impossible even, to converge on a specific solution.
> 
> Tom Petch
> 
> 
> 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.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Job Snijders]

Dear GROW,

The author of draft-msri-grow-bmp-bgp-rib-stats 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: Definition For New BMP Statistics Type
Abstract:
  RFC 7854 defined different BMP statistics messages types to observe
  interesting events that occur on the router.  This document updates
  RFC 7854 by adding new statistics type. 

The Internet-Draft can be found here:
https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.html

*** NOTE *** This draft has nothing other than BMP code point requests
for counters. If adoption fails, the authors can go off an request FCFS
instead.

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.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

[Job Snijders]

 Wed, Dec 06, 2023 at 04:42:05PM +0100, Job Snijders wrote:
Dear GROW,

The author of draft-fiebig-grow-bgpopsecupd 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: Updated BGP Operations and Security
Abstract:
  The Border Gateway Protocol (BGP) is the protocol almost exclusively
  used in the Internet to exchange routing information between network
  domains. Due to this central nature, it is important to understand the
  security and reliability measures that can and should be deployed to
  prevent accidental or intentional routing disturbances.
  ... [abstract snipped for brevity] ...

This internet-draft aims to update RFC7454 / BCP 194.

The Internet-Draft can be found here:
https://www.ietf.org/archive/id/draft-fiebig-grow-bgpopsecupd-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.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for draft-pels-grow-yang-bgp-communities (start 06/Dec/2023 end 06/Jan/2024)

[Job Snijders]

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.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel (start 25/Oct/2023 end 08/Nov/2023)

[Job Snijders]

Dear all,

This document has been adopted by the Working Group.

Authors, please submit the document as 'draft-ietf-grow-bmp-rel-00'

Kind regards,

Job

On Wed, Oct 25, 2023 at 12:57:08AM +0200, Job Snijders wrote:
> Dear GROW,
> 
> The authors of draft-lucente-grow-bmp-rel asked whether GROW
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: Logging of routing events in BGP Monitoring Protocol (BMP)
> Abstract:
>   The BGP Monitoring Protocol (BMP) does provision for BGP session event
>   logging (Peer Up, Peer Down), state synchronization (Route
>   Monitoring), debugging (Route Mirroring) and Statistics messages,
>   among the others. This document defines a new Route Event Logging
>   (REL) message type for BMP with the aim of covering use-cases with
>   affinity to alerting, reporting and on-change analysis.
> 
> The Internet-Draft can be found here:
> https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-rel/
> 
> 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 November 8th, 2023.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear Maximilian,

On Sun, Nov 26, 2023 at 02:45:58PM +0100, Maximilian Wilhelm wrote:
> Anno domini 2023 Maximilian Wilhelm scripsit:
> 
> [...]
> > Some time has past and I don't see any new comments, neither here nor
> > to us authors.
> >
> > Hence I'd like to ask the chairs to start the WG Last Call.
> 
> I believe this didn't happen so far, or did I miss it? :)
> 
> So I'd like to ask to start the WG Last Call, or, if there is no
> interest in getting this into an RFC, to call that out. :)

Thanks for the poke

Looking back I see two messages with comments that probably need
addressing:

https://mailarchive.ietf.org/arch/msg/grow/5iJ-QpjcPXOwIGhuOQMKn_FYQQc/
https://mailarchive.ietf.org/arch/msg/grow/cdlMR2A0-gHqDwIf-UNkBvqVixw/

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] todo items from GROW @ IETF 118

[Job Snijders]

Dear all,

The todo items I noted for myself:

IETF 119: request 90 minutes
Call for working group adoption: draft-pels-grow-yang-bgp-communities
Call for working group adoption: draft-fiebig-grow-bgpopsecupd
Call for working group adoption: draft-msri-grow-bmp-bgp-rib-stats
Last Call: draft-ietf-grow-bmp-peer-up

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] draft agenda for GROW @ IETF 118 posted

[Job Snijders]

Dear all,

The draft agenda for the GROW @ IETF 118 session has been uploaded here:
https://datatracker.ietf.org/doc/agenda-118-grow/

Let me know if we forgot someone or something, there still is some room.

Kind regards,

Job & Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 118

[Job Snijders]

Dear GROW working group,

The IETF 118 meeting is approaching!

Through this email we'd like to ask the GROW working group for agenda
items.

Please email your presentation proposal to grow-cha...@ietf.org if you'd
like to present an update on an existing Internet-Draft, or would like
to bring new material to the working group for consideration.

Hope to see you all in Prague, the capital city of the Czech Republic!

Kind regards,

Job & Chris
GROW co-chairs

   .   ,.
  T."-._..---.._,-"/|
  l|"-.  _.v._   (" |
  [l /.'_ \; _~"-.`-t
  Y " _(o} _{o)._ ^.|
  j  T  ,--.  T  ]
  \  l ( /-^-\ ) !  !
   \. \.  "~"  ./  /c-..,__
 ^r- .._ .- .-"  `- .  ~"--.
  > \.  \
  ]   ^. \
  3  .  ">.   Y  -Row
 ,.__.--._   _j   \ ~   . ;   |
(~"-._~"^._\   ^.^._  I . l
 "-._ ___ ~"-,_7.Z-._   7"   Y  ;  \_
/"   "~-(r r  _/_--._~-//  /,.--^-._   / Y
"-._'"~~~>-._~]>--^---./,.^~^.^  !
~--._'   Y---.\./
 ~~--._  l_   )\
   ~-._~~~---._,..---   \
   ~"~   \
  \/\
   )  ( ')
  (  /  )
 jgs   \(__)|

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] TODO Items from F2F meeting

[Job Snijders]

Dear all,

I believe all todo items have been cleared now:

On Tue, Jul 25, 2023 at 04:43:01PM -0700, Christopher Morrow wrote:
> * note about BMP and TLV and how lovely the new world will be

I received word that potential concerns with bumping the version number
have been addressed and that bumping version is an acceptable outcome by
all involved. If somehow you as an implementer were missed in the survey
and you *do* have concerns with the version bump - please speak up! For
now I will operate under the assumption there is working group consensus
on this particular question.

> * note about WG Adoption for BGP Events in BMP

Done: https://mailarchive.ietf.org/arch/msg/grow/9Nsa4zN4mzuTbgl1rbggnhwJFC4/

> * adoption call for loc-peer

Done: https://mailarchive.ietf.org/arch/msg/grow/IrfEI4s-37iceNQyzSwRlmD6vb8/

Kind regards,

Job
GROW co-chair

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for Adoption draft-lucente-grow-bmp-rel (start 25/Oct/2023 end 08/Nov/2023)

[Job Snijders]

Dear GROW,

The authors of draft-lucente-grow-bmp-rel asked whether GROW
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: Logging of routing events in BGP Monitoring Protocol (BMP)
Abstract:
  The BGP Monitoring Protocol (BMP) does provision for BGP session event
  logging (Peer Up, Peer Down), state synchronization (Route
  Monitoring), debugging (Route Mirroring) and Statistics messages,
  among the others. This document defines a new Route Event Logging
  (REL) message type for BMP with the aim of covering use-cases with
  affinity to alerting, reporting and on-change analysis.

The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-rel/

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 November 8th, 2023.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for Adoption draft-francois-grow-bmp-loc-peer (start 24/Oct/2023 end 07/Nov/2023)

[Job Snijders]

Dear GROW,

The authors of draft-francois-grow-bmp-loc-peer asked whether GROW
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: BMP Loc-RIB: Peer address
Abstract:
   BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path
   information to zero.  This document introduces the option to
   communicate the actual peer from which a path was received when
   advertising that path with BMP Loc-RIB.

The Internet-Draft can be found here:
https://datatracker.ietf.org/doc/draft-francois-grow-bmp-loc-peer/

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends November 7th, 2023.

Kind regards,

Job / Chris
GROW co-chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-registries-change-04.txt

[Job Snijders]

On Fri, Sep 22, 2023 at 03:46:50PM +, John Scudder wrote:
> This version removes "BMP Peer Down Reason Codes” from the list of
> affected registries, per Tom Petch’s IETF LC review.

Thanks, good catch.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Publication has been requested for draft-ietf-grow-bmp-registries-change-03

[Job Snijders via Datatracker]

Job Snijders has requested publication of 
draft-ietf-grow-bmp-registries-change-03 as Proposed Standard on behalf of the 
GROW working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change/


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-registries-change (ends 2019.06.12)

[Job Snijders]

Hi John,

Are you aware of any IPR related to this Internet-Draft?

Kind regards,

Job

On Wed, Aug 16, 2023 at 07:29:25PM +, John Scudder wrote:
> Jeff just reminded me about this. I see that although it passed WGLC it never 
> got put into PubReq, and I forgot all about it, mea culpa. I’ve just version 
> bumped it, I’d appreciate if one of the chairs would push the PubReq button 
> (or whatever else you deem suitable to do next).
> 
> Thanks,
> 
> —John
> 
> > On Jul 11, 2019, at 11:29 PM, Christopher Morrow 
> >  wrote:
> > 
> > With overwhelmingly positive response, let's move this forward!
> > I'll see about sending the IESG bits forward in the next day.
> > 
> > Thanks!
> > -chris
> > 
> > On Wed, May 22, 2019 at 1:25 PM Job Snijders  wrote:
> >> 
> >> Dear GROW,
> >> 
> >> We have a fairly short procedural document to consider for publication.
> >> As suggested in the working group meeting in Prague,
> >> draft-ietf-grow-bmp-registries-change may ready for last call. The last
> >> call will be ~ 2 weeks, ending June 12th, 2018.
> >> 
> >> Abstract:
> >> 
> >>This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
> >>making a change to the registration procedures for several
> >>registries. Specifically, any BMP registry with a range of
> >>32768-65530 designated "Specification Required" has that range re-
> >>designated as "First Come First Served".
> >> 
> >> The document information is available at:
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM=hiF3YdrDQkVvKOBhpXp-lwo9LMS3K917rWD5XqRnyiU=
> >>  
> >> HTML: 
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM=UtFIov2lb8rHJhzfKNMPGgCc0b-eRXk0QHHYLLoP0Bw=
> >>  
> >> 
> >> Please review the document and provide feedback.
> >> 
> >> Kind regards,
> >> 
> >> Job & Chris
> >> co-chairs GROW
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] working group last call draft-ietf-grow-bmp-registries-change (ends 2019.06.12)

[Job Snijders]

Dear John,

I’ll take a look soon to see where we are in the process on this one.
Thanks for the inquiry!

Kind regards,

Job

On Wed, 16 Aug 2023 at 21:29, John Scudder 
wrote:

> Jeff just reminded me about this. I see that although it passed WGLC it
> never got put into PubReq, and I forgot all about it, mea culpa. I’ve just
> version bumped it, I’d appreciate if one of the chairs would push the
> PubReq button (or whatever else you deem suitable to do next).
>
> Thanks,
>
> —John
>
> > On Jul 11, 2019, at 11:29 PM, Christopher Morrow <
> christopher.mor...@gmail.com> wrote:
> >
> > With overwhelmingly positive response, let's move this forward!
> > I'll see about sending the IESG bits forward in the next day.
> >
> > Thanks!
> > -chris
> >
> > On Wed, May 22, 2019 at 1:25 PM Job Snijders  wrote:
> >>
> >> Dear GROW,
> >>
> >> We have a fairly short procedural document to consider for publication.
> >> As suggested in the working group meeting in Prague,
> >> draft-ietf-grow-bmp-registries-change may ready for last call. The last
> >> call will be ~ 2 weeks, ending June 12th, 2018.
> >>
> >> Abstract:
> >>
> >>This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
> >>making a change to the registration procedures for several
> >>registries. Specifically, any BMP registry with a range of
> >>32768-65530 designated "Specification Required" has that range re-
> >>designated as "First Come First Served".
> >>
> >> The document information is available at:
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM=hiF3YdrDQkVvKOBhpXp-lwo9LMS3K917rWD5XqRnyiU=
> >> HTML:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dgrow-2Dbmp-2Dregistries-2Dchange=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=hLt5iDJpw7ukqICc0hoT7A=spxqouZ6rnT4gK41cN_Tfc5z3i-H2xXtN2SQkEGA_xM=UtFIov2lb8rHJhzfKNMPGgCc0b-eRXk0QHHYLLoP0Bw=
> >>
> >> Please review the document and provide feedback.
> >>
> >> Kind regards,
> >>
> >> Job & Chris
> >> co-chairs GROW
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 117

[Job Snijders]

Dear GROW working group,

The IETF 117 meeting is approaching!

Through this email we'd like to ask the GROW working group for agenda
items.

Please email your proposal to grow-cha...@ietf.org if you'd like to
present an update on an existing Internet-Draft, or would like to bring
new material to the working group for consideration.

Hope to see you all in San Francisco, United States of America!

Kind regards,

Job & Chris
GROW Chairs


 * ,MMM8&&&.*
  88&.
 88&&&
 *   MMM88
 MMM88
 'MMM88&&'
   'MMM8&&&'  *_
  |\___/|  \\
 =) ^Y^ (=   |\_/|  ||'
  \  ^  /)a a '._.--.  //
   )=*=(=\T_= /~  ~  \//
  / \ `"`\   ~   / ~  /
  | | |~   \ |  ~/
 /| | | |\ \  ~/- \ ~\
 \| | |_|/||| |  // /`
  jgs_/\_//_// __//\_/\_/\_((_|\((_//\_/\_/\_
  |  |  |  | \_) |  |  |  |  |  |  |  |  |  |
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for Adoption draft-cppy-grow-bmp-path-marking-tlv (start 30/Mar/2023 end 21/Apr/2023)

[Job Snijders]

Dear GROW,

It seems there is good support to adopt
draft-cppy-grow-bmp-path-marking-tlv as working group document.

Thank you all for your responses.

Authors, please upload the file as draft-ietf-grow-bmp-path-marking-tlv-00

Kind regards,

Job

On Thu, Mar 30, 2023 at 04:35:32AM +, Job Snijders wrote:
> Dear GROW,
> 
> The authors of draft-cppy-grow-bmp-path-marking-tlv asked whether GROW
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: BMP Extension for Path Status TLV
> Abstract: 
>   The BGP Monitoring Protocol (BMP) provides an interface for obtaining
>   BGP Path information. BGP Path Information is conveyed within BMP Route
>   Monitoring (RM) messages. This document proposes an extension to BMP to
>   convey the status of a path after being processed by the BGP process.
>   This extension makes use of the TLV mechanims described in
>   draft-ietf-grow-bmp-tlv and draft-ietf-grow-bmp-tlv-ebit.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-cppy-grow-bmp-path-marking-tlv-12.html
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends April 21th, 2023.
> 
> Kind regards,
> 
> Job / Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Technical Errata Reported] RFC6774 (7527)

[Job Snijders]

On Thu, Jun 01, 2023 at 01:43:42PM -0700, Chris Smiley wrote:
> Greetings,
> 
> FYI - this report has been deleted as junk.

Thanks!

Kind regards,

Job
co-chair GROW

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

On Sat, May 27, 2023 at 08:43:59PM +0200, Maximilian Wilhelm wrote:
> Anno domini 2022 Job Snijders scripsit:
> 
> > Thank you for your feedback! There was good support to adopt this
> > internet-draft and continue work on it as a working group document.
> > 
> > Authors, please name the internet-draft 
> > "draft-ietf-grow-anycast-community-00"
> > and submit it to https://datatracker.ietf.org/submit/
> 
> It looks like the expiration date of this draft is coming up.
> 
> I've seen quite some support for this here so it was adopted as a WG
> document. Since then there wasn't much chatter about it and the
> comments which came up have been addressed. Which leads me to the
> questions: What needs to happen so this can become an RFC? :)

The next step in this process is "Working Group Last Call", a period of
time in which members of this working group can comment on the
internet-draft's comments (before its send onwards to wider review).

Before we do that, I have some remarks:

Section 3.2 "Accepting and honoring the ANYCAST community" ... it might
not be clear to a novice reader what exactly 'accepting and honoring'
means.

Also in section 3.2: "if it is received by a network that is not using it"
what does "using it" mean exactly?

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Minutes GROW @ IETF 116 published

[Job Snijders]

Hi folks!

The minutes have been published:
https://datatracker.ietf.org/doc/minutes-116-grow-202303300400/

Many thanks to Peter Schoenmaker and Zhen Tan for observing the session
and taking minutes!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Call for Adoption draft-cppy-grow-bmp-path-marking-tlv (start 30/Mar/2023 end 21/Apr/2023)

[Job Snijders]

Dear GROW,

The authors of draft-cppy-grow-bmp-path-marking-tlv asked whether GROW
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: BMP Extension for Path Status TLV
Abstract: 
  The BGP Monitoring Protocol (BMP) provides an interface for obtaining
  BGP Path information. BGP Path Information is conveyed within BMP Route
  Monitoring (RM) messages. This document proposes an extension to BMP to
  convey the status of a path after being processed by the BGP process.
  This extension makes use of the TLV mechanims described in
  draft-ietf-grow-bmp-tlv and draft-ietf-grow-bmp-tlv-ebit.

The Internet-Draft can be found here:
https://www.ietf.org/archive/id/draft-cppy-grow-bmp-path-marking-tlv-12.html

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends April 21th, 2023.

Kind regards,

Job / Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Call for agenda items for GROW @ IETF 116

[Job Snijders]

Dear all,

Just a reminder that we need to work on finalizing the agenda! Please
send grow-cha...@ietf.org requests for a slot during the IETF 116
GROW meeting!

Kind regards,

Job

On Thu, Feb 23, 2023 at 02:36:47PM +0100, Job Snijders wrote:
> Dear GROW working group,
> 
> The IETF 116 meeting is approaching!
> 
> We'd like to ask the GROW working group for agenda items.
> 
> Please email your proposal to grow-cha...@ietf.org if you'd like to
> present an update on an existing Internet-Draft, or would like to bring
> new material to the working group for consideration.
> 
> Hope to see you all in Yokohama, Japan!
> 
> Kind regards,
> 
> Job & Chris
> GROW Chairs
> 
>/^-^\ /^-^\
>   / o o \V  o o  V
>  /   Y   \|  Y  |
>  V \ v / V \ Q /
>/ - \   / - \
>   /|   |\
> (/ |   | \ )
>  ===/___) ||   || (___\

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 116

[Job Snijders]

Dear GROW working group,

The IETF 116 meeting is approaching!

We'd like to ask the GROW working group for agenda items.

Please email your proposal to grow-cha...@ietf.org if you'd like to
present an update on an existing Internet-Draft, or would like to bring
new material to the working group for consideration.

Hope to see you all in Yokohama, Japan!

Kind regards,

Job & Chris
GROW Chairs

   /^-^\ /^-^\
  / o o \V  o o  V
 /   Y   \|  Y  |
 V \ v / V \ Q /
   / - \   / - \
  /|   |\
(/ |   | \ )
 ===/___) ||   || (___\

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Invite comments on updated AS_SET deprecation draft

[Job Snijders]

Dear Jeff,

On Sun, Jan 29, 2023 at 08:28:27AM -0500, Jeffrey Haas wrote:
> On Sun, Jan 29, 2023 at 11:26:02AM +0100, Job Snijders wrote:
> > On Wed, Jan 25, 2023 at 05:17:08PM +, Sriram, Kotikalapudi (Fed) wrote:
> > > Please let us also know if you would have interest in providing an
> > > implementation.
> > 
> > Perhaps it is worthwhile adding a suggestion to the document for BGP
> > stack vendors to make it super easy to reject BGP routes that contain an
> > AS_SET anywhere in the AS_PATH?
> 
> That's intended to be covered by the first paragraph of section 3:
> : BGP speakers conforming to this document (i.e., conformant BGP speakers)
> : SHOULD NOT locally generate BGP UPDATE messages containing AS_SETs or
> : AS_CONFED_SETs. Conformant BGP speakers SHOULD NOT send BGP UPDATE messages
> : containing AS_SETs or AS_CONFED_SETs. Upon receipt of such messages,
> : conformant BGP speakers SHOULD use the "treat-as-withdraw" error handling
> : behavior as per [RFC7606].

Thanks for highlighting that section, that's the gist of it in terms of
desired outcome, (and why I'd be in favor of progressing this document).

> I know you want to say "add a knob", but we generally try to avoid talking
> about the knobs in IDR specs.

Understandably. I can see how the suggestion is somewhat superfluous.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Invite comments on updated AS_SET deprecation draft

[Job Snijders]

Dear Sriram, others,

(speaking as working group participant)

On Wed, Jan 25, 2023 at 05:17:08PM +, Sriram, Kotikalapudi (Fed) wrote:
> Please let us also know if you would have interest in providing an
> implementation.

Perhaps it is worthwhile adding a suggestion to the document for BGP
stack vendors to make it super easy to reject BGP routes that contain an
AS_SET anywhere in the AS_PATH?

Modern versions of OpenBGPD have a single 'global' knob to reject BGP
routes with AS_SETs: https://man.openbsd.org/bgpd.conf#reject
As draft-ietf-idr-deprecate-as-set-confed-set progresses towards
publication, I think it'll make sense to change the default setting to
become 'reject routes with AS_SETs'.

I imagine operators would benefit from availability of similar knobs in
other BGP implementations too.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear Maximilian,

On Sat, Nov 26, 2022 at 11:17:06PM +0100, Maximilian Wilhelm wrote:
> thanks for the support!
> 
> I re-uploaded the draft with the updated name.
> 
> Chairs, I heard there is an option to ask for an early allocation for
> a community? I have to admit that I'm not deeply familar with the
> process here, 

RFC 7120 section 2 outlines the conditions for IANA Early Allocation
https://www.rfc-editor.org/rfc/rfc7120.html

I'm not entirely sure the semantics, processing, and other rules for
ANYCAST are entirely clear yet (condition B), which in turn impacts
condition C. I'm open to hear the case though! What would be the
motivation to allocate a value prior to RFC publication?

> I have however a favorite value in mind which I would love to see for
> this in the hope this ID one day becomes an RFC :)

Oh dear... the deadly sin of number vanity :)
What's your favorite number value?

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear all,

Thank you for your feedback! There was good support to adopt this
internet-draft and continue work on it as a working group document.

Authors, please name the internet-draft "draft-ietf-grow-anycast-community-00"
and submit it to https://datatracker.ietf.org/submit/

Kind regards,

Job

GROW co-chair

On Sat, Nov 05, 2022 at 03:48:16PM +0100, Job Snijders wrote:
> Dear GROW,
> 
> The authors of draft-wilhelm-grow-anycast-community asked whether this
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: A well-known BGP community to denote prefixes used for Anycast
> Abstract: 
>In theory routing decisions on the Internet and by extension within
>ISP networks should always use hot-potato routing to reach any given
>destination.  In reality operators sometimes choose to not use the
>hot-potato paths to forward traffic due to a variety of reasons,
>mostly motivated by traffic engineering considerations.  For prefixes
>carrying anycast traffic in virtually all situations it is advisable
>to stick to the hot-potato principle.  As operators mostly don't know
>which prefixes are carrying unicast or anycast traffic, they can't
>differentiate between them in their routing policies.
> 
>To allow operators to take well informed decisions on which prefixes
>are carrying anycast traffic this document proposes a well-known BGP
>community to denote this property.
> 
> The Internet-Draft can be found here: 
> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends November 22th, 2022.
> 
> Kind regards,
> 
> Job / Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 15/Sep/2022)

[Job Snijders]

Dear all,

There was good support to adopt this draft as working group document.
Thank you all for your input.

Authors - please upload a -00 version named "draft-ietf-grow-bmp-yang-00"
and I'll approve it and link it to the previous individual submission.
Thanks!

Kind regards,

Job

On Thu, Aug 25, 2022 at 04:20:18PM +0200, Job Snijders wrote:
> Hi GROW,
> 
> At the IETF 114 GROW session Paolo asked whether this working group
> could consider adoption for draft-cptb-grow-bmp-yang.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: BMP YANG Module
> Abstract: 
>This document proposes a YANG module for BMP (BGP Monitoring
>Protocol) configuration and monitoring. A complementary RPC triggers
>a refresh of the session of a BMP station.
> 
> The Internet-Draft can be found here: 
> https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends September 15th, 2022.
> 
> Kind regards,
> 
> Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Adoption Call: draft-wilhelm-grow-anycast-community (Ends 22/Nov/2022)

[Job Snijders]

Dear GROW,

The authors of draft-wilhelm-grow-anycast-community asked whether this
working group could consider adoption of the internet-draft.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: A well-known BGP community to denote prefixes used for Anycast
Abstract: 
   In theory routing decisions on the Internet and by extension within
   ISP networks should always use hot-potato routing to reach any given
   destination.  In reality operators sometimes choose to not use the
   hot-potato paths to forward traffic due to a variety of reasons,
   mostly motivated by traffic engineering considerations.  For prefixes
   carrying anycast traffic in virtually all situations it is advisable
   to stick to the hot-potato principle.  As operators mostly don't know
   which prefixes are carrying unicast or anycast traffic, they can't
   differentiate between them in their routing policies.

   To allow operators to take well informed decisions on which prefixes
   are carrying anycast traffic this document proposes a well-known BGP
   community to denote this property.

The Internet-Draft can be found here: 
https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends November 22th, 2022.

Kind regards,

Job / Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 15/Sep/2022)

[Job Snijders]

Hi GROW,

At the IETF 114 GROW session Paolo asked whether this working group
could consider adoption for draft-cptb-grow-bmp-yang.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title: BMP YANG Module
Abstract: 
   This document proposes a YANG module for BMP (BGP Monitoring
   Protocol) configuration and monitoring. A complementary RPC triggers
   a refresh of the session of a BMP station.

The Internet-Draft can be found here: 
https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends September 15th, 2022.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] a quick reminder about large communities and "well known"

[Job Snijders]

On Thu, Jul 28, 2022 at 05:59:36PM -0400, Jeffrey Haas wrote:
> [In the context of the anycast community at-mic discussion during IETF-114]
> 
> Grow WG,
> 
> As part of the RFC process for Large BGP Communities, there was strong
> objection to having any large communities set aside for special purposes.  
> 
> As a result of this, there are no designated ASes that are part of the
> rather large deployment of BGP code that understands these communities for
> "magic numbers" that is typical of various implementations for well known
> communities.
> 
> While there has been a few attempts to start discussion about designating
> well known large communities, the above point means there is a fair amount
> of resistance to the idea and inertia to overcome in IDR.
> 
> Extended Communities, if they can hold the data in question, are effectively
> free.  Feel free to grab them at whim!
> 
> -- Jeff (speaking partially as IDR chair and minimally as an IDR historian)

Yes. Especially if the objective is to signal the 'community setting
AS'; extended communities are an appropriate tool as they have
sufficient room for both 16-bit and 32-bit ASNs. Thanks for the
reminder, Jeff! :-)

A question to the working group: is signaling the 'sending ASN' a
critical characteristic of the concept outlined in the anycast-community
draft?

If not, a simple RFC 1997 well-known community is probably more suitable.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Preparations for Today's Meeting

[Job Snijders]

On Thu, Jul 28, 2022 at 03:16:24PM -0400, Christopher Morrow wrote:
> On Thu, Jul 28, 2022 at 9:02 AM Christopher Morrow 
> christopher.mor...@gmail.com> wrote:
> > Howdy folks!
> > If you have a presentation slot, ideally know this already...
> > Ideally you ALSO have prepared slides?
> >
> > If so, please email these supposed 'slides' to the chairs, prior to 2pm
> > Eastern US time.
> >
> >
> It's past 2pm.
> There were no slides provided
> 
> Gonna be a quick meeting I guess?

Hmmm, I received the ANYCAST slides via the grow-chairs@ alias last
night. Perhaps the dog is eating your emails? :-)

I've uploaded the materials, I think we are all set now.

See y'all in about an hour!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

[Job Snijders]

Dear Alexander, others,

On Tue, Jul 26, 2022 at 04:14:36PM +0300, Alexander Azimov wrote:
> The current version of the draft follows the wording from
> draft-ietf-idr-deprecate-as-set-confed-set
> 
>BGP speakers conforming to this document (i.e., conformant BGP
>speakers) MUST NOT locally generate BGP UPDATE messages containing
>AS_SET or AS_CONFED_SET.  Conformant BGP speakers SHOULD NOT send BGP
>UPDATE messages containing AS_SET or AS_CONFED_SET.  Upon receipt of
>such messages, conformant BGP speakers SHOULD use the "Treat-as-
>withdraw" error handling behavior as per [RFC7606
> ].
> 
> 
> As you can see, it uses 'SHOULD'. And this was the reason to have an
> additional 'Unverifiable' state, because the 'Invalid' routes MUST be
> rejected.

Ultimately it is up to network operators whether they deploy routing
policy that reject ASPA-Invalid routes.

What's important here is to mark routes that contain an AS_SET in the
AS_PATH as 'Invalid' when performing ASPA verification.

> If the WG agrees to change normalative language from 'SHOULD' to
> 'MUST', the ASPA document will follow.

I don't see that dependency; however there seems to be good consensus to
remove the "Unverifiable" state from the Internet-Draft and instead mark
routes as "Invalid" if an AS_SET is encountered anywhere in the AS_PATH.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

[Job Snijders]

Dear Sriram,

On Thu, 21 Jul 2022 at 14:08, Sriram, Kotikalapudi (Fed) <
kotikalapudi.sri...@nist.gov> wrote:

> Treating an UPDATE with an AS_SET as always 'Invalid' may be reasonable
> and simplifies the algorithm description except the diagnostic value of the
> 'Unverifiable' flavor is lost.


This would be my preference: marking UPDATES as “invalid” if they contain
an AS_SET anywhere in the AS_PATH.

The diagnostic value of the “Unverifiable” flavour to me seems limited, as
it introduces a potential for ambiguity and confusion.

Kind regards,

Job
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

[Job Snijders]

On Thu, 21 Jul 2022 at 10:37, Nick Hilliard  wrote:

> Sriram, Kotikalapudi (Fed) wrote on 19/07/2022 22:24:
> > Question: Operationally, is an AS_SET ever used in the*middle*
> > between AS_SEQUENCEs? Or, should one simply give zero credence to
> > it?


>
> tl;dr: epsilon levels of credence.


My take on this:

In the spirit of RFC6472, any route with an AS_SET in it should not be
considered valid (by ASPA-based validation).

If the route contains an AS_SET and a covering ASPA object exists for the
origin ASN of the route, then the route must be marked with an Invalid
status.

Kind regards,

Job

>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit (Ends 02/May/2022)

[Job Snijders]

Dear all,

The call for working group adoption ended some time ago, it seems
numerous people are in favor of progressing this work in the GROW
working group.

Authors - please resubmit this draft as 'draft-ietf-grow-bmp-tlv-ebit'

Kind regards,

Job
GROW co-chair

On Fri, Apr 08, 2022 at 04:19:19PM +0200, Job Snijders wrote:
> Hi GROW,
> 
> At the IETF 113 GROW session Paolo asked whether this working group
> could consider adoption for draft-lucente-grow-bmp-tlv-ebit.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title:
>Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
> Abstract: 
>Message types defined by the BGP Monitoring Protocol (BMP) do
>provision for data in TLV - Type, Length, Value - format, either in
>the shape of optional TLVs at the end of a BMP message or Stats
>Reports TLVs.  However the space for Type value is unique and
>governed by IANA.  To allow the usage of vendor-specific TLVs, a
>mechanism to define per-vendor Type values is required.  In this
>document we introduce an Enterprise Bit, or E-bit, for such purpose.
> 
> The Internet-Draft can be found here: 
> https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit
> 
> Please share with the mailing list if you are think this work should be
> adopted by GROW, willing to review and/or otherwise contribute to this
> draft!
> 
> WG Adoption call ends May 2nd, 2022.
> 
> Kind regards,
> 
> Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposing a well-known BGP community for Anycast

[Job Snijders]

Dear Max,

On Tue, Jul 05, 2022 at 12:40:48PM +0200, Maximilian Wilhelm wrote:
> after some discussion at RIPE84 we took the time to formalize a draft
> to define a well-known BGP community to indicate a given prefix is
> carrying Anycast traffic. The intent is to allow ISPs to do well
> informed TE, especially in cases where they want to diverge from the
> hot potato principle.
> 
> You can find the draft at
> 
> https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
> 
> Happy to share this at the upcoming meeting and hear your thoughts!

Thanks for bringing this to the working group!

I've added your internet-draft to the agenda.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 114

[Job Snijders]

Dear GROW working group,

The IETF 114 meeting is approaching!

We'd like to ask the GROW working group for agenda items.

Please email your proposal to grow-cha...@ietf.org if you'd like to
present an update on an existing Internet-Draft, or would like to bring
new material to the working group for consideration.

Hope to see you all in the in the City of Brotherly Love! 

Kind regards,

Job & Chris
GROW Chairs

   /^-^\ /^-^\
  / o o \V  o o  V
 /   Y   \|  Y  |
 V \ v / V \ Q /
   / - \   / - \
  /|   |\
(/ |   | \ )
 ===/___) ||   || (___\

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit (Ends 02/May/2022)

[Job Snijders]

Hi GROW,

At the IETF 113 GROW session Paolo asked whether this working group
could consider adoption for draft-lucente-grow-bmp-tlv-ebit.

This message is a request to the group for feedback on whether this
internet-draft should be adopted.

Title:
   Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
Abstract: 
   Message types defined by the BGP Monitoring Protocol (BMP) do
   provision for data in TLV - Type, Length, Value - format, either in
   the shape of optional TLVs at the end of a BMP message or Stats
   Reports TLVs.  However the space for Type value is unique and
   governed by IANA.  To allow the usage of vendor-specific TLVs, a
   mechanism to define per-vendor Type values is required.  In this
   document we introduce an Enterprise Bit, or E-bit, for such purpose.

The Internet-Draft can be found here: 
https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit

Please share with the mailing list if you are think this work should be
adopted by GROW, willing to review and/or otherwise contribute to this
draft!

WG Adoption call ends May 2nd, 2022.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IETF 113 GROW meeting agenda (draft)

[Job Snijders]

Hi all,

Here is the current draft GROW @ IETF 113 agenda:


https://datatracker.ietf.org/meeting/113/materials/agenda-113-grow-00.txt

Please let the chairs know if you'd also like to contribute agenda items.

Kind regards,

Job & Chris 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-07.txt

[Job Snijders]

On Tue, Mar 08, 2022 at 12:43:37AM +0100, Paolo Lucente wrote:
> I have processed all outstanding feedback for draft-ietf-grow-bmp-tlv, once
> again big thanks to Jeff Haas and Ben Maddison for their valuable new input,
> plus indeed all reviewers.
> 
> May i ask <= 5 mins of time to summarize the changes to the document? It
> would be great segway into the draft-lucente-grow-bmp-tlv-ebit document.

Noted!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang

[Job Snijders]

On Mon, Mar 07, 2022 at 11:06:55AM +0100, Camilo Cardona wrote:
> We just submitted a new draft proposing a yang module for configuring
> and managing BMP on a device.
> 
> It would be nice to get some comments, observations, etc.
> 
> Grow Chairs, will it be possible to get a 5 minute slot in the next
> session to give an overview of this module?

Your request for presentation time has been noted and accepted! Thanks.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Fwd: New Version Notification for draft-ymbk-grow-bgp-collector-communities-02.txt

[Job Snijders]

Hi Randy, Emile,

A few small notes that might be of interest should you wish to progress
this draft:

* 32-bit ASNs don't fit in 16-bit fields. Consider using a set of
  Extended Communities?
* The Local Administrator values {64994,64995,64996} might already
  be in use and carry local significance.
* I wouldn't avoid setting up an IANA registry merely because there are
  'very few categories'
* Section 5's 'well-known prefix' perhaps should be set to TBD, rather
  than using widely used RFC 1918 space.

Kind regards,

Job

On Thu, Feb 17, 2022 at 01:22:09PM -0800, Randy Bush wrote:
> six and a half year old draft rises from the dead, with modification
> 
> From: internet-dra...@ietf.org
> To: Emile Aben , Randy Bush 
> Subject: New Version Notification for 
> draft-ymbk-grow-bgp-collector-communities-02.txt
> Date: Thu, 17 Feb 2022 13:09:38 -0800
> 
> A new version of I-D, draft-ymbk-grow-bgp-collector-communities-02.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
> 
> Name: draft-ymbk-grow-bgp-collector-communities
> Revision: 02
> Title:Marking Announcements to BGP Collectors
> Document date:2022-02-17
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/archive/id/draft-ymbk-grow-bgp-collector-communities-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ymbk-grow-bgp-collector-communities/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ymbk-grow-bgp-collector-communities
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-grow-bgp-collector-communities-02
> 
> Abstract:
>When BGP route collectors such as RIPE RIS and Route Views are used
>by operators and researchers, currently one can not tell if the
>collection of paths announced to a collector represents the ISP's
>customer cone, includes internal routes, includes paths learned from
>peerings or transits.  This greatly reduces the utility of the
>collected data.  This document specifies the use of BGP communities
>to differentiate the kinds of views being presented to the
>collectors.
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] RFC 9069 on Support for Local RIB in the BGP Monitoring Protocol (BMP)

[Job Snijders]

Hi GROW,

Cause for celebration for the WG, and Tim, Serpil, Manish, & Paolo! :-)

Thank you for your work (and patience, this doc took about 5 years!)

Kind regards,

Job

On Tue, Feb 15, 2022 at 10:25:03PM -0800, rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 9069
> 
> Title:  Support for Local RIB in 
> the BGP Monitoring Protocol (BMP) 
> Author: T. Evens,
> S. Bayraktar,
> M. Bhardwaj,
> P. Lucente
> Status: Standards Track
> Stream: IETF
> Date:   February 2022
> Mailbox:tiev...@cisco.com,
> serpil.bayrak...@menlosecurity.com,
> manbh...@cisco.com,
> pa...@ntt.net
> Pages:  14
> Updates:RFC 7854
> 
> I-D Tag:draft-ietf-grow-bmp-local-rib-13.txt
> 
> URL:https://www.rfc-editor.org/info/rfc9069
> 
> DOI:10.17487/RFC9069
> 
> The BGP Monitoring Protocol (BMP) defines access to local Routing
> Information Bases (RIBs). This document updates BMP (RFC 7854) by
> adding access to the Local Routing Information Base (Loc-RIB), as
> defined in RFC 4271. The Loc-RIB contains the routes that have been
> selected by the local BGP speaker's Decision Process.
> 
> This document is a product of the Global Routing Operations Working Group of 
> the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] Input on AS Prepend for draft-idr-rpd-15.txt - Ends 02/24/22

[Job Snijders]

Hi all,

(no hats)

On Thu, Feb 10, 2022 at 09:53:44PM +, Keyur Patel wrote:
> IDR is requesting input on the use of AS prepend in BGP policy. This
> begins a 2 week call for requested input on the beneficial use of AS
> Prepend. draft-ietf-grow-as-path-prepending-05.txt indicates there is
> a risk in excessive prepending. In section 5, this draft suggests
> there is no need to prepend more than 5 ASN in an AS Pathway by a
> single AS.  Is this recommendation firm or likely to change?  Should a
> comment be added to the draft-ietf-rpd-15.txt security section to
> point to the draft-ietf-grow-as-path-prepending-05.txt draft?
> 
> The RPD draft can be found at:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd. The AS Path
> Prepending draft can be found at:
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending.
> This call will end on Feb 24th 2022.

A challenge with the recommendation as currently outlined in
draft-ietf-grow-as-path-prepending-05 ultimately is that it is a
so-called "magic constant". Magic constants in an ever growing routing
system could potentially impede future growth.

At GROW @ IETF 110 in the Q of an update on the draft I (and I believe
others) suggested to try to come up with a formula or some kind of
function into which certain properties of the default-free zone's
current observable state produce a useful number; rather than a magic
constant, to make the draft's recommendation somewhat future-proof. If
I'm not mistaken, an alternative to the 'magic constant' has not yet
materialized.

I'd be hesitant to reference draft-ietf-grow-as-path-prepending from
draft-ietf-rpd at this point in time.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Job Snijders]

Dear all,

WGLC now has been closed.

The chairs observed productive and fruitful discussion and convergence
towards a consensus, many thanks for all the input.

We will wait for the next version of the draft to be uploaded by the
authors, and then proceed with the sheperd write-up, and sending it to
IESG territory.

Kind regards,

Job & Chris

 Thu, Dec 02, 2021 at 04:10:43PM +0100, Job Snijders wrote:
> Hi Folks,
> 
> Please take 15 minutes out of your day to review this *really short!*
> internet-draft. The authors were kind enough to make it only 3 pages of
> actual content :-)
> 
> We'll extend this WGLC with another week (December 9th, 2021)
> 
> Kind regards,
> 
> Job
> 
> On Tue, Nov 16, 2021 at 05:33:39PM +, thomas.g...@swisscom.com wrote:
> > Dear GROW WG, dear authors
> > 
> > I have reviewed the draft. I think it is straight forward and ready for 
> > IESG. 
> > 
> > It is the next logical step to make the different BMP message types to be 
> > equal by supporting TLV's for BMP route-monitoring and peer_down messages 
> > as well.
> > 
> > Best wishes
> > Thomas
> > 
> > -Original Message-
> > From: GROW  On Behalf Of Job Snijders
> > Sent: Tuesday, November 16, 2021 5:16 PM
> > To: Paolo Lucente 
> > Cc: grow@ietf.org grow@ietf.org 
> > Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 
> > 2021)
> > 
> > Dear all,
> > 
> > This starts the formal WGLC period which will run from November 16th until 
> > December 1st 2021.
> > 
> > Please review 
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3Dreserved=0
> > and provide comments or feedback on the grow@ietf.org mailing list!
> > 
> > Kind regards,
> > 
> > Job
> > 
> > On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> > > Dear Colleagues, Dear Chairs,
> > > 
> > > A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv 
> > > last week at the WG meeting. We authors believe there are no more 
> > > items to work on for this draft, received inputs were processed and 
> > > any questions / concerns were addressed. I'd hence like to ask to LC this 
> > > work.
> > > 
> > > You may read motivation for this work in the draft itself, let me 
> > > supplement it saying that this is a key piece of work that would make 
> > > extensible every BMP message defined so far; this, in turn, would 
> > > bring BMP on par with other modern monitoring (/ telemetry) protocols (/ 
> > > stacks / solutions).
> > > 
> > > Paolo
> > > 
> > > ___
> > > GROW mailing list
> > > GROW@ietf.org
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40
> > > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> > > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> > > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3Dreserve
> > > d=0
> > 
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3Dreserved=0
> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Job Snijders]

Hi Folks,

Please take 15 minutes out of your day to review this *really short!*
internet-draft. The authors were kind enough to make it only 3 pages of
actual content :-)

We'll extend this WGLC with another week (December 9th, 2021)

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:33:39PM +, thomas.g...@swisscom.com wrote:
> Dear GROW WG, dear authors
> 
> I have reviewed the draft. I think it is straight forward and ready for IESG. 
> 
> It is the next logical step to make the different BMP message types to be 
> equal by supporting TLV's for BMP route-monitoring and peer_down messages as 
> well.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: GROW  On Behalf Of Job Snijders
> Sent: Tuesday, November 16, 2021 5:16 PM
> To: Paolo Lucente 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)
> 
> Dear all,
> 
> This starts the formal WGLC period which will run from November 16th until 
> December 1st 2021.
> 
> Please review 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3Dreserved=0
> and provide comments or feedback on the grow@ietf.org mailing list!
> 
> Kind regards,
> 
> Job
> 
> On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> > Dear Colleagues, Dear Chairs,
> > 
> > A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv 
> > last week at the WG meeting. We authors believe there are no more 
> > items to work on for this draft, received inputs were processed and 
> > any questions / concerns were addressed. I'd hence like to ask to LC this 
> > work.
> > 
> > You may read motivation for this work in the draft itself, let me 
> > supplement it saying that this is a key piece of work that would make 
> > extensible every BMP message defined so far; this, in turn, would 
> > bring BMP on par with other modern monitoring (/ telemetry) protocols (/ 
> > stacks / solutions).
> > 
> > Paolo
> > 
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40
> > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3Dreserve
> > d=0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3Dreserved=0


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Job Snijders]

Dear all,

This starts the formal WGLC period which will run from November 16th
until December 1st 2021.

Please review https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-06 
and provide comments or feedback on the grow@ietf.org mailing list!

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> Dear Colleagues, Dear Chairs,
> 
> A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv last
> week at the WG meeting. We authors believe there are no more items to work
> on for this draft, received inputs were processed and any questions /
> concerns were addressed. I'd hence like to ask to LC this work.
> 
> You may read motivation for this work in the draft itself, let me supplement
> it saying that this is a key piece of work that would make extensible every
> BMP message defined so far; this, in turn, would bring BMP on par with other
> modern monitoring (/ telemetry) protocols (/ stacks / solutions).
> 
> Paolo
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IETF112 - GROW starts in a bit

[Job Snijders]

Hi all,

As we've replaced frantically searching where the heck the room is in a
giant building with ... 'where the heck is the URL?!' :-)

For your convenience:

Meetecho: https://wws.conf.meetecho.com/conference/?group=grow==1

Agenda:   https://datatracker.ietf.org/meeting/112/materials/agenda-112-grow

See you in 7 minutes!

Kind regards,

Job & Chris

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] GROW @ IETF 112 - slides

[Job Snijders]

Hi everyone,

We're having a light meeting schedule this time around!

"Tuesday, 16:00-18:00 (UTC) - Session III"

https://datatracker.ietf.org/meeting/112/materials/agenda-112-grow-00

Please send slides no later than Monday, so we're ready to go on
Tuesday! :-)

If anyone has a last minute item to present on, please let us know,
there is ample room in the slot.

Look forward to seeing all of you!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 112

[Job Snijders]

Dear GROW working group,

The virtual IETF 112 meeting is approaching! You can register here
https://registration.ietf.org/112/

We'd like to ask the working group for agenda items!

Please email your proposal to grow-cha...@ietf.org

Kind regards,

Job & Chris
GROW Chairs

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] NIST RPKI Monitor Version 2.0

[Job Snijders]

Dear Sriram, Doug, others,

On Thu, Apr 29, 2021 at 01:06:58PM +, Sriram, Kotikalapudi (Fed) wrote:
> We (NIST) have released a new version of the NIST RPKI Monitor (v2.0):
> 
> https://www.nist.gov/services-resources/software/nist-rpki-deployment-monitor
> 
> We are open to adding more features and analyses based on user
> feedback. Please feel free to share your comments/suggestions. Thank
> you.

I would like to express appreciation to you and the NIST team for
operating the RPKI Monitor, and offer my congratulations on the launch
of version 2! The Monitor serves as a useful reference & resource, and
also has become an iconic online landmark for the RPKI community. It's
now almost 8 years old? A very respectable age! :-)

Running a non-commercial public online resource (without ads!) for
multiple decades requires a lot of commitment and planning. I am
thankful NIST has taken on this particular work. In my opinion NIST is
performing great service to the RPKI community. It is my hope that NIST
will keep running this service for at least another 8 years! Thank you.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

[Job Snijders]

Hi all,

We (GROW chairs + Alvaro + draft authors Tim & Paolo) had a productive
call, a number of suggestions for clarification came to light.

Tim will follow up by sending a summary of proposed changes to the list.
And some questions for the GROW group.

Thanks!

Job

On Wed, Apr 21, 2021 at 07:34:22PM +0200, Job Snijders wrote:
> Dear Alvaro, draft authors,
> 
> Perhaps it would be good to have a voice discussion? This might expedite
> figuring out a solution to how we describe things.
> 
> From what I understand the BMP Loc-RIB draft to propose is that all BMP
> messages of the Loc-RIB instance type are 'synthesized', as the
> Information Base contains the router's best paths (regardless of
> original protocol). It indeed would be good if the document is very
> clear on this aspect.
> 
> I'm happy to organize a call for early next week (early PST / afternoon
> CEST timeslot).
> 
> Kind regards,
> 
> Job & Chris
> GROW Chairs
> 
> On Mon, Apr 05, 2021 at 12:43:02PM -0700, Alvaro Retana via Datatracker wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-grow-bmp-local-rib-10: 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/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/
> > 
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > I am balloting DISCUSS because there are significant clarity issues.
> > 
> > (1) 4.2.  Peer Flags
> > 
> >In section 4.2 of [RFC7854], the "locally sourced routes" comment
> >under the L flag description is removed.  If locally sourced routes
> >are communicated using BMP, they MUST be conveyed using the Loc-RIB
> >instance peer type.
> > 
> > This change is bigger than simply removing a comment: it is changing the
> > behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the same
> > considerations apply?   I would like to see a clearer treatment of the 
> > change
> > related to locally sourced routes -- a separate section/sub-section seems
> > appropriate.
> > 
> > (2) §4.2/8.2: Peer Flags
> > 
> > §4.2 defines a new Flag as follows:
> > 
> >   0 1 2 3 4 5 6 7
> >  +-+-+-+-+-+-+-+-+
> >  |F|  Reserved   |
> >  +-+-+-+-+-+-+-+-+
> > 
> > But it doesn't mention that this field is intended to be specific to the
> > Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:
> > 
> >This document defines a new flag (Section 4.2) and proposes that peer
> >flags are specific to the peer type:
> > 
> > The registry [1] shows that the early allocation was made in the "generic" 
> > (not
> > per-peer-type) Peer Flags field.  The flags defined in rfc7854 and rfc8671 
> > both
> > assume the same set of Flags for all peer types.
> > 
> > [1]
> > https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags
> > 
> > (3) §5.4 (Route Monitoring)  The implication in this section is that a BGP
> > UPDATE includes the route information -- but the information in the Loc-RIB 
> > may
> > not have come from BGP, so there is no BGP UPDATE to propagate.  This 
> > clearly
> > is a case where the UPDATE is fabricated.  Please provide specific 
> > instructions
> > on how this UPDATE is constructed, including any path attributes.
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > (1) §3 (Definitions)
> > 
> >*  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
> >   an Adj-RIB-Out. This MUST be what is actually sent to the peer.
> > 
> > s/This MUST be what is actually sent to the peer./This is what is sent to 
> > the
> > peer.
> > 
> > Note that this document should not use Normative language related to what a 
> > BGP
>

Re: [GROW] BGP Looking Glass Capability

[Job Snijders]

On Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF) wrote:
> > Consistent API that serves RIB data
> 
> Initially I tried to avoid defining the exact API of the looking glass by
> pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it does
> not strictly define the response format instead leaving it up to the
> implementation what to return to queries, which IMO is not very useful for
> automation.
> 
> As y'all have pointed out there is a wealth of implementations out there
> that have tried to address this (and adding some others I've found):
> 
>- Paolo's pmacct looking glass document:
>https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT,
>- Birdseye https://github.com/inex/birdseye
>- CAIDA looking glass API
>https://www.caida.org/tools/utilities/looking-glass-api/
>- DE-CIX: https://www.de-cix.net/en/resources/looking-glass (which is
>using https://github.com/alice-lg/alice-lg)
>- RIPEStat's API, e.g.
>
> https://stat.ripe.net/data/looking-glass/data.json?preferred_version=2.1=2a0d:d740::/48

Just to add to the list: there is yet another API-based Looking Glass
targetting OpenBGPD: https://github.com/cjeker/bgplgd

A demo is here:
http://165.22.27.105/bgplgd/summary
http://165.22.27.105/bgplgd/rib?as=22512

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Alvaro Retana's Discuss on draft-ietf-grow-bmp-local-rib-10: (with DISCUSS and COMMENT)

[Job Snijders]

Dear Alvaro, draft authors,

Perhaps it would be good to have a voice discussion? This might expedite
figuring out a solution to how we describe things.

>From what I understand the BMP Loc-RIB draft to propose is that all BMP
messages of the Loc-RIB instance type are 'synthesized', as the
Information Base contains the router's best paths (regardless of
original protocol). It indeed would be good if the document is very
clear on this aspect.

I'm happy to organize a call for early next week (early PST / afternoon
CEST timeslot).

Kind regards,

Job & Chris
GROW Chairs

On Mon, Apr 05, 2021 at 12:43:02PM -0700, Alvaro Retana via Datatracker wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-grow-bmp-local-rib-10: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I am balloting DISCUSS because there are significant clarity issues.
> 
> (1) 4.2.  Peer Flags
> 
>In section 4.2 of [RFC7854], the "locally sourced routes" comment
>under the L flag description is removed.  If locally sourced routes
>are communicated using BMP, they MUST be conveyed using the Loc-RIB
>instance peer type.
> 
> This change is bigger than simply removing a comment: it is changing the
> behavior.  Note that §8.2/rfc7854 also talks about the L flag.  Do the same
> considerations apply?   I would like to see a clearer treatment of the change
> related to locally sourced routes -- a separate section/sub-section seems
> appropriate.
> 
> (2) §4.2/8.2: Peer Flags
> 
> §4.2 defines a new Flag as follows:
> 
>   0 1 2 3 4 5 6 7
>  +-+-+-+-+-+-+-+-+
>  |F|  Reserved   |
>  +-+-+-+-+-+-+-+-+
> 
> But it doesn't mention that this field is intended to be specific to the
> Loc-RIB peer-type.  OTOH, §8.2 (IANA Considerations) does:
> 
>This document defines a new flag (Section 4.2) and proposes that peer
>flags are specific to the peer type:
> 
> The registry [1] shows that the early allocation was made in the "generic" 
> (not
> per-peer-type) Peer Flags field.  The flags defined in rfc7854 and rfc8671 
> both
> assume the same set of Flags for all peer types.
> 
> [1]
> https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags
> 
> (3) §5.4 (Route Monitoring)  The implication in this section is that a BGP
> UPDATE includes the route information -- but the information in the Loc-RIB 
> may
> not have come from BGP, so there is no BGP UPDATE to propagate.  This clearly
> is a case where the UPDATE is fabricated.  Please provide specific 
> instructions
> on how this UPDATE is constructed, including any path attributes.
> 
> 
> --
> COMMENT:
> --
> 
> (1) §3 (Definitions)
> 
>*  Post-Policy Adj-RIB-Out: The result of applying outbound policy to
>   an Adj-RIB-Out. This MUST be what is actually sent to the peer.
> 
> s/This MUST be what is actually sent to the peer./This is what is sent to the
> peer.
> 
> Note that this document should not use Normative language related to what a 
> BGP
> session does.  In this case, that is rfc4271's job.
> 
> (2) §5.2 (Peer UP Notification): "Capabilities MUST include the 4-octet ASN 
> and
> all necessary capabilities to represent the Loc-RIB route monitoring messages.
> Only include capabilities if they will be used for Loc-RIB monitoring 
> messages."
> 
> Which are the capabilities that "will be used for Loc-RIB monitoring 
> messages"?
>  The action above is required (MUST), but no specifics are given.
> 
> (3) §5.2.1: "The Information field contains a UTF-8 string whose value MUST be
> equal to the value of the VRF or table name (e.g.  RD instance name) being
> conveyed."
> 
> - Please take a look at the Shutdown Communication string definition in 
> rfc9003
> and use a similar definition.
> 
> - The "value of the VRF or table name" is a local matter, right?  How can the
> requirement be normatively enforced?  How can the receiver enforce the 
> "MUST"? 
> IOW, s/MUST.../The information field contains the value of the VRF or table
> name...
> 
> - There's no need to redefine the TLV in §5.3.
> 
> (4) §5.4: "As defined in section 4.3 of [RFC7854]..."  The quote comes from
> §4.6.
> 
> (5) 

Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

[Job Snijders]

On Wed, Mar 31, 2021 at 06:09:42PM -0400, Jeffrey Haas wrote:
> > There is already a separate draft in IDR that has passed WGLC, and it uses 
> > a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
> > We view that as a longer-term solution, while the EC/LC-based approach is 
> > meant to be deployed quickly.  
> 
> I've been caught napping on the changes in open policy and will have to go
> read this.

If we're talking about 'deploying quickly', something that can be done
on any of the BGP implementations in operation today (capable of
matching a single RFC 1997 BGP community), is to use the NOPEER community.

I really think NOPEER Community [RFC 3765] is suitable as synonymous to
"Only to Customer". It would change the draft from "route leak detection"
into "route leak prevention", but as bgp-open-policy-XX require new code
anyway, this new code might as well use on an existing attribute to
foster incremental deployment.

If future BGP-OPEN compliant BGP speakers end up tagging routes with
NOPEER when received from a "role: peer" BGP neighbor, and automatically
block outbound route announcements towards "role: transit" and "role: peer"
BGP neigbhor sessions, the effect of "Only to Customer" (role: customer)
is achieved.

A confusing aspect in this dialogue:
The meaning of the word 'peer' RFC 3765 is different than the meaning of
the word 'peer' in draft-ietf-idr-bgp-open-policy-15, the latter
document appears to use the word as a description of the positions a
network can have in the 'gao and rexford' model.

When reading draft-ietf-idr-bgp-open-policy-15 keep this mapping in mind:
  'role: peer'  == RFC 3765 'peer'
  'role: provider'  == RFC 3765 'peer'
  'role: rs'== RFC 3765 'peer'

An implementation which is evaluating whether to export a given best
path to a neighbor which has role ('peer', 'provider', 'rs') as
established through draft-ietf-idr-bgp-open-policy; is RECOMMENDED to
not export routes which carry the NOPEER community.

Using NOPEER (instead of EC or LC) can be implemented on both bgp-open
capable implementations, but also through configuration in existing
deployments.

Reading RFC 3765 it seems appropriate to use this well-known community
'attribute' for this purpose. RFC 3765 is intended as a general purpose
route propagation restriction community. Bgp-open capable
implementations which use NOPEER in this way, are be compatible with
existing deployments of NOPEER.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Job Snijders]

Dear Jakob,

On Wed, Mar 10, 2021 at 02:10:24AM +, Jakob Heitz (jheitz) wrote:
> Job, your suggestion kicks a different goal than
> draft-ietf-grow-route-leak-detection-mitigation does.

Yes, I'm aware I am suggesting a different approach to solve the problem
of route leaks.

> draft-ietf-grow-route-leak-detection-mitigation tries to determine
> if your neighbor leaked the route to you.
> To do that, you need to know how your neighbor received the route
> before he sent it to you.
> That's what the ASN in the LC is for.

Right, so my proposal is that the neighbor does not (knowingly) leak 
routes to you, negating the need to additionally tag routes with more
information than "this route is intended for not-for-peers (Down Only)"

I believe the Section 6 'Only To Customer' Attribute described in
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15 can be
implemented using the existing well-known NOPEER Attribute.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Job Snijders]

On Wed, Mar 10, 2021 at 03:08:34AM +, Jakob Heitz (jheitz) wrote:
> >From the BGP speaker (client) implementation point of view,
>
> I would do it like this:
> The client keeps a ring buffer of data it sent to the server.
> The bottom of the buffer is at a certain sequence number.
> As messages are created, that bottom moves up.
> If the server were to restart, it would send its last
> received sequence number and session ID. If the buffer still
> contains the sequence number, then you're in luck, else
> big bang restart.
> The content of the buffer could be optimized by retrieving some
> of the information from the bgp table (adj-rib's are conceptual only)
> instead of literally storing it. How and if any optimization is
> done is implementation specific and not part of an RFC.

In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial
numbers are not required, only a 'session id' (which might remain the
same over the lifetime of the BMP client's lifetime).

A full 'big bang' restart is achieved by the server disconnecting and
allowing reconnection twice, within the 60 second window. When combined
with TCP_FAST_OPEN resuming a session requires 2 packets (one each way)
and restarting a session requires 4 packets.

This way BMP remains a 'read only' protocol, but I admit this is
an unconventional approach.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Job Snijders]

On Tue, Mar 09, 2021 at 08:44:18PM +, Jakob Heitz (jheitz) wrote:
> BMP is a one-way protocol. The BMP server sends nothing.

In the proposal at hand, the BMP server would send a client-specific
TCP_FAST_OPEN cookie (on top of TCP ACKs), and possibly eventually a TCP
RST, which is slightly more than 'nothing'... :-)

As TCP_FAST_OPEN already is a published RFC, existing BMP clients &
servers are free and able to opportunistically use TCP Fast Open. For
the sake of conversation I'll consider TCP_FAST_OPEN out-of-scope for
BMP and GROW in the rest this email.

BMP - one way protocol on reliable transport: are successive RSTs a signal?
===

In a one-way protocol where the recipient essentially is limited to 'TCP
ACK' and 'TCP RST' as response options, would it perhaps make sense to
outline a BMP protocol where both BMP client and BMP server assume more
delibrate intent from the timing of TCP reconnection events?

If the BMP client includes a 'session_id' message as its first message
towards the BMP server, then when the client loses its connection to the
BMP server, it can continue buffering messages destined for that
specific BMP server linked to the previously sent 'session_id'.

Then, if the BMP client manages to reconnect to the BMP server within 60
seconds, the client will flush all buffered messages associated with the
session_id also communicated in prior BMP sessions.

However if the BMP server closes the TCP session within that 60 seconds
buffer window, a subsequent successful reconnection would result
in the BGP client sending a new session_id followed by all 'Peer Up'
messages, because the previous BMP session (and buffer) were
terminated.

The BMP server can immediately disconnect when it receives a BMP
session_id it does not recognize (by issuing a TCP RST). When a BMP
client receives the 'second' TCP RST within 60 seconds, it can choose to
reconnect following an linear backoff model and for the duration of wait
periods exceeding 1 minute not bother buffering for 'unreachable' BMP
servers.

The heuristic is that the BMP client considers the BMP session
'resumed', iff a BMP server doesn't disconnect within 60 seconds.

The BMP server can use the session_id as input to its decision process
whether to disconnect within 60 seconds or not.

Blink once the BMP session survives... blink twice, game over!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] route leak solution and IANA large community register

[Job Snijders]

Dear Sriram, Sue,

Working Group Last Call is possible, but I suspect after WGLC it will
not be possible for the document to progress beyond the Shepherd
Write-up step, because the current -04 version essentially is blocking
on a normative dependency on 'draft-heitz-idr-wklc' (or any successor).

My recommendation would be to let both efforts proceed independently, 
as it probably would be good to continue discussion on whether
draft-ietf-grow-route-leak-detection-mitigation's objective can only be
solved with Large Communities; and separately whether in the large
communities 'space' a segment of the 'spectrum' should be set aside for
future well-known through standards documented signaling.

Kind regards,

Job
GROW Working Group Chair

On Tue, Mar 09, 2021 at 12:30:14PM -0500, Susan Hares wrote:
> Sriram:
> 
> If IDR adopts the draft, you can ask for early allocation on the registry.
> Before that point,  let me chat with the IDR co-chairs and ADs to what other
> options you have. 
> 
> Cheers,  Sue 
> 
> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] 
> Sent: Sunday, March 7, 2021 6:26 PM
> To: Christopher Morrow; Job Snijders
> Cc: grow-cha...@ietf.org; GROW WG; idr-cha...@ietf.org; Susan Hares;
> a.e.azi...@gmail.com
> Subject: route leak solution and IANA large community register
> 
> I have a question for the GROW Chairs and anyone who can help.
> 
> There are these two drafts:
> Methods for Detection and Mitigation of BGP Route Leaks
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
> 04
> 
> BGP Well Known Large Community
> https://tools.ietf.org/html/draft-heitz-idr-wklc-01
> 
> The first is in a mature state in GROW and the second is in a
> pre-adoption-call state in IDR. The first draft requests IANA for an
> allocation in well-known Large Community (WKLC) registry but no such IANA
> registry exists yet. The second draft (in IDR) is making an effort to
> specify and request the creation of an IANA WKLC registry. This work seems
> to be going slow in IDR -- partly the authors are responsible (including
> me).  
> 
> Question: Is the creation of an IANA Large Community registry a prerequisite
> for a WGLC on the first one (in GROW)? Or, it is possible to have WGLC
> requested/completed on the first one and then wait for the creation of the
> IANA LC registry?
> 
> Thanks.
> 
> Sriram  
> 
> 
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Job Snijders]

Dear GROW,

(Removed sidrops@ from CC)

*Wearing a Working Group participant hat*

I reviewed draft-ietf-grow-route-leak-detection-mitigation-04 and it
appears to me there is a shortcut possible in the mitigation algorithm.
This shortcut in turn negates the need to specify any ASN in the "DO
Community". Only requiring a single community opens up the path to use
existing well-known RFC 1997 community as signal between BGP nodes.

The section 4.1 leak mitigation algorithm could be revised such that if
a route path present in the Loc-RIB is considered the best path and
eligible for export to EBGP neighbors, an additional verification step
is performed.

The sender could check whether a 'DO community' is present on the route
in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured
as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB
(Policy Information Base) and thus will not be present in Adj-RIB-Out -
thus blocking a leak from happening. This places the route leak
mitigation solution one step earlier in the BGP 'supply chain' process.

There is an existing well-known BGP Community known as 'NOPEER
Community for BGP Route Scope Control', described in RFC 3765.

Similar to how the mitigation does not truly differentiate between
'Providers' and 'Lateral Peers' (if one considers routing policy puzzles
often can be solved through multiple different combinations of policy in
either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT.

The recommendation then simplifies to the following three steps:

1/ Recommend network operators to never strip the RFC 3765 Community
   upon receiving a BGP route from either an IBGP or EBGP neighbor.

2/ Recommend network operators to manually configure (or have BGP OPENv2
   speakers automatically) *add* the NOPEER Community (if it wasn't
   already present) to route paths received from a Lateral Peer or
   Provider. Then proceed with whatever Import Policy applies.

3/ Recommend network operators (or have BGP OPENv2 speakers
   automatically) block routes which contain the NOPEER Community from
   propagating towards EBGP neighbor marked as 'Lateral Peer' or
   'Provider'. The procedure stops.

4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the
   route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor.
   The NOPEER community is not removed (see step 1).

As Nick Hilliard pointed out earlier in this thread, there might be
business requirements which require the operator to override the
autnomous system's default policy, but as the NOPEER Community happens
to be 'just a BGP community', operators can do as they wish with the
received routing information. A case can be made that operators - by
default - would benefit from accepting the NOPEER community and based on
its presence prevent routes from propagating further towards EBGP
neighbors in the Peer/Provider class.

The above proposal is slightly different than the implementation
requirements stemming from honoring GRACEFUL_SHUTDOWN (where the
intention is for the inter-domain signal to be honored on EBGP-IN), the
NOPEER community essentially is best honored in EBGP-OUT policies.

Promoting inter-domain use of the NOPEER community by outlining how
correctly adding & scoping based on this community one can help mitigate
BGP route leaks. The NOPEER community being readily available in most
deployed BGP speakers for any operator wishing to use the mitigation
mechanism, this might make for a compelling argument.

In short 'Down Only' is equivalent to 'Not towards Peers & Providers:

  - in EBGP-IN set NOPEER on routes received from Peers/Providers
  - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers

The above appears incrementally deployable, and compliant with the
specification of NOPEER, and can be promoted through Network Operator
Groups by converting draft-ietf-idr-route-leak-detection-mitigation to
target Best Current Practise (BCP).

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] is TCP the right layer for BMP session resumption?

[Job Snijders]

Dear group,

Yesterday we had the pleasure to hear a report from Thomas Graf on new
BMP work.

The https://datatracker.ietf.org/doc/html/draft-tppy-bmp-seamless-session-00
document outlines a concept to allow BMP clients to resume 'an existing'
session with the BMP server, reducing the need to re-transmit
information the client 'already knows'.

I informally polled some people with the question 'thoughts on
TCP_FAST_OPEN? It was brought to my attention a userspace server daemon
is not aware whether a TCP connection was set up with FAST_OPEN or not.

Furthermore, TCP_FAST_OPEN's primary use case appears to be to reduce
the burden of TCP Three-way handshake on 'short-lived' connections, and
was *not* designed for general purpose 'session resumption'.

RFC 7413 appears to suggest TCP_FAST_OPEN can be used to jam a 'small'
message (like a HTTP 302 response to a GET request) into the SYN-ACK,
whereas BMP Session Resumption is not about 'a quick and small reply',
but rather "previously there was lots of data, are you aware of that
previous data? By the way, what will follow next is lots and lots of
more data!".

TCP_FAST_OPEN appears a poor fit for the objective of BMP Seamless
Session Resumption.

If not TCP_FAST_OPEN, then what?


Perhaps inspiration can be taken from RFC 6810's RPKI-To-Router (RTR)
protocol which leverages a "Session ID" and "Serial Number" to allow
efficient (even transport-protocol agnostic!) session resumption.

This same style of session resumption mechanism can also be found in the
RPKI Repository Delta Protocol (RRDP).

Perhaps BMP would benefit from a similar resumption mechanism to reduce
the burden on servers & clients?

I welcome insights and feedback from the working group.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] GROW @ IETF 110 - starts 1 hour later! (14:00 - 15:00 CET)

[Job Snijders]

Dear all,

To resolve a scheduling conflict, and because this meeting's agenda
allows it... the GROW meeting will start 1 hour later!

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021=3=8=13=0=0=16=248=64=224

I'll be in the room to make people aware we're starting a bit later.

Today's agenda: https://datatracker.ietf.org/doc/agenda-110-grow/
slides: https://datatracker.ietf.org/meeting/110/session/grow

meetecho: https://meetings.conf.meetecho.com/ietf110/?group=grow==1

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Call for agenda items for GROW @ IETF 110

[Job Snijders]

Dear all,

I'd like to draw attention to our fairly empty agenda... please help fill
it! :-)

Kind regards,

GROW Chairs
Job & Chris


On Wed, Jan 27, 2021 at 3:35 PM Job Snijders  wrote:

> Dear GROW working group,
>
> The virtual IETF 110 meeting is approaching! You can register here
> https://registration.ietf.org/110/
>
> We'd like to ask the working group for agenda items!
>
> Please email your proposal to grow-cha...@ietf.org
>
> Kind regards,
>
> Job  & Chris
> GROW Chairs
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Publication has been requested for draft-ietf-grow-bmp-local-rib-09

[Job Snijders via Datatracker]

Job Snijders has requested publication of draft-ietf-grow-bmp-local-rib-09 as 
Proposed Standard on behalf of the GROW working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Call for agenda items for GROW @ IETF 110

[Job Snijders]

Dear GROW working group,

The virtual IETF 110 meeting is approaching! You can register here
https://registration.ietf.org/110/

We'd like to ask the working group for agenda items!

Please email your proposal to grow-cha...@ietf.org

Kind regards,

Job  & Chris
GROW Chairs
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

[Job Snijders]

Dear Tim,

Hi Tim,

On Wed, Nov 04, 2020 at 05:49:48PM +, Tim Evens (tievens) wrote:
> [tievens] Agree. The draft itself has local in the name.  Does it make
> sense to change the draft name or keep it as is? 

The filename is not relevant, I'd leave it as-is. Ultimately the
document will have an RFC number as filename anyway.

> [tievens] That works, but it's really the only method right now... hence 
> current... it becomes
>   alternative with this draft. (  Changed to alternative. 

Thanks. At this stage of the document's lifecycle it sometimes is
helpful to assume a writing style 'as if the document has been
published'. :-)

Thank you for the changes!

Can you upload a new revision next week?

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] review of draft-ietf-grow-bmp-local-rib-07 (preparing for sheperd write-up)

[Job Snijders]

Dear group, authors

As part of the sheperd write-up I am reviewing the
draft-ietf-grow-bmp-local-rib-07 Internet-Draft. Overall the document
looks good to me.

Please consider these notes as input from an individual working group
participant. The suggestions are editorial in nature, my focus on
readability and clarity.

Thank you for your consideration!

Kind regards,

Job

### note 1

Suggested rewording of Abstract:

NEW Abstract:
The BGP Monitoring Protocol (BMP) defines access to various Routing
Information Bases (RIBs). This document updates BMP (RFC 8671) by
adding access to the Local Routing Information Base (Loc-RIB), as
defined in RFC 4271. The Loc-RIB contains the routes that have been
selected by the local BGP speaker's Decision Process. 

### note 2

Throughout the document I would suggest changing the phrase
"Local-RIB" to "Loc-RIB".

### note 3

Perhaps the first sentence of the introduction reads better if changed
to the following:

NEW:
This document defines a mechanism to monitor the BGP Loc-RIB state
of remote BGP instances without the need to establish BGP peering
sessions.

### note 4

I have trouble understanding the following:

The BGP Monitoring Protocol (BMP) suggests that locally originated
routes are locally sourced routes, such as redistributed or otherwise
added routes to the BGP instance by the local router. It does not
specify routes that are in the BGP instance Loc-RIB, such as routes
after best-path selection.

### note 5

OLD:
Adj-RIBs-In Post-Policy may still contain hundreds of thousands of
routes per-peer but only a handful are selected and installed in
the Loc-RIB as part of the best-path selection.

NEW:
The Adj-RIB-In for a given peer Post-Policy may contain hundreds of
thousands of routes, with only a handful of routes selected and installed
in the Loc-RIB after best-path selection.

### note 6

Section 1.1. "Current method to Monitor Loc-RIB" probably needs to be
"Alternative method to monitor Loc-RIB"

s/current/alternative/

### note 7

In section 3, the following change hopefully clarifies that the Loc-RIB
as observed through BMP is a composite of 
potentially-to-be-redistributed-into-BGP-routes
and routes received from other peers. 

OLD:
It is further defined that the routes selected include locally originated
and routes from all peers.

NEW:
Note that the Loc-RIB state as monitored through BMP might also contain routes
imported from other routing protocols such as an IGP, or local static routes.

### note 8

section 5.3

Curious: why ASCII and not UTF-8 (of which ASCII is a subset)?

### note 9

Section 6.1 states "several methods to implement Loc-RIB efficiently"

is this the implementation of Loc-RIB in a BGP-4 speaker? Or the implementation
of BMP Loc-RIB monitoring?

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

Dear group,

Taking Alvaro's and other people's feedback into account, here is the
fourth version of the charter.

OK? good to go? Warren Kumari? :-)

Kind regards,

Job
GROW co-chair



Charter for Working Group
 
The purpose of GROW is to consider the operational problems associated
with the Internet Protocol (IP) global routing systems, including but
not limited to default-free zone routing table growth, effects of the
interactions between interior and exterior routing protocols, the effect
of address allocation policies, or practices on the global routing
system. Where appropriate, GROW documents the operational aspects of
measurement, monitoring, policy, routing system security, VPN
infrastructures, or safe default behavior of IP routing protocol
implementations and deployments.

GROW will also advise various working groups, mainly IDR and SIDROPS,
with respect to whether it is addressing the relevant operational and
routing security requirements of Internet-connected networks, and where
appropriate, suggest course corrections. Finally, operational
requirements developed in GROW can also be used by any working group
chartered with standardizing a next generation inter-domain routing
protocol.
  
Goals:
--

Provide stewardship and maintenance for the BGP Monitoring  Protocol (BMP)
Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit 
(MRT) Routing Information Export Format
Document Best Current Practises for operations of the Internet global routing 
system.
Analyze aspects for supporting new applications, including extending existing 
routing protocols or creating new ones. This includes risk, interference, and 
application fit.
Document the operational aspects of securing the Internet routing system, and 
provide recommendations to other WGs.
Provide documentation to assist in preventing malpractice in the global routing 
system.

Milestones
--

Nov 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
Jun 2021 - "BMP Peer Up Message Namespace" to IESG
Jun 2021 - "Revision to Registration Procedures for Multiple BMP Registries" to 
IESG.
Jul 2021 - “Document negative consequences of de-aggregating received  routes 
for traffic engineering purposes” - to IESG
Nov 2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to 
IESG.
Jan 2022 - “A BCP on using IRR and RPKI data to improve filtering of BGP 
peering sessions” to IESG or via “Evolving Documents”

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] IPR call for draft-ietf-grow-bmp-local-rib

[Job Snijders]

Dear draft-ietf-grow-bmp-local-rib authors,

Are you aware of any IPR for draft-ietf-grow-bmp-local-rib?

IPR resources:
https://datatracker.ietf.org/ipr/about/
RFC 8179 "Intellectual Property Rights in IETF Technology" 
https://tools.ietf.org/html/rfc8179

Kind regards,

Job
Chair GROW

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 08/12/2020 (Aug 12)

[Job Snijders]

I support adoption too

(no hats)

On Wed, Jul 29, 2020 at 05:19:07PM +, Christopher Morrow wrote:
> + the real slim-shady.
> 
> On Wed, Jul 29, 2020 at 5:17 PM Christopher Morrow
>  wrote:
> >
> > Howdy WG Folks!
> > There's been significant chatter on-list about:
> >   draft-mcbride-grow-as-path-prepend-01
> >
> > Abstract:
> >   "AS_Path prepending provides a tool to manipulate the BGP AS_Path
> >attribute through prepending multiple entries of an AS.  AS_Path
> >prepend is used to deprioritize a route or alternate path.  By
> >prepending the local ASN multiple times, ASes can make advertised AS
> >paths appear artificially longer.  Excessive AS_Path prepending has
> >caused routing issues in the internet.  This document provides
> >guidance,to the internet community, with how best to utilize AS_Path
> >prepend in order to avoid negatively affecting the internet."
> >
> > This work seems directly in the GROW wheelhouse, and it appears folk
> > on-list agree. Let's decide with a WG Adoption call for this document
> > and see if we should continue this work officially/etc.
> >
> > Please give it a read, and comment on adoption ideals here-in.
> >
> > thanks!
> > -chris
> > co-chair-persona

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

Dear all,

Below is a third revision of the charter proposal, we attempted to
incorporate all the feedback received so far, specifically Alvaro's.

Please let us know your feedback!

Kind regards,

Job & Chris

--

Charter for Working Group
==

The purpose of GROW is to consider the operational problems associated
with the Internet Protocol (IP) global routing systems, including but
not limited to default-free zone routing table growth, effects of the
interactions between interior and exterior routing protocols, the effect
of address allocation policies, or practices on the global routing
system. Where appropriate, GROW documents the operational aspects of
measurement, monitoring, policy, routing system security, VPN
infrastructures, or safe default behavior of IP routing protocol
implementations and deployments.

GROW will also advise various working groups, specifically IDR and
SIDROPS, with respect to whether it is addressing the relevant
operational and routing security requirements of Internet networks,
and where appropriate, suggest course corrections. Finally, operational
requirements developed in GROW can also be used by any working group
chartered with standardizing a next generation inter-domain routing
protocol.
 
GOALS
-

* Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP)
* Provide stewardship and maintenance for the Multi-Threaded Routing
  Toolkit (MRT) Routing Information Export Format
* Document Best Current Practises for operations of the Internet global
  routing system.
* Analyze aspects for supporting new applications, including extending
  existing routing protocols or creating new ones. This includes risk,
  interference, and application fit.
* Document the operational aspects of securing the Internet routing
  system, and provide recommendations to other WGs.
* Provide documentation to assist in preventing malpractice in the
  global routing system.

Milestones
--

2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
2020 - "BMP Peer Up Message Namespace" to IESG
2020 - "Revision to Registration Procedures for Multiple BMP Registries" to 
IESG.
2021 - "Document negative consequences of de-aggregating received routes for 
traffic engineering purposes" - to IESG
2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to IESG.
2021 - "A BCP on using IRR and RPKI data to improve filtering of BGP peering 
sessions" to IESG or via "Evolving Documents"


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] New RPSL via attributes in the autnum Class

[Job Snijders]

Dear all,

I'd like to abandon draft-snijders-rpsl-via and mark it dead. I don't think we 
can make the mechanism as proposed work in a meaningful way for common internet 
deployments.

Describing "routing policy" (the *import* / *export* attributes in Autnum 
objects) within the constrains of the RPSL language has proven to be 
problematic.

I hope at some point an initiative will start up (and to be part of that 
effort!) to address some of the gaps we've identified over the years - we'll 
see where that starts.

Kind regards,

Job

On Wed, Oct 23, 2013, at 15:31, Nick Hilliard wrote:
> On 23/10/2013 21:28, Jeffrey Haas wrote:
> > Secondly, the amount of work that went into even getting as far as RPSL from
> > RIPE-181 was daunting.  I'd think very hard before considering such work.
> 
> if it had been easy, someone would have done it long ago because we all
> need automated tools for handling our network devices.
> 
> Nick
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Playing with origin validation

[Job Snijders]

On Sun, Apr 12, 2020 at 08:39:58PM +0200, Robert Raszuk wrote:
> Would anyone be able to explain the below phenomenon?
> 
> RPKI Origin validation marks net 45.227.254.0/24 as INVALID as it expects
> it to be originated by ASN: 395978

If you look at https://stat.ripe.net/45.227.254.0%2F24#tabId=routing you
can see that the prefix is only seen by 72% of the RIPE RIS collectors,
this is a very low score, I'd consider this a problematic network
outage. If you'd have internet access users serviced out of the block it
probably would mean many websites don't work, or don't work well.

In the 'Routing History' widget we can see:

May 2018 - Jul 2018 - AS 395978 
   Aug 2018 - AS 62088
Oct 2018 - Mar 2019 - AS 42260
Feb 2019 - Mar 2020 - AS 51852

I guess early someone deemed AS 395978 deemed to be the right origin ASN
and create RPKI ROAs, but subsequently didn't update these RPKI ROAs to
the new ASNs as the space moved from lessee to lessee. I suspect IP
address leasing is in play because the announcement periods don't seem
to overlap, suggesting there might have been coordination between
previous and next Origin ASN.

Since the ROA still exists, whoever created the ROA (to authorize
395978) still is in authority, so from an operational perspective it is
incumbent on that entity to correct the RPKI information. If the space
had been transferred from one LIR to another LIR the 'offending' ROA
would've been deleted in that transfer process.

> But it comes from  51852 which according to ipinfo or bgpview is
> legitimate ASN:
> 
> https://ipinfo.io/AS51852/45.227.254.0/24
> https://bgpview.io/prefix/45.227.254.0/24

I am not sure in what way you are reading the data, the information
displayed here doesn't weigh in on legitimacy. Both websites are
frontends to public whois data, they shows the prefix is suballocated to
'Xwin universal ltd', but the originating ASN is 'Private Layer INC'.

> As I see similar discrepancies in many global networks I would like to
> ask who to trust ? If RPKI data is not valid then I think we have a
> real problem.

I am not sure it is about trust. I trust the system works as designed,
which means there is potential for human error in the ROA creation
process. In this sense IRR, DNSSEC, and RPKI have some similarities -
they all potentially set a user up for failure.

Operators deploying OV have to the balance of inconvenience for entities
who misconfigured their ROA against the consequences of accepting BGP
misconfigurations or hijacks of prefixes which could've been prevented
had ROAs been honored.

An operator should notify its customers who are announcing RPKI invalids
before deploying Origin Validation with 'invalid == reject' policies on
the EBGP edge. This way the alert notification about the ROA
misconfiguration follows contractually established inter-organisation
communication channels. Sometimes that mechanism works well!

Another theory is that some (a lot?) of the RPKI Invalids that exist in
the default-free zone in a steady state are not really in use, just
'parked'. Folk wisdom suggests if you don't announce all your prefixes
in the DFZ, malicious actors tend to notice and start using the space in
your stead. Because of this (and other reasons) we can't really know
what IP address space is actually in use or not.

Traffic studies done by some network operators in the months prior to
deploying RPKI OV commonly show very little or no traffic destined for
RPKI Invalids. In these studies it is important to separate RPKI
invalids that become 'unreachable', and traffic for IPs covered by RPKI
invalids which are covered by a less specific not-found/valid
announcement. 
https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html

Back to the prefix at hand, I believe this to be the party in charge of
the RPKI ROA:

$ whois 45.227.252.0/22 | grep @ | sort -u
e-mail:  n...@flyservers.com

One could reach out to the operator and ask them?

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] GROW Meeting @ IETF 107 / YVR

[Job Snijders]

Does anyone have agenda items for this specific meeting?

If things can wait a little bit we can request a virtual interim meeting
to accomodate what should've been handled this IETF around.

Kind regards,

Job

On Thu, Mar 05, 2020 at 04:34:56PM +, Chris Morrow wrote:
> 
> Howdy folks!  It's looking like both chairs will not be able to attend
> the meeting in Vancouver in ~20 days time. We won't know definitely
> until about the 16th, however.
> 
> I'm going to put in cancel requests for the GROW meeting now,
> if things change we can re-collect our room, I'm certain.
> 
> -chris
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

Dear Alvaro,

Thank you for your comments.

On Thu, Nov 21, 2019 at 07:42:05PM -0800, Alvaro Retana wrote:
> > Finally, where appropriate, the GROW documents the operational
> > aspects of measurement, monitoring, policy, security, and VPN
> > infrastructures, and safe default behavior of implementations.
> 
> It is important to highlight somewhere that protocol changes (to, for
> example, meet that "safe default behavior") are to be developed in the
> WG chartered with maintaining the specific protocol.  idr for BGP, in
> close coordination with grow, of course.
> 
> idr is also in the process of discussing an update to their charter.
> An important highlight in the text there will be precisely that.

I agree that IDR governs BGP and is expected to be its overall
architect, gatekeeper, primary caretaker. But IDR is not the *only*
group to influence aspects of the BGP Protocol.

> > GROW will also advise various working groups, specifically the IDR
> > and SIDROPS working groups, with respect to whether it is addressing
> > the relevant operational and routing security needs of networks, and
> > where appropriate, suggest course corrections or intervene. Finally,
> > operational requirements developed in GROW can also be used by any
> > new working group charged with standardizing a next generation
> > inter-domain routing protocol.
> 
> I don't think I understand what you mean by "suggest course
> corrections or intervene".  The current Charter ends this sentence
> with "suggest course corrections", what is the meaning/intent of
> "intervene"?  How does that look as a WG?

As an example RFC 8212 comes to mind.

I would like to suggest that we have a phone call with the IDR and GROW
chairs, you, and Warren, to have a dialogue to explore what what is on
people's minds and how we want to express that in charters.

> > Jul 2021 - "Devise a BGP Community Description System" to IESG
> 
> Maybe this is explained somewhere else (??)...what is that?  Is it
> simply best practices/recommendations on how to structure the contents
> of communities, or something else?

Over time it has come up a couple of times that it would be beneficial
to have a framework that allows operators to inform each other what
the semantics are of locally significant BGP communities (of any
flavor). This morning I interjected the idea
https://mailarchive.ietf.org/arch/msg/grow/8k5gaWqU1fB4ItlRASv5Q7mUiUM,
no further documentation exists other than in our memories.

In other words: a way to programmatically tell each other that
"Community 1" means X and "Community 2" means Y in NTT's network, and in
AT's network it is the reverse. I envision we can devise a mechanism
to map semantics to integers. This is not work about 'on the wire'.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] Information model for BGP Communities (Was: Proposed updates to GROW charter)

[Job Snijders]

Forking this thread.

On Fri, Nov 22, 2019 at 03:44:26AM +, thomas.g...@swisscom.com wrote:
> Very good input regarding „Devise a BGP Community Description System
> to IESG.
> 
> I think a YANG informational BGP community modell might be the right
> thing to do. I would volunteer to support such an approach.
> 
> I think it is good to keep the charter generic. I like your proposal.
> 
> I would be interested to know if others on the mailing list share my
> opinion on using YANG information model.

I would suggest to talk technology specifics in a new thread, and would
also like to suggest we first get a better handle on the goal and
problem space definition. This probably is a quite large project.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

On Fri, Nov 22, 2019 at 1:58 AM Jeffrey Haas  wrote:
>
> On Fri, Nov 22, 2019 at 01:44:03AM +0000, Job Snijders wrote:
> > Goals
> > * Provide stewardship and maintenance for the Multi-Threaded Routing 
> > Toolkit (MRT)
>
> I think you may wish to narrow the scope of this to the file format of that
> name.
>
> I don't really believe you intend that the working group pick up maintenance
> of the old code of that name.

Correct.

Reworded: "Provide stewardship and maintenance for the Multi-Threaded
Routing Toolkit (MRT) Routing Information Export Format"

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

Dear all,

Below is a revision of the charter proposal.

Kind regards,

Job

Charter for GROW Working Group
===

The Border Gateway Protocol (BGP) is fundamental to the operation of the
Internet. In recent years, occurrences of BGP related operational issues
have increased, and while overall understanding of the default-free
routing system has improved, there is still a long and growing list of
concerns. Among these are routing table growth rates, interaction of
interior and exterior routing protocols, dynamic properties of the
routing system, and the effects of routing policy on both the size and
dynamic nature of the routing table. In addition, new and innovative
uses of BGP, such as the use of BGP as a signaling protocol for some
types of Virtual Private Networks, have created new and unexpected
operational issues.

The purpose of the GROW is to consider the operational problems
associated with the IPv4 and IPv6 global routing systems, including but
not limited to routing table growth, the effects of the interactions
between interior and exterior routing protocols, and the effect of
address allocation policies and practices on the global routing system.
Finally, where appropriate, the GROW documents the operational aspects
of measurement, monitoring, policy, security, and VPN infrastructures,
and safe default behavior of implementations.

GROW will also advise various working groups, specifically the IDR and
SIDROPS working groups, with respect to whether it is addressing the
relevant operational and routing security needs of networks, and where
appropriate, suggest course corrections or intervene. Finally,
operational requirements developed in GROW can also be used by any new
working group charged with standardizing a next generation inter-domain
routing protocol.

Goals
=

* Develop and document Best Current Practises for operations in the
  Internet routing system.
* Develop and document the operational aspects of securing the Internet
  routing system including management of filtering and routing leaks.
* Analyse, document and provide best practice characteristics of running
  BGP at large scale
* Provide analysis, feedback and assistance for other IETF working
  groups when their subject matter impacts on the global Internet
  routing ecosystem.
* Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP)
* Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit 
(MRT)

Milestones
==

Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
Apr 2020 - "BMP Peer Up Message Namespace" to IESG
Jun 2020 - "Revision to Registration Procedures for Multiple BMP Registries" to 
IESG.
Oct 2020 - "Document negative consequences of de-aggregating received routes 
for traffic engineering purposes" to IESG
Jan 2021 - "A BCP on using IRR and RPKI data to improve filtering of BGP 
peering sessions" to IESG or via "Evolving Documents"
Mar 2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to 
IESG.
Jul 2021 - "Devise a BGP Community Description System" to IESG

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Proposed updates to GROW charter

[Job Snijders]

Dear all,

On Mon, Oct 28, 2019 at 07:21:13PM +, Job Snijders wrote:
> Milestones
> ==
> 
> Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
> Feb 2020 - "BMP Peer Up Message Namespace" to IESG
> Apr 2020 - "Revision to Registration Procedures for Multiple BMP Registries" 
> to IESG.
> Jul 2020 - “Document negative consequences of de-aggregating received  routes 
> for traffic engineering purposes” - to IESG
> Nov 2020 - "TLV support for BMP Route Monitoring and Peer Down Messages" to 
> IESG.
> Jan 2021 - “A BCP on using IRR and RPKI data to improve filtering of BGP 
> peering sessions” to IESG or via “Evolving Documents”

Perhaps as a milestone we can also add an effort to create a mechanism
to allow mapping integer values in BGP {Classic, Extended, Large, Wide}
Communities to semantics by devising a system to express equivalence
relations for use in Internet inter-domain routing.

The above is a fancy way of saying that documentation like
https://www.us.ntt.net/support/policy/routing.cfm is not anywhere close
to being programmatically interpretable, and perhaps we can do better.

In a way RPSL was an attempt to address the problem space, but now in
2019/2020 the solution space maybe has expanded, and we now have a
better understanding of what worked well in RPSL and what didn't.

I'd like to add: September 2020 - "Devise a BGP Community Description System"

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-grow-bmp-adj-rib-out

[Job Snijders]

Thanks for the heads-up!

On Mon, Nov 4, 2019 at 14:18 IETF Secretariat  wrote:

> Dear Tim Evens, Serpil Bayraktar, Paolo Lucente, Kevin Mi, Shunwan Zhuang:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "Support
> for
> Adj-RIB-Out in BGP Monitoring Protocol (BMP)"
> (draft-ietf-grow-bmp-adj-rib-out) was submitted to the IETF Secretariat on
> 2019-11-04 and has been posted on the "IETF Page of Intellectual Property
> Rights Disclosures" (https://datatracker.ietf.org/ipr/3846/). The title of
> the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
> related to draft-ietf-grow-bmp-adj-rib-out"
>
>
> Thank you
>
> IETF Secretariat
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow