[GROW]Fwd: [Idr] WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/

[Jeffrey Haas]

+grow/sidrops

Please note that while the bulk of the work for the draft, "don't use as-sets" 
has long been a BCP, this draft makes recommendation for how aggregation is 
done and the AS_PATH as used for RPKI purposes.  Your operational scrutiny is 
appreciated in this last call.

-- Jeff


> Begin forwarded message:
> 
> From: Susan Hares 
> Subject: [Idr] WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 
> to 7/
> Date: July 8, 2024 at 9:35:43 PM EDT
> To: "i...@ietf.org" 
> 
> This begins a 2 week WG LC for
> draft-ietf-idr-deprecate-as-set-confed-set-14.txt
> https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/ 
> 
>  
> All authors should respond to this email with an IPR statement.
>  
> Here is a short summary of why this document is:
>  
>BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
>AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol
>(BGP).  This document advances that recommendation to a standards
>requirement in BGP; it proscribes the use of the AS_SET and
>AS_CONFED_SET path segment types in the AS_PATH. 
>  
> FYI the verb proscribe means:
> forbid, especially by law.
> denounce or condemn.
>  
> It is a complex English word, but it fits the document.
> One similar word is “prohibit”.
>  
> Questions to consider in your comments:
>  
> Is now the time to proscribe AS_SETs and
> AS-CONF_SET path segments types in AS_PATH?
>  
> Is the document clear and ready for standardization?
>  
> Both Keyur and I wrote shepherd reports,
> so we’ll post a joint shepherd report.
>  
> Our comments focus on the clarity of the document.
>  
> Does this help BGP security in the network?
>  
>  
> Cheers, Sue 
>  
>  
>  
> ___
> Idr mailing list -- i...@ietf.org 
> To unsubscribe send an email to idr-le...@ietf.org 
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

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

[Jeffrey Haas]

Grow Chairs,

We saw some light support for the draft, but support.

What's the consensus on adoption?  Yay? Nay?  Need more input?

-- Jeff


> On Apr 29, 2024, at 5:54 PM, Job Snijders  
> wrote:
> 
> 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

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

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

[Jeffrey Haas]

Perhaps address the points raised here:
https://mailarchive.ietf.org/arch/msg/grow/XdDA44MyC-SRbyWtvOtdGd9ESFg/ 


-- Jeff


> On Apr 9, 2024, at 5:03 AM, Michael McBride  
> wrote:
> 
> Hi Job,
>  
> Please let us know if there is anything needed to help progress this draft.
>  
> Thanks,
> mike
>  
>  
> From: GROW mailto:grow-boun...@ietf.org>> On Behalf 
> Of Michael McBride
> Sent: Wednesday, February 7, 2024 11:20 PM
> To: David Farmer mailto:far...@umn.edu>>
> Cc: grow@ietf.org 
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt
>  
> Really appreciate the comments David, very helpful.
>  
> I incorporated all of your additional suggestions (added sentence to security 
> section, created informational references section, moved links to 
> informational section).
>  
> Back to you Job.
>  
> Thank you.
> mike
>  
>  
> From: David Farmer mailto:far...@umn.edu>> 
> Sent: Wednesday, February 7, 2024 7:21 AM
> To: Michael McBride  >
> Cc: grow@ietf.org ; Job Snijders  >
> Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-09.txt
>  
> Also, the links to the articles "Geoff Huston's Path Prepending in BGP" and 
> "Excessive AS Path Prepending" should be informational references instead of 
> embedded links.
>  
> Thanks
>  
> On Wed, Feb 7, 2024 at 9:13 AM David Farmer  > wrote:
> Speaking of informational references, all the references are normative. That 
> doesn't seem correct. The references to RFC 5398, RFC 5738, and RFC 8195 seem 
> to be informational references, in my opinion.
>  
> Thanks
>  
> On Wed, Feb 7, 2024 at 9:03 AM David Farmer  > wrote:
>  
>  
> On Wed, Feb 7, 2024 at 7:54 AM Job Snijders  > wrote:
> 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/ 
> 
>  
>  
> Job, thanks for the pointer to the update of 7454. Given that it already 
> includes references to this document, that will ensure readers of it know 
> about this document. Which is the purpose of including the Updates metadata 
> header.
>  
> I guess my final thought on the subject is whether there should be an 
> informational reference to RFC 7454, maybe in the security considerations 
> section. 
>  
> Here is a suggestion: Add a new final paragraph to the security 
> considerations section;
>  
> For a more comprehensive discussion of BGP Operations and Security, see 
> [RFC7454].
>  
> Do with it what you will.
>  
> Thanks.
> 
>  
> -- 
> ===
> David Farmer   Email:far...@umn.edu 
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> === 
> 
>  
> -- 
> ===
> David Farmer   Email:far...@umn.edu 
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> === 
> 
>  
> -- 
> ===
> David Farmer   Email:far...@umn.edu 
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> === 
> ___
> GROW mailing list
> GROW@ietf.org 
> https://www.ietf.org/mailman/listinfo/grow 
> 
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Jeffrey Haas]

> On Jun 8, 2024, at 11:54 AM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> Some of us may remember this (including Sue and Jeff).  Jakob Heitz, I, and 
> others have proposed/presented (in the IDR WG) the idea of a range of 
> IANA-registered 4-octet ASN values for the Global Admin field to classify BGP 
> Well Known Large Communities (WKLC).
> See: https://datatracker.ietf.org/doc/draft-heitz-idr-wklc/  [1]
> 
> The above draft was motivated in part by the following GROW WG draft's 
> request plus possible other use cases for WKLC:
> https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/
>   [2]
> 
> Our idea was critiqued for requesting 64M 4-octet ASN values to be set aside 
> by IANA for WKLC. That is only 64 million out of the 4 Billion (a fraction 
> 0.015) 4-octet ASNs. This can be reduced easily to 256K out of the 4 Billion 
> (a fraction 0.6) if that is acceptable. There would be 9 octets available 
> in the WKLC for the data part. The 256K number can be further reduced to 1K 
> if desired (with 8 octets available in the WKLC for the data part). 
> 
> Details can be found in the above cited draft [1].  We can discuss further 
> the possibilities if this approach gets some traction.  Thanks.

Please let the proposal stay dead.  Carving up the globally visible BGP AS 
space with too many "this is special" numbers is a bad idea.



-- Jeff

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: well known large communities

[Jeffrey Haas]

[Not a specific gripe at you, Nick.]

> On Jun 7, 2024, at 6:45 PM, Nick Hilliard  wrote:
> 
> [moving this to a new thread as it's unrelated to 
> draft-ietf-grow-ixp-ext-comms]
> 
> Robert Raszuk wrote on 07/06/2024 22:29:
>> True. But we there is clear opportunity to define those scoped for IXP use 
>> case. 
>> 
>> This is BCP so IMO good place to encourage using common encoding for most 
>> common needs. 
> 
> I'm not convinced this is a good plan. The semantics of the existing WKCs 
> have turned out to be unexpectedly complex in production environments, and 
> the semantics for candidate route server WKCs that have been discussed by RS 
> operators are a good deal more so. There have been proposals in the past 
> about this, but none have ended up with rigorous definitions or sample code.

Far more importantly, "well known" needed to have the semantics baked into the 
spec at the beginning.

The torches and pitchforks operator crowd that rammed through large communities 
in the current form weren't interested in slowing down and discussing how 
that'd work.

Thus, there is no such thing and the term should simply stop being used in this 
fashion.  

At best, a registry could be set aside for entries from a specifically 
allocated AS number and implementors can get special semantics added to their 
code for the specs over time. Not so much "well known" (and generally 
supported) as it becomes registered.

When it finally gets around to happening, I find it likely that either AS 65535 
or 4294967295 get used.  

-- Jeff (I assert no IPR over this.)

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt

[Jeffrey Haas]

There is no such thing as a well known large bgp community. JeffOn Jun 7, 2024, at 15:51, Robert Raszuk  wrote:Hi Job/WG,Reading the document I have a feeling/suggestion that perhaps this is a very good time now to define few IXP focused well known Large Communities such that most often signalled policies between RS and their clients are well defined and not random among IXPs. That may also in fact encourage faster migration to LCs from Extended Commuities. Thx a lot,RobertOn Fri, Jun 7, 2024 at 9:39 PM Job Snijders 40fastly@dmarc.ietf.org> wrote:Thanks David, we will incorporate this in the next revision On Fri, 7 Jun 2024 at 21:15, David Farmer 40umn@dmarc.ietf.org> wrote:I reviewed the draft;The Abstract and Introduction says, "It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers."However, the document no longer calls for any direct actions by ISPs. Obviously, the actions recommended for IXPs will impact the ISPs using IXPs. However, the statements above imply direct actions by ISPs in addition to IXPs, not indirect impacts on ISPs from IXP actions.You should probably rephrase the above statements to refer to indirect impacts on ISPs unless you expect ISPs to take other direct actions, and if you do, those other actions need to be more clearly stated.Thanks.On Wed, Jun 5, 2024 at 11:09 AM  wrote:Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now available. It is a
work item of the Global Routing Operations (GROW) WG of the IETF.

   Title:   Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers
   Authors: Job Snijders
            Stavros Konstantaras
            Mo Shivji
   Name:    draft-ietf-grow-ixp-ext-comms-00.txt
   Pages:   5
   Dates:   2024-06-04

Abstract:

   This document outlines a recommendation to the Internet operational
   community to avoid the use of BGP Extended Communities at Internet
   Exchange Point (IXP) Route Servers.  It includes guidance for both
   the Internet Service Provider side peering with Route Servers and
   IXPs operating Route Servers.  This recommendation aims to help the
   global Internet routing system's performance and help protect Route
   Server participants against misconfigurations.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-ixp-ext-comms-00

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
-- ===David Farmer               Email:far...@umn.eduNetworking & Telecommunication ServicesOffice of Information TechnologyUniversity of Minnesota   2218 University Ave SE        Phone: 612-626-0815Minneapolis, MN 55414-3029   Cell: 612-812-9952=== 
___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

___GROW mailing list -- grow@ietf.orgTo unsubscribe send an email to grow-le...@ietf.org___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Request for WGLC for draft-ietf-idr-deprecate-as-set-confed-set

[Jeffrey Haas]

https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set

[Speaking as an individual contributor.]

IDR Chairs,

The authors of draft-ietf-idr-deprecate-as-set-confed-set would like to request 
Working Group last call for this document.

Since the matter of BGP aggregation has impacts on Internet operations and RPKI 
validation of BGP routes, grow and sidrops are copied on this note and are 
requested to be included in the WGLC when it is scheduled.

Thanks.

-- Jeff (for the Authors)

Internet-Draft draft-ietf-idr-deprecate-as-set-confed-set-14.txt is now
available. It is a work item of the Inter-Domain Routing (IDR) WG of the IETF.

   Title:   Deprecation of AS_SET and AS_CONFED_SET in BGP
   Authors: Warren Kumari
Kotikalapudi Sriram
Lilia Hannachi
Jeffrey Haas
   Name:draft-ietf-idr-deprecate-as-set-confed-set-14.txt
   Pages:   15
   Dates:   2024-05-05

Abstract:

   BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
   AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol
   (BGP).  This document advances that recommendation to a standards
   requirement in BGP; it proscribes the use of the AS_SET and
   AS_CONFED_SET path segment types in the AS_PATH.  This is done to
   simplify the design and implementation of BGP and to make the
   semantics of the originator of a BGP route clearer.  This will also
   simplify the design, implementation, and deployment of various BGP
   security mechanisms.  This document updates RFC 4271 by deprecating
   the origination of BGP routes with AS_SET (type 1) and also updates
   RFC 5065 by deprecating the origination of BGP routes with
   AS_CONFED_SET (type 4) AS_PATH segments.  Finally, it obsoletes RFC
   6472.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/ 
<https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/>

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-14
 
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-14>

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-deprecate-as-set-confed-set-14
 
<https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-deprecate-as-set-confed-set-14>

___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

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

[Jeffrey Haas]

On Sun, Mar 17, 2024 at 12:24:27AM +, Job Snijders wrote:
> 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?

That's a largely correct observation, and overlapping debate partially
covered by https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/

Tersely: It's ambiguous in the base extended bgp specification whether
you're allowed to "originate" a non-transitive extended community into an
adjacent AS.  RSes are one of the perfect cases for non-transitive
origination.  

That said, it's not the critical bit of my opinion about extended
communities at IXPs.

> 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

I'll read this in detail later, but at a quick scan I'm generally supportive
of the high level points I'm seeing in it.

That said, it's another place where scare text about the "memory" that
communities take is used.  If you're on an implementation that is that poor
about communities for this to be a primary consideration... that's
unfortunate.

That said, cleaning up communities to reduce the clutter in your table that
also have security considerations is quite reasonable.

-- Jeff

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

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

[Jeffrey Haas]

On Sat, Mar 16, 2024 at 11:54:10PM +, Job Snijders wrote:
> 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

Thanks for the clarifications.  I think with these clarifications and
further thought my stance moves to "mildly don't support adoption".  But
there's perhaps still room for refinement to change my mind.

The main motivation of the document seems to be to say "don't use extended
communitites to signal RS behavioral operations".  I'm supportive of that.

What the document actually does say is:
"Operators of Internet Exchange Route Servers are RECOMMENDED to scrub
Extended Communities in both inbound and outbound directions."

In other words, get involved in throwing away someone else's stuff.
Whether scrub is intended to mean "selectively filter" vs. "throw away
indiscriminately" is ambiguous in the current text.

While some of the motivation is to limit the leaking of VPN-signaling
excrement that has left an appropriate scope, extended communities are a
general purpose mechanism that gets leveraged for general purpose features,
and not exclusively is intended for VPN purposes.

If the proposal would be updated to recommend specific extended community
types and subtypes to filter, I'd be supportive of that.  But if the
proposal is to filter all extended communities, I'm not supportive of that.

FWIW, such filtering practices are a good input for the bcp-194-bis work.

-- Jeff

___
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

[Jeffrey Haas]

Stavros,

On Fri, Mar 15, 2024 at 09:28:19AM +, Stavros Konstantaras wrote:
> Thank you very much for your comment. As Job said, the draft is targeting the 
> Route Server infrastructure of Internet Exchange Points, but do you believe 
> that this is something that needs further clarification in the draft?

The changes for -01 does help tighten the scope of the document.  Thanks for
getting that addressed.

> If by build-in scoping you are referring to the definitions of Global/Local 
> administrator, truth is that is not taken into consideration in such 
> deployments.

I'm specifically addressing the extended community "transitive" bit.  This
can permit things that are signaled via the IXP route server to be dropped
at the service provider's ASBRs.

> 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?

I have some more general comments that I'll address in reply to Job.

-- Jeff

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

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

[Jeffrey Haas]

Job,

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.

-- Jeff

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

Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00

[Jeffrey Haas]

Jinming Li,


> On Feb 28, 2024, at 2:37 AM, 李金铭  wrote:
> For the first comment, our reference to "route threshold" in the draft 
> only includes routes in RIB-IN that are rejected due to configuration 
> limitations. Which is the same as the latter you mentioned in your email.
> 
> The "license-customized route threshold" count is consistent with the 
> above considerations, and vendor licenses are sometimes updated at the 
> request of network operators, we wanted to define a counter to monitor such 
> changes.
> 
> Therefore, it is reasonable to define a 64-bit counter "gauge" to measure 
> the above changes.
> 
> 
You will want to clarify the text to say "routes that are accepted into the 
rib-in, but not eligible for installation in the loc-rib".

> For the as-path length threshold, The reference here is intended to 
> clarify the definition of AS-Path from RFC4271,not threshold lengths. 
> Obviously there is some ambiguity in the current formulation, and I will 
> update the description in a later version.
> 
> 

Thanks.
> The RPKI counter mentioned in the draft only focuses on ROA query 
> results. Since the RPKI action changes caused by RFC8893 do not involve query 
> results, there is no immediate impact on the counter. In any case, we will 
> keep an eye on it.
> 
> 
The place this can impact is whether rpki reject procedures are applied on 
egress or not.

If RFC 8893 is not implemented by the router, the counters will typically 
reflect rpki validation applied only at the rib-in level.

If RFC 8893 is implemented, the statistics will differ for routes that undergo 
as-path transformations that render them rpki-invalid, or potentially change 
them to valid from invalid.

My recommendation is to omit the rib-out counters unless RFC 8893 is 
implemented.

-- Jeff

> 
> 
> Best regards,
> 
> Jinming Li
> 
> _______
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 
> 
> 邮件原文
> 发件人：Jeffrey Haas  
> 收件人："李金铭" 
> 抄　送: grow  
> 发送时间：2024-02-28 03:30:59
> 主题：Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00
> 
> Jinming Li,
> 
> A few comments on your proposed counters:
> 
> Are your "route threshold" counters intended to cover route discards or only 
> routes that are retained in the adj-ribs-in and automatically rejected 
> because they exceed a configured limit?
> 
> If the case is intended to cover discards as well, a gauge is probably not 
> the correct type for this.  You can only keep a gauge for state that you know 
> comes and goes.  Discards can be counted (counter type), but not tracked on a 
> per-prefix basis without keeping the prefix.
> 
> For your license restriction count, I understand the use case.  However, I 
> have some concerns that the counter is clear in a vendor neutral fashion.  
> And, similar to the comments above, if this is intended to cover cases where 
> routes are discarded along with the case for keeping the routes a counter may 
> be a more appropriate type.
> 
> For the as-path length threshold, please restructure the reference to RFC 
> 4271.  As written, it looks like the citation is intending to say such 
> threshold lengths are a feature of that RFC.  They are not.
> 
> The RPKI counters will be popular!  Please consider socializing these 
> counters with the sidrops group.
> 
> Please also be aware that for adj-ribs-out for rpki that RFC 8893 might 
> change the behavior somewhat.
> 
> -- Jeff
> 
> 
> 
> 
> On Feb 26, 2024, at 8:24 PM, 李金铭  <mailto:lijinm...@chinamobile.com>> wrote:
> 
> Hi all,
> 
> 
>  
> We have submitted a new Internet-Draft draft-liu-grow-bmp-stats-reports-00 
> which is about BMP Statistics Types.
> 
>  
> As the BGP protocol continues to expand, more and more functional features 
> are implemented through the BGP protocol, which adds more event information 
> to monitor these functional features.This document lists some new statistics 
> types to update RFC 7854 for growing BGP features.
> 
> The New BMP statistics types are used by the monitoring station to observe 
> more interesting events that occur on the router.  
> 
> New types Include RIB-IN Statistics Types for Route Threshold, RIB-IN/RIB-OUT 
> Statistics Types for AS-Path Length Threshold, and RIB-IN/RIB-OUT Statistics 
> Types for Route Origin Validation. 
> 
>  
> If you have some comments and suggestions, please provide feedback.
> 
>  
> The IETF datatracker status page for this Internet-Draft is:
> 
> https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/ 
>

Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00

[Jeffrey Haas]

Jinming Li,

A few comments on your proposed counters:

Are your "route threshold" counters intended to cover route discards or only 
routes that are retained in the adj-ribs-in and automatically rejected because 
they exceed a configured limit?

If the case is intended to cover discards as well, a gauge is probably not the 
correct type for this.  You can only keep a gauge for state that you know comes 
and goes.  Discards can be counted (counter type), but not tracked on a 
per-prefix basis without keeping the prefix.

For your license restriction count, I understand the use case.  However, I have 
some concerns that the counter is clear in a vendor neutral fashion.  And, 
similar to the comments above, if this is intended to cover cases where routes 
are discarded along with the case for keeping the routes a counter may be a 
more appropriate type.

For the as-path length threshold, please restructure the reference to RFC 4271. 
 As written, it looks like the citation is intending to say such threshold 
lengths are a feature of that RFC.  They are not.

The RPKI counters will be popular!  Please consider socializing these counters 
with the sidrops group.

Please also be aware that for adj-ribs-out for rpki that RFC 8893 might change 
the behavior somewhat.

-- Jeff




> On Feb 26, 2024, at 8:24 PM, 李金铭  wrote:
> 
> Hi all,
> 
> 
>  
> We have submitted a new Internet-Draft draft-liu-grow-bmp-stats-reports-00 
> which is about BMP Statistics Types.
> 
>  
> As the BGP protocol continues to expand, more and more functional features 
> are implemented through the BGP protocol, which adds more event information 
> to monitor these functional features.This document lists some new statistics 
> types to update RFC 7854 for growing BGP features.
> 
> The New BMP statistics types are used by the monitoring station to observe 
> more interesting events that occur on the router.  
> 
> New types Include RIB-IN Statistics Types for Route Threshold, RIB-IN/RIB-OUT 
> Statistics Types for AS-Path Length Threshold, and RIB-IN/RIB-OUT Statistics 
> Types for Route Origin Validation. 
> 
>  
> If you have some comments and suggestions, please provide feedback.
> 
>  
> The IETF datatracker status page for this Internet-Draft is:
> 
> https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/ 
> 
>  
> Best regards,
> 
> Jinming Li
> 
> 
> ___
> 
> 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

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

[Jeffrey Haas]

Job,

I support adoption for this draft and will be trying to proactively work with 
the author(s) on the content.  It's a valuable mechanism to be developed.  It 
likely should also be paired with a mechanism for consistent publication of the 
data.

-- Jeff


> On Dec 6, 2023, at 10:42 AM, Job Snijders  
> wrote:
> The author of draft-pels-grow-yang-bgp-communities asked whether the
> GROW working group could consider adoption of their internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.

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

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

[Jeffrey Haas]

Thanks, Job.

As a reminder from the presentation at IETF 118, it's the desire for the 
authors to iterate in short order to:
- Ask for adoption and WG review of the counter code points because we believe 
they're worth standardizing.
- Get code points assigned after a short period of review.
- Ship code and RFC!

Note for the archives: I am unaware of any IPR applicable to this draft.

-- Jeff

> On Dec 6, 2023, at 10:48 AM, 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

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

[Jeffrey Haas]

On Dec 6, 2023, at 10:45 AM, Job Snijders  
wrote:
> 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

I support adoption of this work.

-- Jeff

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

Re: [GROW] todo items from GROW @ IETF 118

[Jeffrey Haas]

Job,

On Mon, Nov 06, 2023 at 06:34:29PM +0100, Job Snijders wrote:
> The todo items I noted for myself:
[...]
> Call for working group adoption: draft-msri-grow-bmp-bgp-rib-stats

And as we discussed, we're hoping to figure out a pattern for reasonably
fast turn around on this item.  We want some review here to encourage
standardizing things, but we could move faster by doing first-come,
first-served code points.

Here's a proposal for boring "this draft has nothing other than BMP code
point requests for counters":

- The call is for adoption and REVIEW of the contents.  Perhaps it runs a
  little longer than the normal 2-ish week cycle done for a lot of drafts -
  maybe a month?
- If adoption/review succeeds, the chairs assist the authors in submitting
  the code point request as part of the early allocation procedures from the
  "standards required" pool. 
  +  Work on the semantics for the code points is then owned as a standard
 WG document and follows process.
  + Code can start!
  + TBD what's the exit criteria for RFC publication?  Shipping
implementation(s)?  No further discussion and the WG thinks this is
"done"?  
- If adoption fails, the authors can go off an request FCFS instead.

My suspicion is that in future some people will just grab FCFS and want to
"upgrade" them by documenting them in an RFC instead.  The process could
largely be the same as above, where if the WG agrees on the semantics and
publishes it as an RFC, the main change is the related update to IANA to
publish the RFC as a reference point.

-- Jeff

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

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

[Jeffrey Haas]

On Tue, Oct 24, 2023 at 01:34:17PM +0200, Job Snijders wrote:
> 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.

I think the work should be adopted.

Further comments for the authors on this version:

- The address selector is sufficient for ipv4, ipv6, but not ipv6 link-local
  addresses.
- The authors should consider what, if anything, should be done about BGP
  routes learned from non-BGP live speakers; e.g. APIs or static
  configuration.
- Probably a general comment on the TLV procedures over-all, the error
  handling for cases of conflicting information from the TLVs needs to be
  addressed.  For example, what if NLRI index 5 is present both in a group
  and individually and conflicting state is expressed.

-- Jeff

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

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

[Jeffrey Haas]

On Wed, Nov 01, 2023 at 02:48:36PM +0100, Luuk Hendriks wrote:
> That makes sense, but I am a bit on the fence about this TLV being
> optional and the fallback scenario. Is there enough incentive to
> implement this TLV on the router side, or will this be a nice idea on
> paper while in reality BMP station software will have to use the
> fallback 99.9% of the time so there is none of the envisioned benefit and
> perhaps even an increased computational cost (albeit small)?
> 
> Moreover, all of this applies to the Multiple Labels capability (TBD5)
> as well. When these both are optional, the BMP station has to check for
> their presence individually, and do the fallback trick for zero, one, or
> both of them. 

Moreover, for stuff coming as route-monitoring messages, the receiving BMP
speaker already had to get the capabilities as part of the peer-up
information and thus already had enough information to do the parsing.

The primary reason to do these things in each message is the presumption of
a completely stateless consumer.  If you're doing a distributed collector,
this is a nice to have behavior, but also one that can be generated as
metadata as part of such a collector's back-end.

-- Jeff

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

[Jeffrey Haas]

Job,

On Wed, Oct 25, 2023 at 12:57:08AM +0200, Job Snijders wrote:
> 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.

I support adoption of the draft.  The draft needs a lot of work.  A few
quick comments for the authors:

- As I'm reading it, the format is intended to be "per NLRI", where that
  NLRI may be a group, correct?  If so, how are things to be encoded when
  we're talking about the entire update? 
- Related: If we're sending a malformed update in the field, the ability to
  parse the NLRI may not be feasible.  This impacts not only whether the BGP
  PDU should come first or not, but also the prior comment about having the
  type "malformed update", perhaps with commentary; e.g. one or more string
  TLVs.  No indexed operations will be possible.
- Log action seems likely to say 'here's a trace message appropriate to this
  update'.  Is a string TLV for that forthcoming?
- While I agree with Thomas that the policy discard information is helpful,
  a simple string is unlikely to be quite enough.  Minimally I'd suggest
  relaxing the length limit to permit a better qualifier, or perhaps consider
  a vector of strings.  
  Juniper example, consider a policy "match-bad" where "term evil-guys" is
  the failure position where the "then reject" occurs.  (Or perhaps a new
  "then reject-and-complain".)  Should this be solely encoded as "match-bad"
  even when this may be tens of thousands of terms long?  Perhaps as
  "match-bad/evil-guys" in XPath style?  Etc.
- Validation failure is likely to need some level of overlap with validation
  in the path marking draft.

-- Jeff

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

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

[Jeffrey Haas]

As a correction, the proper URL for the WGLC is here:
https://mailarchive.ietf.org/arch/msg/idr/263_yrn_ZnNRokmUwgye7Id5mHo/

-- Jeff (also processing WGLC in BFD)

> On Apr 11, 2023, at 10:22 AM, Jeffrey Haas  wrote:
> 
> Grow WG,
> 
> The BGP YANG model is starting its Working Group Last Call in IDR.  Since 
> this model not only provides operational visibility into BGP, but provides 
> many base definitions for BGP that are likely to be utilized across other 
> IETF BGP technology YANG models, your review would be greatly appreciated.
> 
> A URL for the WGLC mail is here:
> https://mailarchive.ietf.org/arch/search/?q=bfd-unaffiliated%20ipr 
> <https://mailarchive.ietf.org/arch/search/?q=bfd-unaffiliated%20ipr>
> 
> Thanks!
> 
> -- Jeff (for the authors)
> 
>> Begin forwarded message:
>> 
>> From: "Dongjie (Jimmy)" mailto:jie.d...@huawei.com>>
>> Subject: WG Last Call on draft-ietf-idr-bgp-model-16
>> Date: April 10, 2023 at 10:17:26 PM EDT
>> To: "i...@ietf.org <mailto:i...@ietf.org>" > <mailto:i...@ietf.org>>
>> Cc: "idr-cha...@ietf.org <mailto:idr-cha...@ietf.org>" > <mailto:idr-cha...@ietf.org>>, "Dongjie (Jimmy)" > <mailto:jie.d...@huawei.com>>
>> Resent-From: mailto:alias-boun...@ietf.org>>
>> Resent-To: s...@ndzh.com <mailto:s...@ndzh.com>, ke...@arrcus.com 
>> <mailto:ke...@arrcus.com>, jh...@pfrc.org <mailto:jh...@pfrc.org>, 
>> jie.d...@huawei.com <mailto:jie.d...@huawei.com>
>> 
>> Hi WG, 
>>  
>> This begins the Working Group Last Call for "YANG Model for Border Gateway 
>> Protocol (BGP-4)", draft-ietf-idr-bgp-model-16. The draft could be found at: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16>. 
>>  
>> Since all the IDR chairs are coauthors of this document, I’m helping with 
>> this last call procedure. Please reply to the list with your comments. 
>> Considering this is a long document with a big YANG model, the last call 
>> will last for 4 weeks and conclude on Sunday, 7 May, 2023.
>>  
>> The authors are requested to state whether they are aware of applicable IPR 
>> related to this draft. Similarly, if others in the Working Group are aware 
>> of applicable IPR, please also disclose them.
>>  
>> People are encouraged to indicate whether there is implementation of this 
>> document. According to the IDR rule, at least two implementations will be 
>> required to advance the document.
>>  
>>  
>> Best regards,
>> Jie (on behalf of the IDR chairs)
> 

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

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

[Jeffrey Haas]

Grow WG,

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

A URL for the WGLC mail is here:
https://mailarchive.ietf.org/arch/search/?q=bfd-unaffiliated%20ipr

Thanks!

-- Jeff (for the authors)

> Begin forwarded message:
> 
> From: "Dongjie (Jimmy)" 
> Subject: WG Last Call on draft-ietf-idr-bgp-model-16
> Date: April 10, 2023 at 10:17:26 PM EDT
> To: "i...@ietf.org" 
> Cc: "idr-cha...@ietf.org" , "Dongjie (Jimmy)" 
> 
> Resent-From: 
> Resent-To: s...@ndzh.com, ke...@arrcus.com, jh...@pfrc.org, 
> jie.d...@huawei.com
> 
> Hi WG, 
>  
> This begins the Working Group Last Call for "YANG Model for Border Gateway 
> Protocol (BGP-4)", draft-ietf-idr-bgp-model-16. The draft could be found at: 
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-16 
> . 
>  
> Since all the IDR chairs are coauthors of this document, I’m helping with 
> this last call procedure. Please reply to the list with your comments. 
> Considering this is a long document with a big YANG model, the last call will 
> last for 4 weeks and conclude on Sunday, 7 May, 2023.
>  
> The authors are requested to state whether they are aware of applicable IPR 
> related to this draft. Similarly, if others in the Working Group are aware of 
> applicable IPR, please also disclose them.
>  
> People are encouraged to indicate whether there is implementation of this 
> document. According to the IDR rule, at least two implementations will be 
> required to advance the document.
>  
>  
> Best regards,
> Jie (on behalf of the IDR chairs)

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

[GROW] Fwd: RFC 4384 rejected errata, wrong call

[Jeffrey Haas]

At the request of Warren, making this observation in public.

-- Jeff


> Begin forwarded message:
> 
> From: Jeffrey Haas 
> Subject: RFC 4384 rejected errata, wrong call
> Date: January 30, 2023 at 11:03:39 AM EST
> To: grow-...@ietf.org
> 
> https://www.rfc-editor.org/errata_search.php?rfc=4384
> 
> I think Joel made the wrong call when he rejected the point about 0x0008 in 
> the diagrams should be 0x08.  I went here to report the exact same errata. :-)
> 
> -- Jeff

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

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

[Jeffrey Haas]

Job,

On Sun, Jan 29, 2023 at 02:41:30PM +0100, Job Snijders wrote:
> 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).

Excellent.  It's the hope of the authors that this document is largely done
and may progress to WGLC soon.

> > 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.

That said, progression in IDR is also about two interoperable
implementations.  It sounds like you have a portion of the document
implemented.  Please review the document further and perhaps see if you have
interest in getting the rest of the feature set complete.

In particular, I'm interested in hearing implementation analysis for the new
brief aggregation procedures.  Those are necessary to address a deficiency
in generating aggregate routes that are RPKI Origin stable.

-- Jeff

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

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

[Jeffrey Haas]

Job,

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].

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

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 22, 2022, at 4:26 PM, Robert Raszuk  wrote:
> 
> Generating those could be done by running RFD in "informational mode" ie. 
> without applying actual dampening. 

Logically, it would work.  Enjoy the overhead that brings. :-)

> As far as saturating the pipe - I do not see how that would happen if 
> implementation would be sending such counters every X minutes. 

Per-path stats basically mean you need to stream the entire rib during that 
time.  BMP users would more likely want to get their BGP update changes ahead 
of counters.

> I will look how easy/hard is to provide it in our BGP code base. However 
> question for this thread is if there is any interest to extend BMP to send 
> them to BMP receiver(s) ? 

Outside of a targeted diagnostic mode that would require user triggers, "this 
is the wrong tool". 

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

Tim,

Excellent points, especially with regard to non-RM messages.  Clarifying the 
intended behaviors would be good... and will certainly make a number of 
implementations non-conformant when the -bis is done.  The joys of IETF. :-)



> On Sep 22, 2022, at 8:02 PM, Tim Evens (tievens)  wrote:
> Not all BMP senders are not respecting the statement about “received time” 
> and instead are sending timestamps based on the BMP send time of the message.

And for some cases, it's unclear semantically what to do beyond "received".  I 
seem to recall some internal discussion at work about "what do we put here for 
loc-rib".  I can dig out the answers for the Working Group when we get to that 
part of the process.

> The other problem that we are running into is the BMP sender clock is not in 
> sync with the BMP receivers.  Either it’s a different clock source or 
> something else.  Regardless, it causes things to be out of sync, especially 
> when monitoring BGP churn/excessive updates/bad neighbors/etc.   Might be 
> good to clarify a bit more that the time transmitted in BMP header shouldn’t 
> really be used for churn/update floods/… Instead, BMP receiver should be 
> expected to add a timestamp that can be used for that.

We had conversations with a Certain Large Customer not only on not being able 
to use this for correlation due to state compression and internal timing 
artifacts as the routes moved through the pipeline.  We also had to have the 
conversation that our implementation only kept second-level granularity for 
this stuff.  Those conversations did eventually cause us to alter our 
implementation to include effectively an epoch for events occuring in the same 
second so that timestamps increased.  However, that "sub-second" data is a lie.

Clock synchronization for this sort of stuff is always a mess, even when NTP is 
involved.  The IEEE high precision time stuff can help in some circumstances, 
but that plumbing often is one step disconnected from the routing 
implementations.

(Why not just use a more precise timer in our code?  The short historical 
answer is the cost for an additional uint32 vs. memory scale wasn't a win for 
many customers.  The secondary answer is that we already didn't have strong 
faith in received route timestamps based on TCP artifacts anyway.  Who knows 
how long a given PDU was sitting between the sender and receiver queues before 
your recv() succeeded and you were able to start parsing the update.)

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

Tim,


> On Sep 22, 2022, at 8:02 PM, Tim Evens (tievens)  wrote:
> 
> When I wrote route-refresh, that was from the router/sender side, not BMP 
> receiver sending a route-refresh. BMP is still write-only.
>  
> There are use-cases for re-syncing the RIB to the BMP receiver.  Some of the 
> methods today are to clear the peer, request a route-refresh in, or to reset 
> the BMP feed. This is a bit intrusive to the router (sender) and BMP 
> receiver. Having to go to the router to request a refresh to the BMP server, 
> IMO, is still okay.  The problem is that control knobs for refresh are at the 
> BGP peer level, not BMP.  For Adj-RIB-In Pre-Policy, it makes sense to do 
> that on the peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn’t 
> really make sense.  Having a knob to initiate BMP side refresh would be very 
> nice and hopefully less intrusive.  

Thanks.  This is now clear.

> Regardless of the BMP server needing a refresh, a BMP server does not know 
> when someone has requested route-refresh IN at the peer level (maybe it was 
> requested for policy change, …) Instead, the BMP receiver, blindly, receives 
> a boat load of updates with no awareness that it was a new RIB dump or 
> controlled refresh. In this case, it would appear to be churn.  IMO, there is 
> value in having a message to signal the receiver that a refresh is coming, 
> followed by an EoR.  A PEER_UP could be used for this, but that is intrusive 
> and misuse of PEER_UP.

I think my concerns are in terms of incremental impact on existing BMP 
receivers.  Two thoughts come to mind about encoding:

1. A new BMP message type is used to signal a refresh for the appropriate 
logical view, and similarly that the end of rib markers that this thread was 
originally discussing would happen. :-)

2. Deliberate mis-use of peer-up.  One option is to add a new informational TLV 
to cover that this is a refresh.  For this point, the question to ask of 
receivers is what they would do if they received a peer-up when they already 
had state covering a session that is up.

A quick glance (but not thorough audit) of RFC 7854 is that it seems silent on 
what would happen if you got a redundant peer-up.

While I'd be generally inclined for the new message option, I could sort of see 
cases where existing BMP collectors might be happier using existing peer-up 
triggers for things.  But I could similarly see where some might consider it a 
flavor of state machine violation and may not be happy with it.

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 22, 2022, at 3:07 PM, Robert Raszuk  wrote:
> 
> Hi Jeff,
>  
> State compression for route-monitoring messages in BMP is common.
> 
> If you wanted perfect state, you would use route-mirroring mode, if the 
> implementation supported it.
> 
>  And why not use the churn counter. 

If your implementation supported such a thing.

Most implementations keep per-peer in/out updates + messages for supporting the 
BGP MIB.  Those help.

Per-prefix churn requires you to maintain at least some level of route state 
for that path.  That sort of state is kept as part of route flap damping, but 
RFD isn't as popular as it once was. (For good reasons.)

> 
> I could see it being quite useful even without BMP running at all. 
> And once available, sending it via BMP message would be pretty trivial. 

Very noisy, likely just contributing to saturating the pipe.

If it was put into the stats reports, you'd get stats reports in roughly the 
same amount as your RIB activity.

For stuff that can be hooked to rib-in state, the TLV feature can let you get 
the stuff as annotations... but the noise level of it probably doesn't help the 
analysis case terribly well.

> 
> I could think of three such counters: 
> 
> - "Number of received paths for a given net during the session" 

> - "Number of received withdraws for a given net during the session"

Per-prefix state won't scale nicely as stats report, and doesn't fit into one 
of the five logical rib views.  

> - "Number of next hop metric changes for registered next hops"

This one potentially scales well and would fit into a stats report.

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 21, 2022, at 10:29 AM, Maximilian Wilhelm  wrote:
> 
> Hey folks,
> 
> I think having the original timestamp of when a route was learned is
> valueable, even if theP BM session is set up later, or has flapped and
> is reestablished etc.  This was it's always possible to determine when
> a given prefix/path was learned.  If you want to have the time the
> informatione was learned via BMP it's also possible to use the current
> time then to store it into a TSDB.  So following the principle of always
> keeping the most options I think we should make sure the timestamp always
> represents the one where the BGP UPDATE happened.  As most (if not all?)
> routers already store that time / a route age, that information should
> already be available.

Also, I had thought the RFC was reasonably clear on this point:

   If the implementation is able to provide information about when
   routes were received, it MAY provide such information in the BMP
   Timestamp field.  Otherwise, the BMP Timestamp field MUST be set to
   0, indicating that time is not available.

"when routes were received".

But it's also clear about the MAY.

Time highlights below that part of the issue is that with the level of 
flexibility the field provides that it can make data from different routers 
incomparable.

> Anno domini 2022 Tim Evens (tievens) scripsit:
> 
>> Timestamp is another item we need to clarify in 7854bis. Some BMP senders 
>> send timestamps based on the actual received BGP update.  This may be days, 
>> weeks, etc. old from the time that the message is sent to BMP receiver. It 
>> has been a bit confusing for people to see timestamps that are old when they 
>> just received a RIB dump.

The field in BMP is for the BGP time carried in the BMP protocol.  The state 
described above is meta-data about a BMP receiver having received a given BGP 
route.

>> OpenBMP/PSQL maintains two timestamps, one is the DB insert time and the 
>> other is the BMP received timestamp.  For folks that are working with time 
>> series DBs to track/insert/maintain records using time, they may drop 
>> messages because they believe they are too old when in fact they are new.   
>> Basically, for those that are using timeseries DBs, they may have to use a 
>> new BMP received timestamp instead of the BMP header timestamp.

For timeseries purposes, it depends on what you're doing timeseries upon.  

If you're looking for route stability, the freshness of your BMP message is 
less interesting than the sending router's timestamp for when it got the route.

If you're looking for churn at an arbitrary epoch after you've synched your 
feeds, then the BMP message receive time may be preferable.

That said, given that the timestamps carried in BMP aren't guaranteed to mean 
the same things from implementation to implementation, normalizing the time can 
be a challenge.

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

Henk,


> On Sep 21, 2022, at 9:45 AM, Henk Smit  wrote:
> 
> Hi Robert,
> 
> > But this will hide BGP churn for a given NET to be detectable by BMP 
> > receiver. Is this a good thing ? 
> 
> The question is: how expensive is it to report everything bit-for-bit to the 
> BMP collector? 
> If you want to report everything, you have to store everything.
> Which will require bufferspace. How much? You don't know in advance. Might be 
> a lot. 

Considerable in some cases.  This is the core reason why BMP has distinct modes 
for route-monitoring (RFC 7854, §4.6) and route mirroring (RFC 7854, §4.7)

The state compression that happens for route-monitoring is normally a feature.  
However, it means that BMP in route-monitoring mode with state compression is 
problematic for diagnosing certain types of BGP Update churn.

In my experience, the bulk of customer needs are met with route-monitoring with 
state compression.

One level of compromise that the protocol enables, but there's no RFC-specified 
mechanism for control, is tracing subsets of BGP state verbatim via 
route-mirroring on a dynamic basis.  Instead of trying to shove the entire 
firehose of BGP from all of your feeds down the BMP drinking straw verbatim, 
use route-mirroring for targeted tracing.

Even then, there's possibility of slow TCP speakers or other forms of 
backpressure causing you to eventually have too much to buffer.

> The current way of doing things allows the BMP implementation on a router to 
> be pretty efficient. 
> When BGP receives routes, you store them in the BRIB. You don't store 
> anything special for BMP (expect maybe timestamps, or other meta-data). 
> When BMP on a router is going to send BMP updates, it just walks the BRIB, 
> and sees which NLRI/routes have not been sent to the collector yet. 
> BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP 
> session per NLRI/route). 

Roughly, yes.  Maybe a bit more state if you want to do bgp-style state 
suppression. (You have to track what you previously sent.)

The rib-out feed is considerably uglier.

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 21, 2022, at 7:42 AM, Zhuangshunwan 
>  wrote:
> 
> Hi Tim and All,
>  
> I think the idea of a "BMP route refresh" would be appreciated,  it will 
> helps keep the information synchronized between the BMP Server and the BMP 
> Client.

Would someone clarify what they mean by a bmp route refresh?

The BMP protocol was intentionally designed as write-only.  

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 21, 2022, at 1:52 AM, Robert Raszuk  wrote:
> 
> Hi Paolo,
>  
> A-la: there is multiple updates related to a certain NLRI by when a BMP 
> message is to be sent out, let's state-compress (ie. not send out) those 
> that were already obsoleted by a subsequent update.
> 
> But this will hide BGP churn for a given NET to be detectable by BMP 
> receiver. Is this a good thing ? I am not sure. It is a loss of information 
> to me. 

State compression for route-monitoring messages in BMP is common.

If you wanted perfect state, you would use route-mirroring mode, if the 
implementation supported it.

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

> On Sep 14, 2022, at 2:36 PM, John Scudder  wrote:
> 
> That’s cleaner but now the monitoring station has to go to the (minor?) 
> trouble of keeping track of EoRs and reconciling them against AFs supported 
> on the session. 
> 
> Yet another option would be to introduce a BMP-specific “end of initial BMP 
> convergence” message that does what the current text suggests — a single 
> message to say “done". That one smells the best to me, at the moment. It’s 
> also the most intrusive.

Speaking as someone who soaks in how some customers use BMP, the per-AFI/SAFI 
end of rib is a feature rather than a bug.

BMP already serves to push the firehose of a router down a drinking straw.  
Being able to tell you're done with one address family is helpful to let some 
things come to convergence rather than waiting on everything.

The other headache of the single "I'm done" bit is the consequence on trying to 
get all of the per-AFI/SAFI queues to be done at the same time.  For example:
IPv4 unicast is done, no EoR is sent.
IPv6 unicast starts doing its work.
IPv4 unicast has more churn go through
IPv6 unicast is done, no EoR is sent.
System needs to go back to trying to get IPv4 unicast done to send EoR.  Pray 
that nothing else changes...

-- Jeff

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

Re: [GROW] [Idr] RFC7854: EoR

[Jeffrey Haas]

+grow, where BMP is standardized.

On Sun, Sep 11, 2022 at 09:45:29PM +0200, Vincent Bernat wrote:
> Hey!
> 
> In 3.3:
> 
>Once it has sent all the
>routes for a given peer, it MUST send an End-of-RIB message for that
>peer; when End-of-RIB has been sent for each monitored peer, the
>initial table dump has completed.  (A monitoring station that only
>wants to gather a table dump could close the connection once it has
>gathered an End-of-RIB or Peer Down message corresponding to each
>Peer Up message.)
> 
> The wording looks like the EoR is sent once per peer. However, an
> EoR is AFI/SAFI-dependent. Therefore, it is unclear if any EoR
> should signal the end of the initial table dump or if one EoR per
> family is needed.
> 
> Looking at JunOS implementation, I see one EoR per family.

It is indeed per family in Juniper's implementation for exactly the reasons
you mention.

If the authors agree that was the intent, it's minimally worth an RFC Errata
covering the point.

-- Jeff

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

Re: [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

[Jeffrey Haas]

Michael,


> On Sep 5, 2022, at 4:52 AM, Scharf, Michael  
> wrote:
> The authors have published version -08 to address feedback from various 
> reviewers, including your one.
>  
> As you can see at the page 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-08 
> , we added a 
> typedef for MSS and leafs for MSS and PMTUD. Please review this change and 
> let us know if this works for you.

Those changes address my comments.  Thanks!

> We have _not_ added further nodes, as the use case is not clear and there has 
> been no specific suggestion how the draft should be updated. As mentioned 
> before, this document does not try to comprehensively model all potential 
> parameters of a TCP stack. 

It's YANG.  Unlike MIBs, as long as the structure is well-designed, it can be 
extended later to address deficiencies.

Thanks for the work.

-- Jeff

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

[Jeffrey Haas]

I support adoption.

The draft's YANG is already in better shape than some stuff that's been in 
other working groups for a few years. :-)

-- Jeff


> On Aug 25, 2022, at 10:20 AM, 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 mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

[Jeffrey Haas]

Mahesh,

> On Aug 23, 2022, at 3:03 PM, Mahesh Jethanandani  
> wrote:
> 
>>> In addition, I have now also checked the OpenConfig YANG models, and they 
>>> also have ways to set the MSS, for instance:
>>> 
>>>leaf tcp-mss {
>>>  type uint16;
>>>  description
>>>"Sets the max segment size for BGP TCP sessions.";
>>>}
>> 
>> An example above, where a typedef for the uint16 might be helpful.
> 
> Not clear on why you would like to see a typedef rather than a definition for 
> MSS node as suggested by Michael. Or did you mean to put a range for the MSS 
> value?

For individual instances implementing the MSS, you'll want a leaf.

The purpose of a typedef is having each of the places where MSS configuration 
or operational state is used have a consistent type/constraint and perhaps 
pointer into the TCP specs.

That way, as a theoretical example, you don't define MSS in one model as uint16 
and another as uint32 with a range restriction - which might be how someone's 
implementation does it.

-- Jeff

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

Re: [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

[Jeffrey Haas]

Michael,

On Fri, Aug 19, 2022 at 08:39:14AM +, Scharf, Michael wrote:
> > From: Jeffrey Haas 
> >
> > The underlying issue that Camilo is trying to raise isn't so much
> > interface-specific as it is session specific.  Consider the following
> > examples:
> > 
> > https://www.juniper.net/documentation/us/en/software/junos/bgp/topics
> > /ref/statement/tcp-mss-edit-protocols-bgp.html
> > https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/bgp/73x/b-bgp-cg-
> > 8k-73x/implementing-bgp.html#task_sq1_xdk_4jb
> 
> Thanks for the pointers. Actually, I have looked at several router operating 
> systems (including also Nokia SROS) when preparing the first individual 
> versions of this draft.
> 
> For what it is worth, an old summary shown during IETF 105 (see 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01)
>  includes both router and host operating systems as examples.
> 
> In addition, I have now also checked the OpenConfig YANG models, and they 
> also have ways to set the MSS, for instance:
> 
> leaf tcp-mss {
>   type uint16;
>   description
> "Sets the max segment size for BGP TCP sessions.";
> }

An example above, where a typedef for the uint16 might be helpful.

> leaf mtu-discovery {
>   type boolean;
>   default false;
>   description
> "Turns path mtu discovery for BGP TCP sessions on (true)
> or off (false)";
> }
> 
> The details, i.e., whether to configure a maximum value for the MSS as system 
> default, per network interface, or per (BGP) neighbor may be specific to the 
> system, but in general most router and host operating systems have ways to 
> influence the MSS.

And thus a motivation to discuss this in the context of the broader IETF
YANG work.  The IETF BGP module similarly covers MSS.  GROW is looking to
copy similar patterns.

> So, this clearly shows that the MSS might be relevant. But the reality is a 
> bit more complex:
> 
> 1/ The MSS value is per direction of a TCP connection, and the effective send 
> MSS (called Eff.snd.MSS in RFC 9293) can be different from the receive MSS 
> (called RMSS in RFC 9293)
>
> 2/ It is relatively common to also enable/disable PMTU discovery as 
> alternative to an explicit MSS configuration (not only in OpenConfig, see 
> again e.g. my old survey in 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-yang-groupings-for-transmission-control-protocol-tcp-configuration-01)
> 
> 3/ If a TCP stack allows setting a maximum, the effective MSS may be smaller 
> than this configured parameter (config vs. operational state)
> 
> None of this is a fundamental problem for a YANG model, and we could figure 
> out how to model this specific detail. Both MSS and PMTU discovery was in the 
> list of features that were originally discussed in TCPM as potentially in 
> scope of this document. But there was no strong interest in this inside TCPM 
> without a clear use case.
> 
> If the feedback from BGP implementers is that MSS and MTU discovery is a 
> MUST-HAVE, that situation could change.

What you're seeing is that interest from the parties working on the modeling
for BGP with similar parties who are realizing similar issues must be dealt
with for other protocols.  (In this case, BMP.)

You're also seeing this interest late for the usual reason in IETF modeling
work: YANG module "interwork" efforts have come late in the process.

> > For the first point, it might make sense to expose the effective MSS in the
> > tcp/connections container.  Doing so in a typedef defined in this module may
> > be helpful for the second point.
> 
> As already pointed out, we would have to understand whether it should be the 
> MSS, or also PMTU discovery, or even more.

MSS and PMTUD are certainly reasonable items.

> As the upcoming revision of the draft will have other changes, the authors 
> could make a proposal in this space, too. But I'd really be more comfortable 
> with this if there was some further list support from the community before 
> going down that road.

I think your largest problem is going to be the list of SME on this are few
and thus interest will appear to be low.

Speaking as someone who works at a larger vendor, I'd prefer to see this
work addressed in the main effort.  If it isn't, vendors will end up
implementing their own operational state for this as augmentations which
might lead to inconsistencies.

> Thanks for this good discussion!

Thanks for entertaining these late discussions for this work.

-- Jeff

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

Re: [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

[Jeffrey Haas]

Michael,

On Tue, Aug 09, 2022 at 10:31:47AM +, Scharf, Michael wrote:
> As different interfaces can have a different MTU, it is not uncommen to
> use different MSS values for connections originating/terminating on
> different interfaces. At least the Linux kernel apparently picks the MSS
> per interface. As a result, it hardly makes sense to model in YANG a
> single MSS value for all interfaces. Instead, the MSS value would have to
> be per interface and set in a corresponding YANG model for the interface.

Knowing the MSS that the host would pick for sessions over a given interface
might be "nice", but I would tend to agree that it might not make great
sense in the model.

> Theoretically, we could do this for MSS, e.g., by augmentation. But for
> other parameters, such as hardware offload configuration, this would get
> complex and technology-specific. As a result, the proposed YANG model
> stays away from interface-specific parameters.

The underlying issue that Camilo is trying to raise isn't so much
interface-specific as it is session specific.  Consider the following
examples:

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/tcp-mss-edit-protocols-bgp.html
https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/bgp/73x/b-bgp-cg-8k-73x/implementing-bgp.html#task_sq1_xdk_4jb

The inconsistency Camilo mentioned aside, there are two aspects to sessions
that are relevant to the management information:

- For the session, can you see the effective parameter?  (In this case, no.)
- How do you configure the parameter in question?

For the first point, it might make sense to expose the effective MSS in the 
tcp/connections container.  Doing so in a typedef defined in this module may
be helpful for the second point.

For the second point, TCP sessions are created outside of the YANG module.
Just like parameters like the endpoints and ports need to be configured
(some explicitly, some implicitly) by other modules, MSS and other session
parameters may be needed.  The typedef noted above provides a common way to
model that configuration state and is supported by the operational state
above.

Is a typedef required?  No... but it makes many things easier since it
avoids everyone reinventing items like constraints, etc.

-- Jeff

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

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

[Jeffrey Haas]

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

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

Re: [GROW] How to reuse the tcp model in the BMP model - asking for suggestions

[Jeffrey Haas]

Camilo,

Responding somewhat late to this thread, but I think that you will find that
the latest updates to the tcpm module addressed most of your concerns, if
not all of them.  The BGP YANG module, as Michael notes below, helped refine
some of the use case scenarios.

The audit was primarily covering how to use authentication.  Some additional
focus on other TCP properties might be worth evaluating.


-- Jeff

On Tue, Jun 21, 2022 at 09:12:36AM +, Scharf, Michael wrote:
> Hi Camilo,
> 
> There are existing examples for YANG modules that model application-specific 
> configuration for TCP connections, such as:
> 
>   *   draft-ietf-idr-bgp-model
>   *   draft-ietf-netconf-tcp-client-server
> 
> I would assume that BMP could be modeled like that.
> 
> Note that the model for TCP-AO authentication has changed in 
> draft-ietf-tcpm-yang-tcp-07 because of last call comments, i.e., some model 
> aspects can still be subject to change.
> 
> Michael
> 
> From: Camilo Cardona 
> Sent: Friday, June 17, 2022 4:37 PM
> To: Scharf, Michael ; 
> draft-ietf-tcpm-yang-tcp.auth...@ietf.org; draft-ietf-tcpm-yang-...@ietf.org
> Cc: t...@ietf.org; grow@ietf.org
> Subject: Re: How to reuse the tcp model in the BMP model - asking for 
> suggestions
> 
> 
> Hello Michael,
> 
> 
> 
> First of all, thanks for considering our questions and letting us know about 
> this new version.
> 
> 
> 
> Please keep in mind that the BMP model draft is in very early stages, not 
> even a WG draft yet, it might change in the future. So, we apologise if we 
> cannot give you exact requirements.
> 
> 
> 
> Having said that, it will feasible that the model will need to include 
> multiple TCP configurations. Defining the connection might be specific to the 
> application, but BMP requires other  features like authentication, MSS, 
> keepalives which seem general enough. What we wanted was to leverage other 
> model for this, if existing.
> 
> 
> 
> Thus, I guess the most general question we can make is , How is the 
> recommended way of reusing the tcp model?
> 
> 
> 
> Thanks,
> 
> Camilo Cardona

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

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

[Jeffrey Haas]

Max,

On Sun, Jul 24, 2022 at 07:10:58PM +0200, Maximilian Wilhelm wrote:
> Thanks for all the feedback on the draft, it's much appreciated!
> I've tried to incorporate feedback on all points raised into the
> document and uploaded a new version -01, which you can find at
> 
>   https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/01/
> 
> The diff between -00 and -01 is available at
> 
>   https://www.ietf.org/rfcdiff?url2=draft-wilhelm-grow-anycast-community-01
> 
> Does this address the points raised here? Did I miss anything?
> Happy to hear you feedback on the latest version!

You've addressed all of my concerns.  Thanks.


-- Jeff

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

[Jeffrey Haas]

> On Jul 21, 2022, at 1:25 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> Jeff, 
> 
> I am OK with going along with the suggestion from Nick and Job. I think you 
> are saying yes as well.
> 
> As for OV and AS_SETs, it may be worth considering updating RFC 6811 to 
> reflect the same thing, i.e., always mark a route Invalid for having an 
> AS_SET anywhere in the AS_PATH.

Some opinionated individuals already documented such a thing in RFC 6907, 
§7.1.9 et seq. :-)

The lingering case, that you might be talking about, is §7.1.8.

Note that 6907 didn't register itself as an update to 6811.

-- Jeff

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

[Jeffrey Haas]

Sriram,

It's no more broken that the other brief-mode aggregation issues that OV has.  
See our discussions on the sloppiness of origin-AS in those circumstances - I 
think they're applicable here.

-- Jeff



> On Jul 21, 2022, at 12:46 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> Jeff,
> 
> Thanks for the detailed insights. 
> 
> I gather that at least Nick and Job are clearly in favor of marking an UPDATE 
> Invalid (i.e., a route leak in the present context) for having an AS_SET 
> anywhere in the AS_PATH. (I.e., forget about having the Unverifiable flavor.) 
> It appears Randy is also in the same camp.
> 
> Are you also OK going along with it?
> 
> In Section 5.3 (Mitigation), it is also stated:
>   If the output of the AS_PATH verification procedure is "Invalid" the
>   route MUST be rejected.
> 
> Sriram
> 
> 
> From: Jeffrey Haas 
> Sent: Thursday, July 21, 2022 6:22 PM
> To: Nick Hilliard
> Cc: Sriram, Kotikalapudi (Fed); sidr...@ietf.org; GROW WG; 
> draft-ietf-sidrops-aspa-verificat...@ietf.org
> Subject: Re: [GROW] Any credence to AS_SET in the *middle* between 
> AS_SEQUENCEs?
> 
>> On Jul 21, 2022, at 4:36 AM, 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.
>> 
>> in the context of EBGP connectivity, on the internet, having an AS_SET in 
>> the middle of a sequence means that whoever is responsible for leaking that 
>> is exposing far more about their internal sausage factory than I ever want 
>> to know.  There could possibly be valid reasons, but it's far more likely 
>> that this is the outcome of temporary or simply poor quality routing 
>> policies.
> 
> In principle, "complex aggregation" permitted you to avoid shortening the 
> as-path lengths excessively.
> 
> Simple example:
> 
> A: 100 5 4 3 2 1
> B: 200 5 4 3 2 1
> 
> Complex Aggregated path: [ 100 200 ] 5 4 3 2 1; length 6
> Simple aggregated path: [ 1 2 3 4 5 100 200 ]; length 1
> 
> In practice, the majority of aggregation happens near leaf ASes from provider 
> space delegated to multi-homed customers.  So, "throw it all into the set" 
> works fine for the desired properties.  In the set of ASes with aggregated 
> prefixes, they are expected to have all of the more specifics.
> 
> Where brief aggregation gets tricky is where the cut point is for the 
> aggregating AS that will now be the "origin".  Those procedures don't 
> interact nicely with RPKI OV, and are the main detail I've been owing a 
> write-up on for the deprecate as-set document.
> 
> One thing very much worth mentioning is that anything clever some provider 
> might want to do with complex aggregation is likely to be undone by anyone 
> else doing aggregation and using the simple mode.
> 
>> ASPA somewhat assumes a naive/simplistic routing policy.  Having AS_SET 
>> support of this style means that it's entertaining a far greater level of 
>> complexity than ASPA's target network might operate. There are echoes of the 
>> DNS camel here.
> 
> I suspect that for simple aggregation the procedures for ASPA could be clear. 
>  I don't know that I'd try to support complex aggregation.
> 
> And that said, ASPA will have the same concerns with brief mode aggregation 
> that OV does.
> 
> -- Jeff
> 

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

[Jeffrey Haas]

> On Jul 21, 2022, at 4:36 AM, 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.
> 
> in the context of EBGP connectivity, on the internet, having an AS_SET in the 
> middle of a sequence means that whoever is responsible for leaking that is 
> exposing far more about their internal sausage factory than I ever want to 
> know.  There could possibly be valid reasons, but it's far more likely that 
> this is the outcome of temporary or simply poor quality routing policies.

In principle, "complex aggregation" permitted you to avoid shortening the 
as-path lengths excessively.

Simple example:

A: 100 5 4 3 2 1
B: 200 5 4 3 2 1

Complex Aggregated path: [ 100 200 ] 5 4 3 2 1; length 6
Simple aggregated path: [ 1 2 3 4 5 100 200 ]; length 1

In practice, the majority of aggregation happens near leaf ASes from provider 
space delegated to multi-homed customers.  So, "throw it all into the set" 
works fine for the desired properties.  In the set of ASes with aggregated 
prefixes, they are expected to have all of the more specifics.

Where brief aggregation gets tricky is where the cut point is for the 
aggregating AS that will now be the "origin".  Those procedures don't interact 
nicely with RPKI OV, and are the main detail I've been owing a write-up on for 
the deprecate as-set document.

One thing very much worth mentioning is that anything clever some provider 
might want to do with complex aggregation is likely to be undone by anyone else 
doing aggregation and using the simple mode.

> ASPA somewhat assumes a naive/simplistic routing policy.  Having AS_SET 
> support of this style means that it's entertaining a far greater level of 
> complexity than ASPA's target network might operate. There are echoes of the 
> DNS camel here.

I suspect that for simple aggregation the procedures for ASPA could be clear.  
I don't know that I'd try to support complex aggregation.

And that said, ASPA will have the same concerns with brief mode aggregation 
that OV does.

-- Jeff

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

Re: [GROW] seeking advice about non-standard use of ‘Segment’ (in the ASPA verification draft)

[Jeffrey Haas]

Sriram,


> On Jul 19, 2022, at 4:52 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
>> Since there's work to simply make "sets go away" (which I owe you text for), 
>> there are two choices:
>> 1. Make the text correct for as-sets, which will complicate the algorithm 
>> (but perhaps not significantly)
>> 2. Preclude sets as valid matches for aspa purposes and keep the simpler 
>> fully indexed solution.
> 
> The algorithm currently does #1 (relying on non-standard use of 'Segment'). 
> But we have a way to do #1 even by simply indexing the ASes in the 
> AS_SEQUENCEs. We can accommodate AS_SET at the beginning of the AS_PATH. We 
> will accommodate it. What about AS_SET in the middle is my next question. 
> Please see my other post with the subject: 'Any credence to AS_SET in the 
> *middle* between AS_SEQUENCEs?'

If by "beginning of the AS_PATH", you mean rightmost and toward the origin AS, 
that's good to hear.  I suspect you can have clean procedure for that 
circumstance.

"AS_SET in the middle" is not impossible, but extremely unlikely to be seen.  
This corresponds to the "complex aggregation" case discussed in RFC 4271's 
appendices.  My personal experience is that this is not typically implemented.  
That said, it has been seen in the wild on occasion, so someone's 
implementation is trying to do Something Clever.

My personal suggestion is to not worry about accommodating it unless you think 
it doesn't overly complicate the procedures or impact correctness for the core 
use case.

>> ASPA verification doesn't try to operate on confederation segment types...
> 
> We are thinking we'll add the following statement in the draft about 
> Confederations:
> 
> The ASes on the boundary of an AS Confederation MUST register ASPAs using the 
> Confederation’s global ASN and the procedures for ASPA-based AS path 
> validation in this document are NOT RECOMMENDED for use on eBGP links 
> internal to the Confederation.

I'd support that text.

-- Jeff

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

Re: [GROW] seeking advice about non-standard use of ‘Segment’ (in the ASPA verification draft)

[Jeffrey Haas]

Sriram,


> On Jul 19, 2022, at 11:47 AM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> RFC 4271 and RFC 5065 specify using the term ‘Segment’ to denote AS_SEQUENCE, 
> AS_SET, AS_CONFED_SEQUENCE, or AS_CONFED_SET. The ASPA verification draft 
> v-09 currently deviates from that and uses ‘Segment’ to refer to an AS in an 
> AS_SEQUENCE and also to refer to an AS_SET.
> 
> Is such non-standard use objectionable or unadvisable?

Objectionable and unadvisable both.

> 
> If affirmative, then possible fixes are: (1) remove any AS_SET from the 
> AS_PATH for algorithm purposes only and then simply use AS(i) to refer to the 
> i-th AS in the AS_SEQUENCE(s) (with a slight additional tweak in the 
> algorithm), or (2) use an alternate term like element or component.

"element" is keyword used in RFCs 4271 and 5065, but in the context of a 
segment type.

And yes, figuring out what "element" means in an absolute as-path indexed sense 
is challenging.  Normally it becomes necessary to treat AS_PATH elements first 
as an indexed array of segments of a type.  Within a segment, if it's of type 
sequence, you can generally talk about an AS element in an indexed fashion.  If 
it's a set type, it's usually a membership operation (X is a member of 
segment)

Since there's work to simply make "sets go away" (which I owe you text for), 
there are two choices:
1. Make the text correct for as-sets, which will complicate the algorithm (but 
perhaps not significantly)
2. Preclude sets as valid matches for aspa purposes and keep the simpler fully 
indexed solution.

ASPA verification doesn't try to operate on confederation segment types, so 2 
is likely where this goes.


-- Jeff

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

Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol

[Jeffrey Haas]

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou 
 wrote:
> 
> Hi Jeff,
>  
> Our work is not to propose a new protocol.
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01
>  
> 
> Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Thanks for the pointer to this document.  I had not previously read it.

The use case portion of the document is clear and well-written.

I don't pretend to be an expert in any of the IGPs, but here are a few 
observations from my read-through of the document:

- Should the per-adjacency header include something like ifIndex as part of its 
information?  This might help with troubleshooting misconfigured interfaces.
- In places where fields are Reserved, please use text in the form of "MUST be 
set to zero on transmission and SHOULD be ignored on reception".
- Your reason type and statistics type fields should get IANA sections and IANA 
allocation policy for allocating future code points.
- Your statistics TLV could probably be patterned more like that of the main 
BMP RFC.  That would permit more than one statistic to be attached at a time.
   + Statistic Value says that it is always 4 bytes of length.  If it's a fixed 
length, you may not require a length.  But I think you'll want this to be 
variably sized.  Some fields should be a 64-bit gauge; see BMP RFC for examples.
- The document should procedurally describe what happens when a session is 
first established.  For BGP BMP, the full RIB set is exchanged.  For this 
proposal, very likely the intent is that the LSDB is transmitted.  Given the 
incremental nature of IS-IS messages, it may be necessary to describe similar 
"end of rib" procedures that are in the BGP BMP specification in the context of 
your draft.  Afterwards, propagating the raw IS-IS PDUs in your messages will 
likely make sense.

-- Jeff

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

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Robert,


> On Jul 11, 2022, at 12:16 PM, Robert Raszuk  wrote:
> On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas  <mailto:jh...@pfrc.org>> wrote:
> Tianran,
> 
> Please note that nothing prohibits BGP-LS from being distributed over BMP 
> today aside from implementation support.  It's just another AFI/SAFI.
> 
> -- Jeff
> 
> Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the 
> BGP-LS formatted data at the IGP node exporting this data ? 

Do whatever you'd do in your implementation for BMP for the scenario that makes 
sense for you.

If you want to know what an upstream BGP router sent you, look at your rib-in.
If you want to know what local state you've got and are intending to 
disseminate to your downstreams, look at your loc-rib.
If you want to know what state you've sent to your downstream, look at your 
rib-out.

None of this is unusual.

rib-in and rib-out are clear from a BGP protocol fundamentals perspective.

loc-rib has a touch of ambiguity, along with exactly the same dose of ambiguity 
about "where does locally originated state manifest in implementations" that 
made for a lot of discussion in GROW "recently" as the loc-rib and rib-out 
specs were being finished for RFC purposes.

In our implementation, where loc-rib tracks the "lsdist.0" table, I'd probably 
use that for the majority of use cases that I'd want to get a feed for BGP-LS 
from BMP.  Or, I could just do a BGP-LS peering session and get it that way, 
but the discussion is that BMP works fine.

> 
> If this would avoid BGP to check the syntax of what is send it would work 
> fine .. but it would not. And BGP has no business on doing that check and to 
> understand zoo of foreign extensions completely not related to BGP itself. 

Feel free to speak for your own implementation, but kindly don't assert that 
others can't do it when it's being done.

-- Jeff 

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

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Tianran,

Please note that nothing prohibits BGP-LS from being distributed over BMP today 
aside from implementation support.  It's just another AFI/SAFI.

-- Jeff


> On Jul 11, 2022, at 10:02 AM, Tianran Zhou 
>  wrote:
> 
> Hi Robert,
> 
> I see this name very similar to BMP bgp monitoring protocol.
> Is this the similar function and scope as BMP?
> 
> 
> Best,
> Tianran 
> 
> 
> Sent from WeLink
> 发件人： Robert Raszukmailto:rob...@raszuk.net>>
> 收件人： Yingzhen Qumailto:yingzhen.i...@gmail.com>>
> 抄送： idrmailto:i...@ietf.org>>;grow >;lsrmailto:l...@ietf.org>>
> 主题： Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
> 时间： 2022-07-11 18:01:47
> 
> Hi Yingzhen, 
> 
> Yes I understand that OSPF-GT is a new protocol leveraging some OSPF 
> elements. 
> 
> And please do not get me wrong ... way before OSPF Transport Instance I wrote 
> BGP Transport Instance proposal and I do consider such additions to protocols 
> as a very useful thing. In fact honestly recent discussions on UPA/PUA/PULSE 
> could be very well served by OSPF-GT in a stateful fashion. 
> 
> But I just do not see this fits well as a replacement of BGP-LS. 
> 
> Yes, protocol designers like a swiss army knife approach (not to use nail and 
> hammer analogy). However I think custom tools in the toolkit work much better 
> for specific tasks :) 
> 
> Cheers,
> R.
> 
> 
> 
> On Mon, Jul 11, 2022 at 3:20 AM Yingzhen Qu  > wrote:
> Hi Robert,
> 
> Please think of OSPF-GT as a new protocol and it borrows ideas from OSPF. 
> BGP-LS is one use case. In LSR WG, there have been proposals asking IGPs to 
> carry non-routing information which will have impacts on protocol 
> convergence, and OSPF-GT is meant to be the vehicle for such information.
> 
> BMP started before YANG, now with NETCONF/YANG or gNMI, you can retrieve the 
> entire LSDB or part of it from a router, or subscribe to some data instances. 
> 
> Thanks,
> Yingzhen
> 
>> On Jul 10, 2022, at 3:44 PM, Robert Raszuk > > wrote:
>> 
>> Hi Acee,
>> 
>> My questions were based on section 3.4 of the latest version of the draft. 
>> 
>> So I do not think I misinterpreted it. 
>> 
>> Thank you,
>> R.
>> 
>> 
>> 
>> On Mon, Jul 11, 2022 at 12:38 AM Acee Lindem (acee) > > wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
>> Robert Raszuk mailto:rob...@raszuk.net>>
>> Date: Sunday, July 10, 2022 at 1:32 PM
>> To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>
>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>, 
>> Susan Hares mailto:sha...@ndzh.com>>, IDR List 
>> mailto:i...@ietf.org>>, "grow@ietf.org 
>>  grow@ietf.org " > >, lsr mailto:l...@ietf.org>>
>> Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol
>> 
>>  
>> 
>> Hi Yingzhen & OSPF-GT authors,
>> 
>>  
>> 
>> UP front I must state that anything is better to export IGP information from 
>> routers to interested nodes than using BGP for it.
>> 
>>  
>> 
>> But to propose using OSPF to transport ISIS seems pretty brave :) I must 
>> admit it ! 
>> 
>>  
>> 
>> With that I have few questions to the proposal - assuming the use case is to 
>> distribute links state info in a point to point fashion: 
>> 
>>  
>> 
>> What is the advantage - if any - to use a new OSPF instance/process to send 
>> link state data over a unicast session to a controller ? 
>>  
>> 
>> It doesn’t have to be unicast, the remote neighbor construct just extends 
>> the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is 
>> all the protocol machinery is in place.  Note that LSDB streaming is just 
>> but one use case and of OSPF-GT. The detals of this application would be 
>> specified in a separate draft.
>> 
>>  
>> 
>>  
>> 
>> The draft is pretty silent on the nature of such a p2p session. Please be 
>> explicit if this is TCP, QUIC or what ? 
>>  
>> 
>> It is OSPF, OSPF has its own protocol identifier (89). This draft just 
>> extends OSPF. I think you’ve misinterpreted the draft. Hence, your other 
>> questions aren’t really applicable or would be answered in a draft of the 
>> OSPF/IS-IS LSDB usage of OSPF-GT.
>> 
>>  
>> 
>> Thanks,
>> Acee
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> C) The draft is pretty silent on types of authentication for such sessions. 
>> Security considerations are pretty weak in that respect as well. 
>> 
>>  
>> 
>>The security considerations for OSPF-GT will be similar to those for
>>OSPFv2 [RFC2328] and OSPFv3 [RFC5340].  However, since OSPF-GT is not
>>used to update OSPF routing, the consequences of attacks will be
>>dependent on advertised non-routing information.
>> 
>>  
>> 
>> I would actually argue that security considerations of p2p remote neighbors 
>> are actually quite different from security considerations of flooding data. 
>> 
>>  
>> 
>> Along the same lines security is not about protecting your 

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Jeffrey Haas]

Jeff,


> On Jul 10, 2022, at 5:14 PM, Jeff Tantsura  wrote:
> 
> Thanks Sue!
> 
> We don’t have to always reinvent the wheel (at least not every time )
> I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC)
> There are most probably some other vendor specific encodings/methods to steam 
> to do that 

Minimally, the Openconfig group has models for the LSDB and some number of 
vendors either have implementation for providing access to that state via 
netconf, or gNMI.

Example model:
https://github.com/openconfig/public/blob/master/release/models/ospf/openconfig-ospfv2-lsdb.yang

I've largely reached the point where when someone uses the term "subscription" 
in terms of operational state, I'm going to think "you want this in YANG 
modeling via one of the access protocols for that".

For general operational state access, it's not bad... just very slow and eats 
your CPU doing too much printf.  (non-ascii versions of the model output become 
discussion points, but also change your ecosystem discussion).

Part of the discussion not fully had is what the consumers for this state are.  
If you're talking operational tools, getting pushed toward YANG models starts 
making more sense.  However, if you have routing driven purposes, either 
directly at consuming routers or at controllers, you want different answers.

Certainly, as you're aware, Jeff, vendors and operators are happily consuming 
BGP-LS state do to Clever Things.  For those cases, I'm not sure there's going 
to be a driver to get it out of BGP.

> I believe – there has been some work around Kafka.

It works quite nicely on collectors.  Serving your ecosystem by consuming the 
state from the network in efficient formats and then feeding tools from the 
collector in your toolchain of choice tends to be a nice model.

> 
> Would be great to  do some study around existing solutions, see what worked, 
> what didn’t’ (and why)  

Getting various parties to discuss this publicly is the larger challenge.

-- Jeff

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

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

[Jeffrey Haas]

> On Jul 7, 2022, at 11:50 AM, Robert Raszuk  wrote:
> But most if not all of those do not affect intradomain traffic engineering 
> rules. 
> 
> So I think Jeff's point is how much trust is needed to overwrite your own 
> policy in selecting exit points and overwriting your EPE policy, TE policy, 
> Local Pref etc ... 

Exactly.

> And I think misuse of those can happen even over direct peerings if the 
> overall objective is 
> to avoid double checking the community against prefix lists. 

Exactly.

-- Jeff

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

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

[Jeffrey Haas]

Max,


> On Jul 5, 2022, at 6:40 AM, 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.

Thanks for the draft.

Minimally, I think the draft is "mostly harmless!" (with no offense to the 
idea).  An advisory community that may help operators shape policy for the 
documented scenarios might be helpful.

I think my major questions for the draft overlap whether an operator has any 
particular reason to trust the marking to be used to influence their policy.  
For example, if a /24 marked with the anycast community would bypass your TE 
and stick to shortest IGP distance, what's the likelihood that someone would 
intentionally mis-mark routes for this behavior?  If we get to the point where 
this needs a prefix-list to decide what routes you'd trust, especially given 
the advice about no-export, does the community actually help the operator?

-- Jeff

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

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jeffrey Haas]

Two comments here:

If the BGP Speaker is inserting itself into the AS_PATH, it's not really a 
Route Server in the traditional sense.

A normal BGP Speaker can happily pass along routes via eBGP peering with the 
nexthop unchanged with all devices that it shares a common nexthop subnet with.

My recommendation is to not to try to consider these devices a Route Server.  
For ASPA purposes, just add the BGP connections to the inputs.

If providers are unhappy with having a IXP router's AS in the ASPA data and 
thus lose the desired ASPA filtering properties, the IXP should install a real 
route server.

-- Jeff


> On Mar 21, 2022, at 11:48 AM, Zhuangshunwan 
>  wrote:
> 
> +1
> I think Jacob's suggestion is reasonable.
> I once worked on a route leak analysis project. There is a first step in that 
> project, which is to clear the IXP’s AS number added to the AS-PATH by the 
> non-transparent RS.
> The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” 
> (where ASx and ASy are RS-clients connected in BGP via the RS) will be 
> corrected to “AS1 - ASx - ASy - ASn”.
> With this process, we can exclude the influence of non-transparent RS on the 
> accuracy of route-leak analysis.
>  
> Kind Regards,
> Shunwan
>  
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] 
> Sent: Monday, March 21, 2022 11:13 PM
> To: Gyan Mishra ; Sriram, Kotikalapudi (Fed) 
> 
> Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
> Zhuangshunwan ; Nick Hilliard 
> Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
> question)
>  
> Route servers are a distraction for ASPA.
> ASPA is about BGP path validation.
> As such it concerns itself with ASNs in the AS path.
> It is about relationships between adjacent ASes in the AS path.
> Since RSes are not in the AS path, they cannot be included in ASPA.
> RSes are only visible and relevant to the direct neighbors of the RS.
> The ASN of the RS does not appear in the AS path, therefore it is of no 
> concern to anyone that is trying to validate the AS path.
> Could we please remove all references to route servers from the ASPA draft 
> and issue a new draft about treatment of route servers only?
>  
> Regards,
> Jakob.
>  
> From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
> Behalf Of Gyan Mishra
> Sent: Sunday, March 20, 2022 9:20 AM
> To: Sriram, Kotikalapudi (Fed)  >
> Cc: Ben Maddison mailto:benm@workonline.africa>>; 
> sidr...@ietf.org ; grow@ietf.org 
> ; Zhuangshunwan  >; Nick Hilliard  >
> Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
> question)
>  
>  
> Hi Sriram
>  
> On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
>  > wrote:
> I think a correction is required. Instead of what was said before -
> 
> #1: An RS client of an RS (transparent or not) includes the RS AS in their 
> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
> connects in the control plane via the RS.
> 
> only the following simpler statement is required in the draft:
> 
> #2: An RS client of an RS (transparent or not) includes the RS AS in their 
> SPAS/ASPA. 
> 
> The reason is as follows. Consider the following topology and Update flow per 
> arrows:
> 
> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
> --->  AS4 (validating AS)
> 
> AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
> ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
> once the Update transitioned to a downward path after the RS, it cannot be 
> subsequently sent to a provider or lateral peer. But with #1, the Update will 
> be evaluated as Valid (not route leak) by the ASPA verification procedure in 
> case the RS is transparent. But with #2, the Update will be correctly 
> detected as a route leak (whether the RS is transparent or not). 
> 
> Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
> Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure 
> and that is not good. I.e., the detection of the apex in the AS path at the 
> RS (not visible in the path) and inversion (non-upward flow) after the RS is 
> obscured with #1 (in the transparent case). However, with #2, the hop AS1-AS3 
> is evaluated as "attested not Provider". That means that the detection of 
> apex/inversion at the RS (though not visible in the path) is effectively not 
> missed out by the procedure with #2. 
> 
> Thank you.
> 
> Sriram  
> 
> -Original Message-
> From: GROW mailto:grow-boun...@ietf.org>> On Behalf 
> Of Sriram, Kotikalapudi (Fed)
> Sent: Tuesday, March 15, 2022 11:34 AM
> To: Nick Hilliard mailto:n...@foobar.org>>
> Cc: Ben Maddison mailto:benm@workonline.africa>>; 
> grow@ietf.org 

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

[Jeffrey Haas]

Camilo,


> On Mar 7, 2022, at 5:59 PM, Camilo Cardona  wrote:
> On 7/3/22, 22:32, "Jeffrey Haas"  wrote:
>>You probably care about what's going on for the tcp yang module.  I've 
>> prodded that item in a separate response.
>> 
> JCC: Ack! We will look at that. Are you planning to include that also in the 
> BGP one?

Alvaro prodded IDR that it was at IETF last call.  Since the BGP module is 
looking to make use of TCP-AO, it got some extra scrutiny.

That, plus the fact that anyone who does any serious BGP or BMP troubleshooting 
usually ends up a lesser expert on TCP and wants good troubleshooting... :-)

>>For your address family list, perhaps consider the BGP yang identity 
>> afi-safi-type.  We're hoping that as the bgp-yang work wraps up we'll have 
>> the expected types in a common registry that can be extensibly maintained.  
>> I see you're using this for the "name" for address-family filters.
>> 
> JCC: We do reference the BGP one  for AFIs, don’t we? Let us know where we 
> are missing that reference as the idea is indeed to leverage the BGP model as 
> much as possible.

This one was a mistake on my part. You're covered!

>>For your "bmp_peer_types", consider having it be an identity.  They're 
>> easy to maintain in the yang language, while enumerations tend to require a 
>> fully model update.
>> 
> JCC: Also here, please check that "peer" is already an union between the 
> remote-address of the BGP model, the peer-type of the same model, and the bmp 
> one. We added the last one because we couldn’t find a way of signaling "ALL", 
> and we wanted to be explicit, but we can check other options.

Understood.  The "type enumeration" works, but so would making it an identity.

The IETF YANG maintenance rules effectively push you to maintain enumerations 
by publishing an update to the module.  However, if you define a base identity 
for this bit of config and create the "all" case, you're covered for current 
purposes.  At a later date if you want to add other identities via augmentation 
rather than a full module re-issue, you can do so.  For example, 
"all-customers", "all-ebgp" or other such stuff.

> 
>>How were you planning on monitoring other network-instances?  E.g. the 
>> ribs for vrf-X?
>> 
> JCC: My naïve answer would be to place it under the network-instance that it 
> corresponds, such as the BGP model does, but I am sure there are tons of 
> caveats to explore.

Yeah, there's choices here.  The critical one is I think that you want your 
config state for your stations to be somewhat centralized while your "here's 
what I monitor" to be network-instance aware.  Exactly what that looks like 
probably will take some discussion.  I don't have a strong opinion yet!

> 
>>Consider moving your action to be a per-station action.  See for example 
>> the actions in the bgp yang model.
>> 
> JCC: The action currently points to a single station. Maybe I am 
> misunderstanding your observation here though.

The model is basically "clear session foo".  If you look at the bgp-model, 
you'll see that under neighbor context, there's a clear action.  Its presence 
under the neighbor means that you have semantic clarity about what you're 
taking action on.  

Contrast this vs. a global action that requires parameters.

It's a style point.  I would tend to recommend the per neighbor yang actions 
because the validation considerations are handled by its presence there.  I.e. 
"is this a configured entity."

-- Jeff
> 

___
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

[Jeffrey Haas]

Camilo,

A few quick notes from an eyeball review of the draft:

You probably care about what's going on for the tcp yang module.  I've prodded 
that item in a separate response.

For your connections, just put in the full 4-tuple; i.e. local-port.

For your address family list, perhaps consider the BGP yang identity 
afi-safi-type.  We're hoping that as the bgp-yang work wraps up we'll have the 
expected types in a common registry that can be extensibly maintained.  I see 
you're using this for the "name" for address-family filters.

For your "bmp_peer_types", consider having it be an identity.  They're easy to 
maintain in the yang language, while enumerations tend to require a fully model 
update.

How were you planning on monitoring other network-instances?  E.g. the ribs for 
vrf-X?

Consider moving your action to be a per-station action.  See for example the 
actions in the bgp yang model.

-- Jeff



> On Mar 7, 2022, at 5:06 AM, Camilo Cardona  
> wrote:
> 
> Hi Grow,
> 
> 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?
> 
> Thanks,
> Camilo Cardona
> 
> 
> 
>> 
>> On 7/3/22, 10:51, "internet-dra...@ietf.org"  
>> wrote:
>> 
>> 
>>   A new version of I-D, draft-cptb-grow-bmp-yang-01.txt
>>   has been successfully submitted by Camilo Cardona and posted to the
>>   IETF repository.
>> 
>>   Name:  draft-cptb-grow-bmp-yang
>>   Revision:  01
>>   Title: BMP YANG Module
>>   Document date: 2022-03-07
>>   Group: Individual Submission
>>   Pages: 14
>>   URL:
>> https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt
>>   Status: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/
>>   Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang
>>   Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01
>> 
>>   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 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

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

[Jeffrey Haas]

Brief note that the tcpm module for YANG has some discussion about generically 
tuning this stuff.

I'd strongly encourage those with an interest in this topic, and how TCP-AO 
would interact with the BMP module, to give their draft a strong look.  It's 
working through IETF last call.

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-06 


-- Jeff


> On Mar 7, 2022, at 1:04 PM, Tim Evens (tievens) 
>  wrote:
> 
>  
>// Connection, missing tcp tuning params
>// like keep-alives, segment sizes, etc.
>  
> TCP keep-alives SHOULD be enabled by default if possible. The ability to tune 
> them is also important.  Window sizes have been a challenge over higher 
> latency BMP sessions. We should be able to adjust/configure scaling/etc. 
>  
> In addition to TCP tuning, I do like the ability to configure an initiation 
> delay as well as backoff timers.  If the BMP session is flapping, then at 
> some point it should backoff and wait a little longer. 
>  
> Thanks,
> Tim
>  
>  
> On 3/7/22, 2:08 AM, "GROW"  wrote:
>  
> Hi Grow,
> 
> 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?
> 
> Thanks,
> Camilo Cardona
> 
> 
> 
> > 
> > On 7/3/22, 10:51, "internet-dra...@ietf.org"  
> > wrote:
> > 
> > 
> >A new version of I-D, draft-cptb-grow-bmp-yang-01.txt
> >has been successfully submitted by Camilo Cardona and posted to the
> >IETF repository.
> > 
> >Name:  draft-cptb-grow-bmp-yang
> >Revision:  01
> >Title: BMP YANG Module
> >Document date: 2022-03-07
> >Group: Individual Submission
> >Pages: 14
> >URL:
> > https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt 
> > 
> >Status: 
> > https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/ 
> > 
> >Htmlized:   
> > https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang 
> > 
> >Diff:   
> > https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01 
> > 
> > 
> >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 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 
> 
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Jeffrey Haas]

> On Feb 18, 2022, at 12:30 PM, Randy Bush  wrote:
> 
>> 
>> * 32-bit ASNs don't fit in 16-bit fields. Consider using a set of
>>  Extended Communities?
> 
> next you're gonna want ipv6; sheesh!  :)
> 
> i think the draft tried to finesse and not get into wire format.  but it
> probably should.
> 
> extended or wide?  

If your semantics will happily fit into 6 bytes, extended would work okay for 
you.  Implementations that support extended communities often let you configure 
such things even if they're not "well known".

https://www.rfc-editor.org/rfc/rfc5668.html 


You'd probably just want to ask for a new sub-type for this using the 
transitive version of the type, and then put the semantics in the local-admin.  
Most of the range is defined first come, first served so it's trivial to get an 
assignment without a lot of work.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-four-octet-as

-- Jeff

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

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

[Jeffrey Haas]

I support Hávard's observations. 

I'd also like to comment that the notation of "prepends 5" meaning "5 + 1" is a 
bit confusing for all of the examples.  Consider instead just saying what the 
announced as-path length is.  Operators prepend 5 because their intent is 
"announce 6". :-)

Rather than try to cast the (very contrived) scenario as a form of route 
leaking, I'd suggest the authors focus on the impact of downstream consumers of 
the prepending.  In particular, the example here simply notes that the 
receiving AS had a desire to use one path, but the upstream providers in 
executing their own motivations caused them to not have such a preferable path 
by default.

Sadly, too bad for this downstream operator.  The more hops away you are from a 
given bit of reachability, the less your opinion tends to matter over what the 
announcements look like.  It's likely time for them to form a business 
relationship with the announcing AS or one of their immediate service provider 
ASes.  (And thus, reinforcing business motivations that push the AS diameter of 
the Internet to remain small...)

-- Jeff


> On Feb 18, 2022, at 7:28 AM, Havard Eidnes  
> wrote:
> 
> Hi,
> 
> here are a few comments about section 3.1 in the draft:
> 
> Other than the missing comma in the list of routers/ASes, near
> the end there is talk about a route leak.  However, I don't think
> what's stated here as a route leak is what's commonly understood
> to be a route leak.
> 
> I think a route leak is commonly understood to be when a route is
> announced to a neighbor in violation of the (intended) routing
> policy, i.e. a route leak can be the result of an erroneously
> implemented intended routing policy.  I can't see how that's the
> case here, because no routing policy has been expressed for "I".
> This probably means that "I" re-advertises all routes it
> receives, from any edge on any other edge, and therefore by
> definition can't have a "route leak".
> 
> It's another matter that the traffic pattern from B to J in the
> stated scenario involves a change to a path which traverses I.
> 
> If we instead of "thinking BGP" in the drawing in 3.1, suppose we
> think "RIP with max metric 64" instead.  Of course when you
> adjust metrics on any interface in the topology, traffic flows
> will shift around.  I can't quite understand when we do the
> similar thing in BGP it's such a big problem?
> 
> Admittedly, by prepending outgoing route announcements towards a
> given peer, you only affect "one end of the link", and there's a
> fair chance that asymmetric traffic patterns will result if
> that's the only thing which is done.  But...  Is that a problem?
> 
> I think the problem desribed in section 3.1 could do with a bit
> clearer description of why this is problematical.
> 
> Regards,
> 
> - Håvard
> 
> ___
> 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] Input on AS Prepend for draft-idr-rpd-15.txt - Ends 02/24/22

[Jeffrey Haas]

[Speaking as an individual contributor.]

Prepending has been around for ages and it's well understood at this point in 
how it behaves.

An older version of the grow prepending document was nicely clear as to why 
excess prepending was problematic.  From that perspective, the document was 
useful.  More recent versions of the document have muddied its clarity.

I don't find it needful that BGP protocol documents reference this document in 
particular.

-- Jeff


> On Feb 10, 2022, at 4:53 PM, Keyur Patel  wrote:
> 
> [Sending it to IDR & GROW]
>  
> Hi Folks,
>  
> 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.
>  
> Best Regards,
> Keyur
>  
> ___
> 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] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Jeffrey Haas]

Paolo,

> On Dec 13, 2021, at 6:21 PM, Paolo Lucente  wrote:
> 
> Agree & ack your final remarks about properties of introducing optional TLVs 
> in Route Monitoring messages. Would you like to see them mentioned in the 
> draft?

It's worth a sentence or two at most.  While it's one of those things that 
theoretically is obvious to the implementor, I've grown cynical over the years 
as to how "obvious" shows up in software. :-)

-- Jeff

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

[Jeffrey Haas]

On Wed, Dec 08, 2021 at 11:57:08AM -0500, Jeffrey Haas wrote:
> A final meta comment that probably belongs in an Error Handling section:
> For a route monitoring message, the new TLVs follow an encoded BGP Update
> message.  BGP isn't a rigorous TLV protocol, as we know.  And certainly, a
> BMP implementation MUST know how to decode a BGP PDU in order to do its
> work.

This also knocked loose an interesting issue that we don't have to worry
about for the short term but is applicable here:

RFC 8654 provides for an extended message length for BGP.

In pathological circumstances, an implementation with extended message
support being encapsulated in a BMP PDU might not be able to fit.  This is
already a theoretical problem without the optional TLVs, but might become
more of one with the TLVs.

It might be worth one sentence of mention in Error Handling if such a
section is created.  "RFC 8654 permits BGP Updates and other messages to
grow to a length of 65535 octets.  This may cause a BMP PDU that attempts to
encapsulate such long messages to overflow."




-- Jeff

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

[Jeffrey Haas]

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

A few comments:

4.2: "value MUST be boolean" really isn't precise enough  I suspect the
intent is "0 is false, 1 is true".  Spell that out.  Some protocols the
existence of a zero-length TLV as a presence node is sufficient to say
"true".  And perhaps some people's code says

#define FALSE 0
#define TRUE !FALSE

You may even want to be more limiting and require that the length of the TLV
is one.

7 IANA Considerations:
You're effectively defining a registry for route monitoring messages.  That
should likely be a new registry - see examples in RFC 7854 section 10.

No TLVs are being defined for peer down.  I still suggest creating a
registry.

The registry policies in section 10 probably aren't what you want.  E.g.:
:   Information type values 0 through 32767 MUST be assigned using the
:   "Standards Action" policy, and values 32768 through 65530 using the
:   "Specification Required" policy, defined in [RFC5226].  Values 65531
:   through 65534 are Experimental, and value 65535 is Reserved.

I don't recall the status of changing of the policies.  Wasn't there a draft
on that circulating or am I remembering incorrectly?

A final meta comment that probably belongs in an Error Handling section:
For a route monitoring message, the new TLVs follow an encoded BGP Update
message.  BGP isn't a rigorous TLV protocol, as we know.  And certainly, a
BMP implementation MUST know how to decode a BGP PDU in order to do its
work.

That said, an implicit property for route monitoring optional TLVs is that
the encapsulated BGP Update is well-formed!  If it is not, then you can't
seek into the optional TLV section and parse it appropriately.

Related indirect property: If you want to have BMP as a channel for bad BGP
PDUs, it probably needs to be via route mirroring.

-- Jeff

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

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

[Jeffrey Haas]

Ben,

On Wed, Dec 08, 2021 at 06:00:44PM +0200, Ben Maddison wrote:
> > While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
> > code point.".
[...]
> That makes sense, thanks.
> Having never written a routine that does this, I am slightly surprised
> that it is still cheaper, even if the implementation cannot *require* that
> it will arrive sorted - but I am more than happy to take yours and Jeff's
> word for it!

Since it's not a state secret and a very common strategy for building
canonicalized collections:

1. Syntactically and semantically verify the contents of the received
TLV set.
2. Presuming step 1 passes, determine if for those rules whether there are
places in the data that should be cleaned/stripped.  As an example, an NLRI
MAY be encoded with trailing bits after the prefix length. (This causes fun
bugs elsewhere in the code in many cases!)  Step 2 might be done in tandem
with step 1 depending on whether the buffer in question is yours to do with
as you please or whether you're dealing with a shared buffer.
3. Presuming step 2 is done and is sorted in a canonical order[1], you can
simply take the memory in question and use it as a long key in a collection
to find an object with the same contents.  The collection in question is
usually some nice bit of work appropriate to the key properties, but
anything that's efficient will work.  Some implementations are partial to
height balanced trees, others to radix tables or similar like PATRICIA.

There is significant room for optimizations in step 3.

Why does sorted matter?  Because if it's not, you need to insert a step
between 2 and 3 to canonicalize the data prior to the lookup step.
Otherwise you'll happily find an object (or not) in your collection that
matches the bit pattern but duplicates the semantics of the object.

E.g. {1,2,3} and {1,3,2} may be the same state, but you now have two objects
representing it.  Having a common object means you can now link state
together from that canonicalized object and use it to find related things as
another key.

-- Jeff

[1] The BMP TLV draft somewhat frustratingly permits multiple instances of
the same type in a TLV set.  Repetitions breed ambiguityin canonicalization.
A result of this is that when "pick one" is an answer, sometimes you get
behavior that depends on the implementation's sorting choice in this
instance.

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

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

[Jeffrey Haas]

On Wed, Mar 31, 2021 at 04:26:06PM -0700, Randy Bush wrote:
> > The point Jakob follows up with in this thread strongly suggests
> > communities are not a viable mechanism.
> 
> communities are rarely a viable mechanism.  too malleable, forgable,
> ...  once again, see our paper.

Randy adds elsewhere:

Florian Streibelt, Franziska Lichtblau, Robert Beverly, Anja Feldmann,
Cristel Pelsser, Georgios Smaragdakis, Randy Bush; BGP Communities: Even
more Worms in the Routing Can; ACM Internet Measurement Conference 2018
https://archive.psg.com/181101.imc-communities.pdf


-- Jeff

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

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

[Jeffrey Haas]

[Note, commenting as an individual contributor...]

On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote:
> On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
> kotikalapudi.sri...@nist.gov> wrote:
> > We (authors of the WKLC draft) can continue working on creating an IANA
> > WKLC registry for the future but I think the route leaks solution draft can
> > switch to using Transitive Extended Community. Especially, if that could
> > help expedite the route leaks draft and its deployment? I would like to
> > seek advice regarding that (I'm cc'ing GROW also here).
> 
> 
> Sorry to argue in public, but I disagree very strongly on the second part
> here.
> 
> We would like to continue proceeding with use of a LC range for
> implementation, using a single (or small number) of Global Administrator
> values.
> 
> I think we should request that a small block of GAs surrounding the initial
> assignments be tentatively marked something like Reserved for IANA
> assignment.
> That is different from actually establishing a registry or assigning them
> specifically for WKLCs, but would be compatible with subsequent WKLC work.

The issue being faced here for WKLC is a few related items:
- There needs to be some number of global admin (AS) reserved for generic use.
- Since this was not done at the time the feature was shipped, there is no
  support in anyone's code to treat subsequently allocated ranges as
  "special".

The two larger criticisms of the WKLC draft to date is that it wanted a LOT
of the AS space to be used, and that its transitivity functionality would
not fit well into an incremental deployment of the feature.  If the
transitivity requirements are removed and the space is narrowed, that at
least moves it closer to existing community operational practices.  E.g. a
single AS allocated for the purpose that leaves two unstructured fields, or
a small number of ASes.

This then would require implementations that want to treat the new
well-known fields as "special" to have code to do so.  So, we're already
looking at some level of new code.

Absent that new code, what we have is generic policy, along with the
implementation's normal propagation behavior - which is behind a knob for
some implementations.

> The move to using LC values was precipitated by the observation that the
> path for getting attributes deployed would be very long, and that operators
> (actual network operators) are looking for a solution which can be deployed
> *now*.

If the state can fit into an extended community, that similarly can be done
NOW.  A significant portion of the extended community space is available on
first-come, first-serve basis.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

But it doesn't change the above issues.

> Nothing has changed in this regard; the WKLC draft is IMHO still the right
> path, and only the size of the initial allocation is problematic.
> 
> Having 1-4 GA values (from the 32-bit range of potential values) is not
> burdensome IMNSHO, and is a lot less of a concern than the 1/64 (or 1/16)
> of the range of 32-bit ASNs originally requested/suggested.
> 
> If we can all agree that 1-4 GA values assigned for this is acceptable, I
> suggest a revised version of the draft and assessment of consensus on the
> revised draft for adoption and last call.
> 
> LC is the ONLY viable path, given the nebulous state of implementation and
> use for EC/WC or attributes. LC is already deployed, and assigning a few
> GAs by IDR is the only roadblock to the draft in GROW getting approved.

I question your conclusion.

The desire is to have an attribute that is used for route leak mitigation
purposes.

This thread illustrates that it's very easy for such a control community in
any flavor (regular, extended, large) to be stripped because the service
provider hasn't proactively acted to permit it.

Does this really solve the problem?

-- Jeff

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

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

[Jeffrey Haas]

Sriram,

On Wed, Mar 31, 2021 at 05:16:47PM +, Sriram, Kotikalapudi (Fed) wrote:
> >You can thus just get a FCFS extended community from a
> >transitive space TODAY and
> >it'd probably do most of what you want.  One of the beneficial properties
> >that extended communities have is the transitivity is at least understood
> >and well deployed.
> 
> I was hoping for a confirmation of that nature. So, that is good to hear.
> 
> >That said, there's still no guarantee that some operator may choose to just 
> >delete them all at an ASBR.
> 
> Yep. It is not a perfect world. But are you suggesting that no 
> community-based approach (EC or LC or ?) is worth pursuing? 

The point Jakob follows up with in this thread strongly suggests communities
are not a viable mechanism.

> >...the headache you're going through is trying to avoid the work of creating 
> >a new attribute. 
> 
> 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.

> >A discussion I'd suggest is that we've had a need for a "BGP routing
> >security" attribute where we can put these various proposals:
> >- It's not a victim of existing community practices.
> >- Policy might still interact with it, but the baseline maintenance
>   expectations can be set for it.
> >- It can be extensible so new components can be added incrementally.
> 
> In the above, are you suggesting BGP Path Attribute or a new type of 
> Community that comes with transitivity guarantees?

The biggest headache with getting new features into BGP as attributes is the
first bit of code point assignment.  If such a feature has an extension
mechanism, new things within that path attribute are usually much easier to
get deployed, and it helps their development and deployment velocity.

We're not exactly low on BGP Path Attribute code points.  But it'd be nice
if the incremental deployment story for bgp security features is better than
the incremental micro feature of the day.  Minimally, as Jakob notes, it'll
make the deployment story nicer for the service providers that have harmed
incremental deployment of new features by proactive filtering.

-- Jeff

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

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

[Jeffrey Haas]

On Wed, Mar 31, 2021 at 06:02:52PM +, Jakob Heitz (jheitz) wrote:
> No community is transitive.
> Not even the transitive extended communities.
> 
> In all BGP code I've worked in, not just Cisco, a configuration
> is required to send communities of any kind to an ebgp session.
> By default, no communities are sent to ebgp sessions.
> That's a good thing, because network operators don't want
> junk in the routes transiting across their networks, causing
> churn and memory consumption.

Contrarily, the implementations I've worked on don't have this behavior.
But it's still a highly relevant point and perhaps what should probably be a
useful rule of thumb across IETF working groups that deal with BGP:

Because such a knob exists on multiple implementations, communities 
SHOULD NOT be used for any protocol transient signaling behaviors.

> Path attributes are transitive.
> However, several years ago, approximately coinciding with the
> development of RFC7660, there was massive thrust to get attributes
> blocked too. Now we implement path attribute filtering
> and many network operators use it.

Sadly, also yes.

At least in my case, every discussion I have about the feature I note that
it is toxic to the incremental deployment of new features in BGP.  And
similarly, that it is a toxic use case for someone paying them as a transit
provider.

-- Jeff

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

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

[Jeffrey Haas]

Sriram,

(Clearly I'm not Sue...)

Extending the observation I've just made to Gyan, the headache you're going
through is trying to avoid the work of creating a new attribute.  A result
of this is a lot of work trying to proscriptively change how people operate
their networks for more general features.

Extended communities have functionally behaved as more of a protocol control
mechanism in their general history.  They already have behaviors that permit
them to be selectively transitive or non-transitive across ASes.
Operationally, they MAY be stripped by policy, but sanitization practices
for them are significantly less codified than RFC 1997 communities.  You can
thus just get a FCFS extended community from a transitive space TODAY and
it'd probably do most of what you want.  One of the beneficial properties
that extended communities have is the transitivity is at least understood
and well deployed.

That said, there's still no guarantee that some operator may choose to just
delete them all at an ASBR.

A discussion I'd suggest is that we've had a need for a "BGP routing
security" attribute where we can put these various proposals:
- It's not a victim of existing community practices.
- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
- It can be extensible so new components can be added incrementally.

While I understand a motivation for putting this in communities is "faster
deployment", take the other example from the life of large communities: when
there's sufficient interest, the feature will show up pretty fast.

-- Jeff (the best time to plant a tree is ten years ago. the second best
time is now...)


On Wed, Mar 31, 2021 at 02:56:58PM +, Sriram, Kotikalapudi (Fed) wrote:
> Hi Sue,
> 
> Thanks for the detailed thoughts you have shared on the IDR list about the 
> WKLC draft and route leaks solution draft (while also responding to Brian’s 
> post).
> 
> At one point in the past, the route leaks solution needed 8 bytes of user 
> data space to accommodate two ASNs but then there was a design change (more 
> than a year ago) and the current draft [1] requires only 4 bytes of user data 
> space (one ASN). So, it seems possible to use a Transitive Extended Community 
> instead of WKLC.
> 
> We (authors of the WKLC draft) can continue working on creating an IANA WKLC 
> registry for the future but I think the route leaks solution draft can switch 
> to using Transitive Extended Community. Especially, if that could help 
> expedite the route leaks draft and its deployment? I would like to seek 
> advice regarding that (I'm cc'ing GROW also here). 
> 
> One question is… even after IANA allocation of a Transitive Extended 
> Community for route leaks, there may still be additional effort needed to get 
> the operators to truly treat the EC as *transitive* so that it propagates at 
> least a few hops. How do we accomplish that? Write a BCP in GROW strongly 
> recommending operators to implement default policy to ensure transitivity? We 
> would like to hear people's thoughts about that? 
> 
> Thank you.
> 
> Sriram
> 
> [1] Route leaks solution draft (in GROW): 
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-04
>  

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

[Jeffrey Haas]

Tim,

On Wed, Nov 04, 2020 at 06:01:14PM +, Tim Evens (tievens) wrote:
> I've updated this to UTF-8. From a receiver point of view, we handle utf-8 
> generically without any special need to deserialize it.  I suggest we do not 
> attempt to define structure and/or constraints around the VRF names as that 
> would severely impact system implementations that are out-of-scope of this 
> draft. 
> 
> How about if we add:
> 
> "The structure, syntax, and constraints for a VRF name are router specific."

I see that you did the change to UTF-8.  My comment wasn't that we should
insist the VRF name has any specific semantics.  The issue is largely that
which is discussed here in RFC 8203:

https://tools.ietf.org/html/rfc8203#section-6

:   This document uses UTF-8 encoding for the Shutdown Communication.
:   There are a number of security issues with Unicode.  Implementers and
:   operators are advised to review Unicode Technical Report #36 [UTR36]
:   to learn about these issues.  UTF-8 "Shortest Form" encoding is
:   REQUIRED to guard against the technical issues outlined in [UTR36].
:
:   As BGP Shutdown Communications are likely to appear in syslog output,
:   there is a risk that carefully constructed Shutdown Communication
:   might be formatted by receiving systems in a way to make them appear
:   as additional syslog messages.  To limit the ability to mount such an
:   attack, the BGP Shutdown Communication is limited to 128 octets in
:   length.

You'll need similar boilerplate comments your security considerations.  In
the absence of such comments, you'll be facing a rather stiff bit of IESG
commentary. :-)

For shorter context for this list, the issue is roughly two things:
- You're sending along a byte string that has implicit lengths for each of
  the encoded characters.  You need to deal with issues when the implicit
  character length is not properly contained in the TLV you get on the wire.
  (This topic is in need of an IETF tutorial.)
- Some of the stuff in UTF-8 is "bad".  You'll want to filter that.

Since we have an RFC that cleared such review comments, including some
flavor of the 8203 security considerations will make your life happier.

-- Jeff

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

[Jeffrey Haas]

Job, 

I agree that utf-8 is more appropriate, but would remind you that a great deal 
more text about handling it would be needed. See prior discussion on RFC 8203. 

Jeff

> On Nov 3, 2020, at 1:29 AM, Job Snijders
> 
> ### note 8
> 
> section 5.3
> 
> Curious: why ASCII and not UTF-8 (of which ASCII is a subset)?
> 

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

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

[Jeffrey Haas]

I'm rather far behind in my mail, but hopefully current on this thread.  A
few comments on the adopted draft:

The thing I find most worthy in this document is the discussion about how
excessive prepending increases your vulnerability to route hijacking.
This issue will exist whenever you have a well connected peer that is
willing to forge their AS_PATH.  It's probably worth the general nod to
bgpsec because it implies how you don't get out of that problem without
locking down the contents of the as path.  The well connected peer issue is
inferred in 3.1.

While I agree with Jakob's comments that lead to the updated section 3.4
text, trying to normalize "avoid other people's bugs" is awkward at best.
3.5 similarly fits in that category.

Section 4 is a nice start to describing the solution space, but is
problematic on a few levels:
- Scoping communities from your directly attached ISP may not help you in
  some circumstances.  
- More specifics is a hard yank on traffic - if you're even permitted to
  originate them.  If you're not lucky, your prefix is already so long from
  being a small service provider that you can't make it longer.
- BGP origin code as a high order tie-breaker is a technique that works
  well, but only at places where as-paths are of equivalent length.  For
  many situations resulting in long paths, I'm not sure that helps.


Section 5's guidance of "no more than 5 prepends" is probably fine these
days, but that is largely a matter of the current diameter of the Internet.

Section 7 - Security Considerations - could likely use a paragraph
discussing how long prepending may make you more vulernable to route
hijacking.



Feedback on the contents done, a personal anecdote:

Just prior to 2000, I used to work for a small regional ISP.  That ISP was
multi-homed to a tier one and two tier two providers, each of which were
trying to fight their way into tier-one space.  Our motivations for our
multihoming were one part resiliency, one part cheapest bandwidth for the
dollar, and one part the fact that connectivity at the time to specific
sites meant that we had a strong reason to use a specific provider.

It was our experience at that time that it was necessary to use prepends in
the range of 3-5 for portions of our address space in order to try to
provide appropriate inbound load balancing.  The number was that high
because at the points we were trying to balance traffic for, the denseness
of the Internet topology meant that the unpadded routes were often getting
closely tied for path length.

Prepending wasn't a complete panacea.  We regularly experienced traffic
spikes after traffic rebalancing until we found a prepend length that was
stable enough.  I recognize at this point that we were suffering from the
effects of BGP Wedgies.  (See RFC 4264.)

I've been out of the operator game for a very long time.  We've generally
seen the diameter of the Internet decrease since I was in the business.  The
problems I was solving at the time still exist, but aren't quite as severe
in the well connected bits of the Internet.  I would not be shocked if some
of the far corners of the Internet still need this for similar motivations
than my employer had twenty years ago.



I will offer one final bit of feedback: Some customers simply filter very
long AS_PATHs.  The issues noted in this draft are effectively self
correcting in the presence of aggressive filter policies.


On Tue, Sep 08, 2020 at 05:16:30PM +, Michael McBride wrote:
> Hello wg,
> 
> We have addressed all comments so far. Thank you. We still need to expand the 
> prepend alternatives section. Please give it another look and let's see what 
> else should be included.
> 
> mike
> 
> -Original Message-
> From: GROW  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, September 08, 2020 9:58 AM
> To: i-d-annou...@ietf.org
> Cc: grow@ietf.org
> Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Global Routing Operations WG of the IETF.
> 
> Title   : AS Path Prepending
> Authors : Mike McBride
>   Doug Madory
>   Jeff Tantsura
>   Robert Raszuk
>   Hongwei Li
>   Filename: draft-ietf-grow-as-path-prepending-00.txt
>   Pages   : 10
>   Date: 2020-09-08

-- Jeff

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

Re: [GROW] Support for Enterprise-specific TLVs in BMP

[Jeffrey Haas]

Paolo,

On Mon, Oct 26, 2020 at 02:15:45PM +0100, Paolo Lucente wrote:
> I would like to get some feedback / encourage some conversation
> around the topic of supporting Enterprise-specific TLVs in BMP (or
> draft-lucente-grow-bmp-tlv-ebit-01) so to see whether it is
> appropriate to ask the Chairs for WG adoption.
[...]
> Motivation: i would like to supplement what is already written in
> the Introduction section of the draft "Vendors need the ability to
> define proprietary Information Elements, because, for example, they
> are delivering a pre-standards product, or the Information Element
> is in some way commercially sensitive.", in short prevent TLV code
> point squatting.
[...]
> Approach: reserving the first bit of a TLV type to flag whether what
> follows is a private or a standard TLV and, if private, provide the
> PEN in the first 4-bytes of the TLV value is a simple and successful
> mechanism to achieve the motivation that was merely copied from
> IPFIX, a case of nothing new under the Sun.

Firstly, I'm supportive of adding enterprise specifc information into the
BMP protocol.  I'm also supportive of using PENs to create the necessary
code space.

I will, however, offer a bit of repetitive advice I'd given at one of the
last in-person GROW sessions we'd had: This information will in many cases
degrade the packing of information in BMP route monitoring messages.  This
will have specific impacts on the memory and CPU used in an implementation.

That said, as long as the features are optional - if it hurts, don't do
that.  But I'd offer advice that whatever document this goes into contains
an Operational Considerations section that notes the impact. A BMP
implementation should be able to disable such features to mitigate the
impact on the receiver.

With regard to the use of this to prevent squatting, I'll offer two prior
inputs I've given IETF on such things:

https://tools.ietf.org/html/draft-haas-idr-extended-experimental-01
https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02

The two salient points here are:
- If the thing should be standardized, don't stick it in your enterprise
  space.  This means that a FCFS registry should be available for the stuff.
- Stability of a feature is the awkward, even if you're using FCFS.  If you
  choose an encoding, changing it has impact.  If you don't want to move the
  code point, at least consider a versioning field.

-- Jeff

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

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

[Jeffrey Haas]

Having gone through a flavor of this issue as part of the wide communities 
work, I think you’ll find it a bit more constrained than you might think. 

For purposes of a yang model, the main short term question is whether you wish 
to collapse some of the actions to common ones that might be modeled as Yang 
identities. 

Examples of this would include prepend N times. Set local preference. Set or 
adjust MED. Etc. 

Once the catalog is built, standardization is no longer the hard part. 

Jeff

> On Nov 22, 2019, at 12:07, Job Snijders  wrote:
> 
> 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

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

[GROW] IETF-106 BMP questions reminder

[Jeffrey Haas]

Please remember to send the "what do your implementations do" questions to
the grow mailing list.  This will let us aggregate the answers.

-- Jeff (an implementation owner)

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

Re: [GROW] Proposed updates to GROW charter

[Jeffrey Haas]

On Fri, Nov 22, 2019 at 10:19:06AM +0800, Christopher Morrow wrote:
> On Fri, Nov 22, 2019 at 9:55 AM Jeffrey Haas  wrote:
> >
> > On Fri, Nov 22, 2019 at 09:38:03AM +0800, Christopher Morrow wrote:
> > > I'd say: "Sure, make a protobuf definition, provide a common toolset
> > > to parse to/from this, evangelize that to the networks you care to
> > > interconnect with"
> > > seems great to me.
> >
> > Protobufs is a weak schema language.  Stick to yang.
> >
> > Protobufs is a fine transport for yang. :-)
> 
> ha! ok, so my format selection is influenced by my job's choice for
> format selection.
> Point really being: 'pick some common format, document and tool around
> it, then evangelize"
> (I think we agree on this general re-wording / goal)

Excellent.

And although it is indeed a gentle pick at your employer's format, yang has
some nice properties here that protobufs doesn't quite have.  In particular,
it's possible to express restrictions on content for validation purposes
that help with code.  E.g. a string representation of a RFC 1997 community
can be restricted by regex to be correct for encoding on the wire and
validated at the far end.  Raw protobufs the best you get is something in
the description.

In fairness to the protobufs standards, I don't follow the and perhaps
they've evolved to capture this case.



-- Jeff

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

Re: [GROW] Proposed updates to GROW charter

[Jeffrey Haas]

On Fri, Nov 22, 2019 at 01:44:03AM +, 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.

-- Jeff (you don't want to work on that code... believe me)

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

Re: [GROW] Proposed updates to GROW charter

[Jeffrey Haas]

On Fri, Nov 22, 2019 at 09:38:03AM +0800, Christopher Morrow wrote:
> I'd say: "Sure, make a protobuf definition, provide a common toolset
> to parse to/from this, evangelize that to the networks you care to
> interconnect with"
> seems great to me.

Protobufs is a weak schema language.  Stick to yang.  

Protobufs is a fine transport for yang. :-)

-- Jeff

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

Re: [GROW] New Version Notification for draft-petrie-grow-mrt-bmp-00.txt

[Jeffrey Haas]

On Fri, Nov 01, 2019 at 07:57:06PM +, Colin Petrie wrote:
> On 01/11/2019 19:22, Paolo Lucente wrote:
> >> The one addition I'd suggest for the document is that information about
> >> peer-up/down messages is needed to usefully decode some information or
> >> context about the other BMP messages.  You'll want a bit of operational
> >> procedure in your text about "please save this bit of state in each file”.
> > 
> > Or we can “save this bit of state” in the BMP message itself :-) I 
> > indeed refer to make this MRT draft depend on BMP v4 ( 
> > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/ ) since, for 
> > example, we define there a handful TLVs for Stateless Parsing (it was 
> > more done to PoC the mechanism but indeed they would result entirely 
> > useful here). Should this be an approach we'd like to consider, of 
> > course it opens the door to further considerations, one for all: shall 
> > these TLVs be made mandatory?
> 
> Yes either the BGP update encoding information need to be in the TLVs 
> (like in BMP v4) or some more metadata in MRT to store this.
> If the TLVs are not mandatory then this would have to be captured via an 
> MRT method.

Minor issue with TLVs: They're decoration on an entire BMP PDU.

An impact of such TLVs on individual prefixes means that you end up
impacting route packing in the BGP state in the PDU.  More messages, more
work to encode/decode.

Note that I'm not saying there's anything WRONG with this.  However, people
are going to find that the cost of decoration is perhaps higher in terms of
performance than they may have expected.

-- Jeff

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

Re: [GROW] New Version Notification for draft-petrie-grow-mrt-bmp-00.txt

[Jeffrey Haas]

Colin,

On Fri, Nov 01, 2019 at 04:19:59PM +, Colin Petrie wrote:
> I posted draft-petrie-grow-mrt-bmp-00,
> any and all comments are welcome.
> 
> This was a result of a discussion I had with some people about using MRT 
> as a storage format for BMP messages.

While we're starting to get a bit recursive (BGP->BMP->MRT... what next?  ;-), 
this seems like a good thing to have.

The one addition I'd suggest for the document is that information about
peer-up/down messages is needed to usefully decode some information or
context about the other BMP messages.  You'll want a bit of operational
procedure in your text about "please save this bit of state in each file".

-- Jeff

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

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Jeffrey Haas]

Sriram,


> On Oct 23, 2019, at 11:45 AM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> Out of the 477 routes with AS_SETs:
>   *** Identifying Routes with AS_SET that seem meaningless or malformed 
> ***
>   # Routes with only one AS in AS_SET : 383
>   # Routes with Reserved ASN in AS_SET : 131
>   # Routes with common AS in the AS_SEQUENCE and AS_SET : 139

The three of these have a strong feeling of bugs related to aggregation 
interacting with either confederations or private internal AS numbers and 
remote-private.

Operators with diverse labs may wish to play around and see what they can 
generate. :-)
(I don't claim our implementation is bug-free here.  But I know what I'd look 
for if doing a code audit.)



>   # Routes with repeated ASes in the AS_SET : 0

This one is somewhat expected.  The practice of canonicalizing sets in most 
people's code base should generally ensure that if you have a single sane BGP 
implementation in the path of the route to the observatory that the duplicates 
would be pruned.

-- Jeff

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

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Jeffrey Haas]

On Wed, Oct 02, 2019 at 07:45:15PM -0400, Rob Foehl wrote:
> >It'd be interesting to find out what code these folk are running. Hopefully 
> >not one of my bugs. :-)
> 
> I've never had an interaction with AS_SET that could be described as
> anything other than broken -- like, ever, from any vendor.  I'd
> prefer to see them disappear entirely, but if that doesn't happen,

As Jared noted, this was more of a common thing back-in-the-day.

For properly operating proxy aggregation, you'd generally hope that all
contributing networks were properly behind the aggregating party.  However,
as the Internet has gotten more meshy, those topological considerations
don't apply anywhere near as much.

As this torches and pitch-forks campaign against as-set continues, operators
will have to figure out whether they're really happy with the two impacts:
- No proxy aggregation, ever?
- Lie about the AS_PATH when you do it.

Today you can at least infer that proxy aggregation is happening.

The second point has entertaining impact vs. RPKI, so that's the likely
forcing function.

> at least having a "no-as-sets-under-any-circumstances" policy knob
> would be helpful...

It's a fine policy knob, and I'm more supportive of that in general.

-- Jeff

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

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Jeffrey Haas]

> On Sep 26, 2019, at 6:43 PM, Warren Kumari  wrote:
> 
> This is nice, but what would make it more useful would be if it also
> reported if there are *useful* AS_SETS / if the AS_SET means anything.
> 
> For example, from Jared's email below:
> AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path.

This one is on the buggy end of things, but still reasonably valid.  It smells 
like something that passed through remove-private of some flavor.

> 
> I've also seen a number of instances where the AS_SET contains many
> repeated instances, e.g:
> AS path: 6939 3356 42020 39010 {39275 39275 39275 39275 39275 39275
> 39275 39275 39275 39275} -- this doesn't seem to actually mean
> anything...

This one seems very buggy.  The protocol still knows what to do with it.

It'd be interesting to find out what code these folk are running. Hopefully not 
one of my bugs. :-)

-- Jeff

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

Re: [GROW] Limiting AS path length?

[Jeffrey Haas]

Speaking as a vendor:


> On Sep 16, 2019, at 11:18 AM, David Farmer  wrote:
> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:
>> Can we articulate what problem is solved by limiting the AS_PATH length?
> 
> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
> excessively long.  Furthermore, excessively long paths will use more memory 
> which could cause stability issues in some situations.

There are a number of bugs in implementations over the life of BGP related to 
path length.  In particular, overflows either in the number of ASes in the 
segment (max 255), where a second segment needs to be created; overflows in the 
length of the path attribute and needing to switch the size of the length field 
(the extended bit).

This is the primary reason we've tended to see strong pushes for filter length 
- attempts to avoid exercising such bugs.  Ideally, implementations should have 
been upgraded to avoid them by this point.

I am not optimistic. :-)

With regard to memory use, it's not a real problem for implementations and is 
generally noise in the real world vs. the total number of paths in your router.

> 
> Having a sanity limit on path length isn't a bad idea. Personally, I think 20 
> a little on the short side, but 40 or 50 seems like a reasonable limit. 
> Anything beyond that is most definitely excessive, and I'm not sure you would 
> even want to use such a path if it were real.

Quoting a coworker: constants are almost always wrong. :-)

-- Jeff

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

Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

[Jeffrey Haas]

Paolo,

Thanks for addressing my comments.  One final reply on this thread:

On Thu, Jul 11, 2019 at 12:30:53PM +, Paolo Lucente wrote:
> Done. This opened a further consideration at my end. The document lacks a
> statement as in https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about
> “TLVs can be sent in any order.

While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
code point."  

Many implementations that deal with TLV based protocols will canonicalize
data structures based on the TLVs using sorted structures.  Having them
sorted on the wire means the canonicalization step is cheaper.

Note that this is a general justification for the procedure and it's not
critical for something like BMP.

>  Multiple TLVs of the same type can be
> repeated as part of the same message and it is left to the specific
> use-cases whether all, any, the first or the last TLV should be
> considered.”. In the specific case of VRF/Table Name one could have both a
> VRF id/name and a Table Name, hence the same TLV could be repeated twice
> (my take is that it’s a perfectly valid scenario). I’d tackle this case
> once i get green light from you that we are good about how your feedback
> was processed.

I suspect most vendors will eventually generate a composite name and send a
single TLV for the name.

It would not shock me at some point if this becomes sufficiently vendor
specific that we start seeing vendor specific TLVs here.

-- Jeff

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

Re: [GROW] Benjamin Kaduk's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Benjamin,

Not speaking for the authors, but as an interested vendor:

On Mon, Jul 08, 2019 at 03:40:44PM -0700, Benjamin Kaduk via Datatracker wrote:
> --
> DISCUSS:
> --
> 
> The "Peer Up message Information" TLV type seems under-specified and
> under-motivated.  (It is not mentioned in Abstract or Introduction.)  Why
> does it need to be defined in this document, and what role is it
> expected to play?  Who is the expected audience for it?  Is it limited
> to the "group name"-like functionality described in Section 7.1?  Why is
> cleartext appropriate, and are there any potential privacy
> considerations for any potential use cases?

While underspecified, a general motivation is the ability to provide
information about a specific rib-out view.  In particular, since differing
BMP sessions may identify distint slices of the rib-out table, there's a
desire to provide additional information to the receiver about that view.
This may include such things as name of the view, peer group name, free form
description of the group, etc.  Such things are as much a matter of
preference of configuring the feature for use as it may be of an
implementation consideration.

With regard to the privacy considerations, they are identical to that of the
BMP base protocol.  See prior comment from Alvaro.

> Section 7.1
> 
> Do I interpret this correctly as saying that peer and update groups are
> not a defined protocol feature but rather something offered by
> implementations for convenience of administrators?

Some implementations, peer-groups are simply an administrative feature.  In
others, they have tight coupling toward the implementation.  Those
considerations are not part of RFC 4271 BGP-4 but are well understood by
BGP-4 operators.

-- Jeff

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

Re: [GROW] Possible Next Version of route-leak-detection-mitigation

[Jeffrey Haas]

Alexander,

On Mon, Jul 08, 2019 at 06:06:15PM +0300, Alexander Azimov wrote:
>- A single community is used for both route leak prevention, and
>detection;
>- All route leaks MUST be rejected;
>- L is removed since we don't need it in this case.

A default policy of reject all leaks makes sense, I think.

I have a slightly different view of what has been called L above:
Programmatically determining that you are the network of last resort to not
cut off an ASes prefix is tricky.  This is what the NOC phones get used for.

What's somewhat desired, I think, is dealing with the result of that NOC
phone call: An attestation that a provider has permitted a detected leak.
Consider it an "override".

---

An aside question: For service providers that are "peer" types, how are
their own internal networks intended to be flagged?

-- Jeff

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

[GROW] draft-ietf-grow-bmp-local-rib terminology edits

[Jeffrey Haas]

Grow WG,

Here are my comments on a fresh re-read of the bmp-local-rib draft.  I'll
make the following leading statements:

- Portions of the issues we're tripping across are biases coming from
  working on a given implementation.  Those happen. :-)
- I strongly suggest you get a review pass of this document in IDR so you
  can make sure that terminology is consistent vs. IETF BGP RFC documents.

These comments are vs. -04.

Section 1 - Introduction:
The introduction provides a description about the problems with how one
gathers data today, including RFC 7854 local view and compares issues
(beginning in the text "The current method") that impede standard RFC 4271
BGP (plus extensions) from being used to monitor a router.  The introduction
really needs a few sentences at the top giving a positive statement of what
this draft is trying to accomplish.  An example of this would be:
"This document defines a mechanism to monitor the BGP Loc-Rib state for
multiple BGP instances without the need for one or more unneeded BGP peering
sessions."  The rest of the introduction provides the justification.

"the BGP instance" doesn't have any RFC context associated with it.  RFC 7854 
makes some discussion about multi-instancing of BGP in section 8.1.  I'd
suggest you define this somewhere in a terminology section as "an instance
of BGP-4 (RFC 4271)" or similar, with the related pointer to the 7854
multi-instance comment.

: As shown in Figure 2, Locally originated follows a similar flow where
: the redistributed or otherwise originated routes get installed into
: the Loc-RIB based on the decision process selection.

I'd suggest a pointer to RFC 4271, section 9.4 here.

: BGP instance Loc-RIB usually provides a similar, if not exact,
: forwarding information base (FIB) view of the routes from BGP that
: the router will use. 

The BGP spec doesn't mention a FIB at all.  The interaction with the rest of
the system is via the Routing Table.  (RFC 4271, section 3.2)  I'd either
normalize the text to use that, or delete references to the FIB.

Section 2, as noted elsewhere, should likely use RFC 8174 these days.

Section 3:
Loc-RIB definition - please point to 4271 section 9.4

Section 5:
:  Loc-RIB contains all routes from BGP peers as well as any and all
:  routes redistributed or otherwise locally originated.  In this
:  context, only the BGP instance Loc-RIB is included.  Routes from
:  other routing protocols that have not been redistributed, originated
:  by or into BGP, or received via Adj-RIB-In are not considered.

I'd suggest the following:
"The Loc-RIB contains all routes selected by BGP's Decision Process (RFC
4271, section 9.1).  These routes include those learned from BGP peers via its
Adj-RIBs-In post-policy, as well as routes learned by other means.  (RFC
4271, section 9.4) Examples of these include redistribution of routes from
other protocols into BGP, or otherwise locally originated; e.g. aggregate
routes."

The purpose of the examples sentence is not to be proscriptive about how
things got into the decision process.  If the examples are found to be
contentious, I'd simply suggest deleting the sentence rather than try to
enumerate all valid examples.

:  Loc-RIB in this context does not attempt to maintain a pre-policy and
:  post-policy representation.  Loc-RIB is the selected and used routes,
:  which is equivalent to post-policy.
:
:  For example, VRF "Blue" imports several targets but filters out
:  specific routes.  The end result of VRF "Blue" Loc-RIB is conveyed.
:  Even though the import is filtered, the result is complete for VRF
:  "Blue" Loc-RIB.  The F flag is not set in this case since the Loc-RIB
:  is complete and not filtered to the BMP receiver.

The above feels awkward.  I've tried to remove the need for this text by
noting "post-policy" in the suggested text above.

The second paragraph above is structured to try to discuss when the F-bit is
used.  I'd suggest instead that section 4.2 add a new sentence describing
that the F-bit is only set when a subset of the Loc-Rib is sent on the BMP
session and not when BGP routes are excluded from the Adj-Ribs-In based on
policy.

Section 5.1:
s/filed/filled/

Peer BGP ID: It's fine for this document to shorten this to BGP ID, but a
reference should be made to "BGP Identifier".  (RFC 4271, section 1.1; RFC 6826)


Section 5.2/5.3:
Per prior discussion in other threads, it should be noted that changes that
result in an alteration of behavior need a PeerDown/PeerUp bounce along with
re-sync of routes.  I believe this may only include a change to the F-bit in
the current specification.

Section 5.5:
It might be worth mentioning that route mirroring messages MAY/SHOULD be
ignored.  However, it might not be worth mentioning.  It's not like we'll
bounce the session as long as things parse?  (But we've seen protocol
pedantry where that would be a valid behavior)

Section 6.1.1/6.1.2:
6.1.2 clearly talks about filtering.  6.1.1 talks about multiple 

Re: [GROW] WG Adoption: draft-scudder-grow-bmp-peer-up - ENDS: 06-11-2019 (Jun 11)

[Jeffrey Haas]

Chris,

While past the poll closure, I've read and support adoption of the draft.

(And ideally, quick review cycle over IETF 105 and subsequent publication.)

-- Jeff

On Wed, May 22, 2019 at 01:13:45PM -0400, Christopher Morrow wrote:
> Howdy GROW folks,
> During the last meeting (or really the Thailand meeting) I believe
> John asked for a WG Adoption call for the draft named:
>draft-scudder-grow-bmp-peer-up
> 
> Abstract of which is:
>   " 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.  The changes in this document are formal
>only, compliant implementations of RFC 7854 also comply with this
>specification."
> 
> Let's have a read/review/comment and decide to Adopt this draft as a
> WG Item, or conversely decide to not Adopt this draft.
> 
> Polls close 06-11-2019
> 
> Thanks!
> -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] working group last call draft-ietf-grow-bmp-registries-change (ends 2019.06.12)

[Jeffrey Haas]

Job,

I've read the document and support publication.

-- Jeff

On Wed, May 22, 2019 at 07:24:39PM +0200, 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://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change
> HTML: https://tools.ietf.org/html/draft-ietf-grow-bmp-registries-change
> 
> 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-local-rib (ends 2018.11.26)

[Jeffrey Haas]

Job,


> On May 22, 2019, at 1:44 PM, Job Snijders  wrote:
> 
> Dear all,
> 
> Part of the IETF process is to ensure all concerns have been addressed
> (and hopefully resolved). A concern was raised about "best vs active".
> My takeaway from the conversation at IETF 104's GROW session is that
> there is significant interest to progress towards publication - and
> both Jeff Haas and John Scudder seemed to indicate to have ideas for
> text on how to resolve issues they saw.
> 
> Version -03 didn't receive any feedback on the WG, so it is not clear
> to me whether we have converged on consensus or not.
> 
> A -02/-03 diff be found here
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-local-rib-03.txt
> 
> I'd like to ask that folks with skin in the game take a look and share
> with the working group whether we are good to go, or follow up with
> proposals for changes to the draft, or at least affirm outstanding
> issues still remain.

The outstanding issues remain.

Minimally, the work I have promised (and am delinquent on) is to send diffs to 
help the draft be more clear in a RFC-4271 sense as to what is being sent.  
This at least removes the ambiguity of the current text.

With regard to actual resolution of active vs. "bgp best", I suspect that we'll 
end up with the draft covering one thing and implementations perhaps choosing 
which of the two options to send.  Noting this in a TLV for the peer-up message 
would be one possible way to encode this.

I intend to spend some time resolving open IETF work next week after the U.S. 
Memorial Day holiday.

-- Jeff

P.S. I don't know that I've made this point before, but a flavor of this 
conversation had happened during standardization of the BGP MIB.  
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Jeffrey Haas]

On Thu, Mar 21, 2019 at 11:57:00AM +, Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) wrote:
> For the case you mentioned, it’s actually an interesting example of
> forging AS-PATH out of “good” intention, which does not belong to
> misconfiguration or attack. In fact, it suggests that should be enhanced
> inbound check/analysis instead of simply dropping the route. Operators can
> take actions based on the analysis and combined with other information.
> For example, AS65535 may contact AS64512 for further information, and work
> on the DDOS attack together.

You are pleasantly optimistic about how this sort of scenario usually
resolves.

> Inspired by that, we think adding “suggested actions” to each categorized
> “result type” can be useful for understanding how the proposed
> inbound/outbound enhancement works.

Such a section would be reasonable for your proposal.

-- Jeff

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

[GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Jeffrey Haas]

Authors,

Some various comments on the draft in no particular order:
- Consider using the document ASes from the reserved ranges; i.e. RFC 5398
- Construct a unified table of the "results" and a short term for their
  meaning.  One of my least favorite thing in RFCs that tend to be placed
  into code is calling something a "type X".  It leads to rather confusing
  conversations unless you're a protocol expert.

A final comment is another infrequent case a provider's AS may end up in the
AS-Path: Intentionally forcing that provider to discard a route *you* own.

Consider the case where AS 64512 owns 192.0.2/24.  AS 64512 is under a heavy
DDoS attack that is substantially originated from AS 65535.  By prepending
65535 to the AS-Path upon origination, 65535 will lose the route to
192.0.2/24 and, if default-free, much of the attack traffic goes away.

-- Jeff

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

Re: [GROW] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

Tim,

On Fri, Dec 14, 2018 at 01:19:30AM +, Tim Evens (tievens) wrote:
> NOTE: Sorry for the delay... end of year commitments are pressing... 
> Addressing these comments in descending order. 

I know this feeling well. :-)

> [tievens] Per this draft, the BGP-ID and ASN are set to the global/default
> value or based on VRF (Local-RIB it conveys).   The simple answer is if
> you change distinguishing (peer identity) values in the per-peer-header,
> you will need to send a PEER DOWN (using old values) and PEER UP (using
> new values). Regardless of this draft, if you send a new per-peer header
> with different values (sans type, flags, and timestamps), the receiver is
> likely going to treat that as a different peer. We/OpenBMP, and I believe
> others, use peer rd, peer addr, peer asn, and peer id as distinguishing
> identify for a peer, which enables us to multiplex different peers over
> the same TCP (bmp) stream. 

Excellent, I believe we concur on this detail.

I'd like to suggest that some text be added to the loc-rib draft covering
this detail.  Thanks!

-- Jeff
> 
> 
> 
> 
> -- Jeff
> 
> ___
> 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] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

Jakob,

On Thu, Dec 13, 2018 at 08:26:49PM +, Jakob Heitz (jheitz) wrote:
> Most of the routes will be deleted anyway.
> Only the locally originated routes will remain.
> 
> I would suggest to keep the implicit withdraw behavior and not
> to explicitly withdraw any loc-rib routes when they go away.
> That means, the BGP speaker will send BMP loc-rib peer-down,
> not withdraw any routes to BMP and resend the locally originated
> routes again.

That was my reading as well.  But I had the similar observation that it's an
awful lot of useless work if you don't need it.  But to have that take
effect, it'd require behavioral changes in the peer down message.

This was a corner case.  I think it's worth documenting it in the draft, but
it seems we have at least two parties that agree on the expected semantics.

Thanks!

-- Jeff

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

Re: [GROW] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

Jakob,

On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote:
> Wait, a BMP server is not a BGP peer. It does not replicate a routing table.
> It is a logger/processor of information. It doesn't "delete" older 
> information,
> just because some newer information arrived.
> Its purpose it to tell you what happened at some time in the past,
> because you are trying to debug a problem or do some capacity planning
> or whatever. Just because a BGP router changed its BGP-ID does not mean
> that all the routes it had 2 days ago magically did not happen.


RFC 7854:
:A Peer Down message implicitly withdraws all routes that were
:associated with the peer in question.  A BMP implementation MAY omit
:sending explicit withdraws for such routes.

-- Jeff

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

Re: [GROW] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

Jakob,

On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote:
> From: Jeffrey Haas  
> > On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote:
> > > Sending a peer-down followed by a peer-up seems reasonable to me.
> > > Changing these requires a new OPEN message to neighbors, so everything
> > > is going to bounce anyway.
> > 
> > I think so as well.
> > 
> > But what of the route monitoring messages?
>
> I would leave those alone. Sending them again adds no new information.
> The BMP server can switch the ASN and BGP-ID on its own if it wants.

That's my impression too.  However, if the implementation treats the
peer-down as an implicit flush it won't work cleanly.

This means that something in the header needs to indicate "I'm
updating some state, hold on to your RMs".

-- Jeff

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

Re: [GROW] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote:
> Sending a peer-down followed by a peer-up seems reasonable to me.
> Changing these requires a new OPEN message to neighbors, so everything
> is going to bounce anyway.

I think so as well.

But what of the route monitoring messages?

-- Jeff

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

[GROW] BMP loc-rib Peer-Type behavior

[Jeffrey Haas]

Authors,

In section 4.1, we define a new peer type to cover the loc-rib.  This is
mostly a pointer to section 4.2 of RFC 7854.


  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer Type   |  Peer Flags   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Distinguisher (present based on peer type)   |
 |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Address (16 bytes)   |
 ~   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer AS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer BGP ID   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Timestamp (seconds)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Timestamp (microseconds) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My question is with regards to Peer AS and Peer BGP ID:

If either of those fields are altered on the router, what is the expected
behavior in BMP?

I have opinions, but would like to see yours. :-)

-- Jeff

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