Subject: Re: [GROW] Proposed updates to GROW charter

From: Paolo Lucente <[email-masked]>
Date: Sat, 2 Nov 2019 07:49:02 +0000

Dears,

Please add Multi-threaded Routing Toolkit (MRT).

Paolo

> On 31 Oct 2019, at 16:55, Nick Hilliard <[email-masked]> wrote:
> 
> Job Snijders wrote on 29/10/2019 00:10:
>> My hope is that the proposed update aligns our description with our activities.
> 
> It does, but it also aligns with lots of other things.  Too generic is not a good thing.
> 
> That said, GROW fulfils an important niche at IETF, not just for producing its own RFCs, but also acting as a reference point for other WGs.  So it badly needs not to be closed down (randy, take note).
> 
> I've re-worked your proposal.  Please feel free to add / remove / modify / ignore / throw in volcano as you see fit.
> 
> * Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP)
> * Develop and document Best Current Practises for operations in the Internet routing system.
> * Develop and document the operational aspects of securing the Internet routing system including management of filtering and routing leaks.
> * Analyse, document and provide best practice characteristics of running BGP at large scale
> * Provide analysis, feedback and assistance for other IETF working groups when their subject matter impacts on the global Internet routing ecosystem.
> 
> Nick
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Martijn Schmidt <[email-masked]>
Date: Sat, 2 Nov 2019 08:46:10 +0000

Hello,

I see the following proposal, which I reckon references to de-aggregation oopsies by so-called "route optimizers":

Jul 2020 - “Document negative consequences of de-aggregating received routes for traffic engineering purposes” - to IESG

And that reminds me of something - what about the inverse where the originating ISP is overdoing their traffic engineering by selectively announcing de-aggregated routes alongside an overarching supernet? It's not a huge problem from a routing security perspective, but this is a major challenge in routing traffic locally outside well-established markets, especially when the ISP in question backhauls some (but not all) of their upstream providers over very long submarine paths.

Best regards,
Martijn Schmidt
________________________________
From: GROW <[email-masked]> on behalf of Paolo Lucente <[email-masked]>
Sent: 02 November 2019 08:49:02
To: Nick Hilliard <[email-masked]>; Job Snijders <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; [email-masked] [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [GROW] Proposed updates to GROW charter

Dears,

Paolo

---

From: Job Snijders <[email-masked]>
Date: Sat, 2 Nov 2019 20:57:53 +0000

On Sat, Nov 02, 2019 at 08:46:10AM +0000, Martijn Schmidt wrote:
> I see the following proposal, which I reckon references to
> de-aggregation oopsies by so-called "route optimizers":
> 
> Jul 2020 - “Document negative consequences of de-aggregating received
> routes for traffic engineering purposes” - to IESG
> 
> And that reminds me of something - what about the inverse where the
> originating ISP is overdoing their traffic engineering by selectively
> announcing de-aggregated routes alongside an overarching supernet?
> It's not a huge problem from a routing security perspective, but this
> is a major challenge in routing traffic locally outside
> well-established markets, especially when the ISP in question
> backhauls some (but not all) of their upstream providers over very
> long submarine paths.

Yes, the inverse can be an issue as well. We can add that as a
milestone! Perhaps:

    "Document impact of selectively announcing de-aggregated routes in the global routing system."

It could be helpful to come up with a fancy nickname for this type of
issue, in the spirit of how "BGP Wedgies" (RFC 4264) is a nice short
name for a complex issue.

Maybe "BGP Deaggregation Slopping" as a working title?

In any regard, will you take a lead to produce a draft? :)

Kind regards,

Job

---

From: Martijn Schmidt <[email-masked]>
Date: Sun, 3 Nov 2019 15:10:29 +0000

>      "Document impact of selectively announcing de-aggregated routes in the global routing system."
I would think more along the lines of: "Document impact of selectively 
announcing more specific routes to the global routing system."
> Maybe "BGP Deaggregation Slopping" as a working title?
Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP 
Castaways". If anything a connotation with the sea and/or submarine 
cables would be appropriate, I think!
> In any regard, will you take a lead to produce a draft? :)
Yes.. and I will also try to involve some others whom I know have run 
into this problem operationally.

Best regards,
Martijn

---

From: Gert Doering <[email-masked]>
Date: Sun, 3 Nov 2019 20:15:22 +0100

Hi,

> cables would be appropriate, I think!

"BGP vandalism"

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Nov 2019 19:41:21 +0000

>> cables would be appropriate, I think!

"Noxious Routing"?

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 3 Nov 2019 21:28:50 +0100

Folks,

Allow me to express a bit of a different view - this time from enterprise
perspective.

Actually announcing more specifics of the block one owns has real service
advantages. So in itself it is actually a good thing !

What is bad for Internet is propagating those more specific routes beyond
the point that they make any difference any longer.

There was proposal to aggregate those at dynamic points where sending them
no longer brings any service/routing advantages, but apparently at that
time no one cared much:

https://www.ietf.org/archive/id/draft-marques-idr-aggregate-00.txt

- - -

See assume I own /19 for a global network. I can't possibly announce that
block via all of my 20 ISP peerings globally as top requirement is not to
keep the Internet BGP table tiny, but rather to offer best service to
customers.

Further more imagine I offer various services based on geo location. For
customers in Japan I want them to go to Japan DMZ and not float to any
other location just because his ISP is one AS hop away from NY and two AS
hops away from Osaka or Tokyo ISPs I peer with. So if I would attract such
service to US I would need to carry it back to Tokyo over global WAN -
disaster.

See even /24 is a very coarse limit one has to deal with. I may have few
gateways for a given service per site not 255. And each service has
completely different service requirements from the network characteristic.
If I have 8 ISPs there

It is very clear (at least to some) that basic BGP best path routing is
suboptimal. For years folks have been using SLA based routing to steer
packets over non necessarily BGP best path between Internet endpoints. The
more fine are the announcements the better egress path selection can be
achieved. So the Internet is no longer used to reach A & B. It is used to
reach A & B in most optimal way for a given application.

Let's therefore keep those points in mind while blindly bashing
"deaggregation" and calling names those who do it :). I bet no one is doing
that just for fun.

Enterprises are doing it to provide the best level of service. ISPs do it
to serve the needs of their customers. It is feasible to enhance BGP to
aggregate when it no longer makes sense to carry more specific prefixes -
let's rethink this.

Thx,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 3 Nov 2019 17:42:41 -0500

Where does it no longer make sense to deaggregate? Isn't that a bunch
related to what problem the initial announcement is trying to solve?

On Sun, Nov 3, 2019, 15:29 Robert Raszuk <[email-masked]> wrote:

> suboptimal.. For years folks have been using SLA based routing to steer

---

From: Job Snijders <[email-masked]>
Date: Sun, 3 Nov 2019 16:53:24 -0600

Thank you Robert for sharing your perspective.

I didn’t take the intention of the mail thread to be that deaggregation is
bad, just that when done incorrectly, it results in suboptimal results.

We need to document the cases where the business intentions and the reality
of what happens in the internet routing system don’t match up.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Nov 2019 00:08:45 +0100

Hi Christopher,

> related to what problem the initial announcement is trying to solve?

My answer is - If routing path to destination by more specific would be
identical to the path covered by less specific prefix.

Based on some work on this in the past I do believe such "sweet spots" can
be identified especially with average AS_PATH length being less then 4.

Of course PA space is much easier then PI but both are possible to be
aggregated.

Would it cover all cases - perhaps no. Would it cover a lot of cases -
likely yes.

But before we spend more time on this let's answer one question which was
asked before - do we have a problem ? Of course 1 mln routes is easier to
be handled then 5 mln, but then you may stop upgrading hardware :) Not a
colorful future for those who need to invest in their software ...

Hi Job,

>   We need to document the cases where the business intentions and the
reality of what happens in the internet routing system don’t match up.

Fully agree and volunteer to help. Also in many cases we may indeed find
that deaggregation is purely accidental ... however those who cause it just
have no control to aggregate it or suppress announcements N AS hops away.
So we could start picking low hanging fruits like Tony's
draft-ietf-idr-as-pathlimit-03.

Thx,
R.

---

From: Martijn Schmidt <[email-masked]>
Date: Mon, 4 Nov 2019 14:08:16 +0000

Hi Robert,

What I don't mean to say is that deaggregation is always stupid, quite the contrary - it has its places where it can be a useful tool. You've just described one such use case, but I know of many more. Reasons why I have personally deaggregated prefixes include circumventing silly LocalPref designs of large incumbent telcos that have multiple "classes" of downstream customers, or forcefully localizing traffic in regions where AS-path length has no meaningful relation to actual physical distance traversed, and so on.

The specific case I want to document here is technical harm being done as a side effect of traffic engineering with more specific routes for commercial reasons. In certain regions of the world (e.g. not EU/NA, and generally not AP either) it's common for a sufficiently large eyeball telco to have to pick up some of their upstream transit over a submarine path, which means that the backhaul often becomes an order of  more expensive than the transit service itself. Therefore, those eyeball telcos have an incentive to use as much capacity per link as possible without saturating it, as opposed to what you'd do if the upstream were just a crossconnect away e.g. simply connect as much capacity as reasonable.

Of course normal internet routing doesn't work that way, a heavily peered local tier-2 operator will generally attract a lot more traffic than a restrictively peered tier-1 operator from EU/NA. But you don't want to put all your eggs in one basket either, so to consume some extra traffic on the underutilized links to justify the cost of that submarine capacity the downstream eyeball telco announces some more specific routes to the tier-1 operator which it backhauls from EU/NA - et voila, the traffic is balanced and life is good from a commercial and service availability perspective.

But that's when the trouble starts from a latency technical perspective, because now locally hosted content is always forced to take the path through EU/NA since the more specific prefix is simply not available locally even though the overarching supernet might be perfectly visible without ever leaving the region in which the prefixes were originated.

Anyway, TLDR: I don't want a nickname for this problem which is derogatory, because that helps nobody. Would you continue to read a guide where the first thing that happens is your being insulted? But, I do agree with Job that a non-technical nickname which illustrates the problem without insulting the party that made an honest mistake could help a lot in explaining to a management team why a certain routing policy should probably be reconsidered.

Best regards,
Martijn

On 11/3/19 9:28 PM, Robert Raszuk wrote:
Folks,

Allow me to express a bit of a different view - this time from enterprise perspective.

Actually announcing more specifics of the block one owns has real service advantages. So in itself it is actually a good thing !

What is bad for Internet is propagating those more specific routes beyond the point that they make any difference any longer.

There was proposal to aggregate those at dynamic points where sending them no longer brings any service/routing advantages, but apparently at that time no one cared much:

- - -

See assume I own /19 for a global network. I can't possibly announce that block via all of my 20 ISP peerings globally as top requirement is not to keep the Internet BGP table tiny, but rather to offer best service to customers.

Further more imagine I offer various services based on geo location. For customers in Japan I want them to go to Japan DMZ and not float to any other location just because his ISP is one AS hop away from NY and two AS hops away from Osaka or Tokyo ISPs I peer with. So if I would attract such service to US I would need to carry it back to Tokyo over global WAN - disaster.

See even /24 is a very coarse limit one has to deal with. I may have few gateways for a given service per site not 255. And each service has completely different service requirements from the network characteristic. If I have 8 ISPs there

It is very clear (at least to some) that basic BGP best path routing is suboptimal.. For years folks have been using SLA based routing to steer packets over non necessarily BGP best path between Internet endpoints. The more fine are the announcements the better egress path selection can be achieved. So the Internet is no longer used to reach A & B. It is used to reach A & B in most optimal way for a given application.

Let's therefore keep those points in mind while blindly bashing "deaggregation" and calling names those who do it :). I bet no one is doing that just for fun.

Enterprises are doing it to provide the best level of service. ISPs do it to serve the needs of their customers. It is feasible to enhance BGP to aggregate when it no longer makes sense to carry more specific prefixes - let's rethink this.

Thx,
R.

On Sun, Nov 3, 2019 at 8:41 PM Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:

"Noxious Routing"?

Nick

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: Jared Mauch <[email-masked]>
Date: Mon, 4 Nov 2019 09:29:56 -0500

> On Nov 3, 2019, at 5:42 PM, Christopher Morrow <[email-masked]> wrote:
> 
> Where does it no longer make sense to deaggregate? Isn't that a bunch related to what problem the initial announcement is trying to solve?

I’m looking to get rid of some of our more specifics in 2020 which should help reduce the table size, but I’m sure someone else will take up the slots almost immediately.

- Jared

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Nov 2019 16:51:32 +0100

> I’m sure someone else will take up the slots almost immediately.

Hehe and what stops that someone to inject those more specifics today
before you take back yours :) ? Last time I looked at BGP UPDATE I did not
notice any TDM like slots there :)

If BGP announcements would be having free quota per allocation size from
given Originating AS we would have very different Internet table size
today.

For good or for bad we would also have a very well developed hierarchical
routing in the Internet as opposed to mainly flat model.

R.

On Mon, Nov 4, 2019 at 3:29 PM Jared Mauch <[email-masked]> wrote:

> I’m looking to get rid of some of our more specifics in 2020 which should
> help reduce the table size, but I’m sure someone else will take up the
> slots almost immediately.
>
> - Jared

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 4 Nov 2019 22:55:32 -0400

Hello Robert,

  I really like the way you describe the situation. And this one is a
very important phrase:

"What is bad for Internet is propagating those more specific routes
beyond the point that they make any difference any longer. "

  I recognize that your draft if more complicated than what I expected
(sorry, my fault), but anyhow at the beginning I though: "this is so
true: after the AS_PATH reaches length X or more, then it does not look
necessary to propagate more specific routes". I might be wrong but I can
not think in any single situation.

  Hope your draft move forward.

Alejandro,

On 11/3/19 2:28 PM, Robert Raszuk wrote:
> Actually announcing more specifics of the block one owns has real
> service advantages. So in itself it is actually a good thing ! 
>
> What is bad for Internet is propagating those more specific routes
> beyond the point that they make any difference any longer. 
>
> There was proposal to aggregate those at dynamic points where sending
> them no longer brings any service/routing advantages, but apparently
> at that time no one cared much: 
>
> See assume I own /19 for a global network. I can't possibly announce
> that block via all of my 20 ISP peerings globally as top requirement
> is not to keep the Internet BGP table tiny, but rather to offer best
> service to customers. 
>
> Further more imagine I offer various services based on geo location.
> For customers in Japan I want them to go to Japan DMZ and not float to
> any other location just because his ISP is one AS hop away from NY and
> two AS hops away from Osaka or Tokyo ISPs I peer with. So if I would
> attract such service to US I would need to carry it back to Tokyo over
> global WAN - disaster. 
>
> See even /24 is a very coarse limit one has to deal with. I may have
> few gateways for a given service per site not 255. And each service
> has completely different service requirements from the network
> characteristic. If I have 8 ISPs there 
>
> It is very clear (at least to some) that basic BGP best path routing
> is suboptimal.. For years folks have been using SLA based routing to
> steer packets over non necessarily BGP best path between Internet
> endpoints. The more fine are the announcements the better egress path
> selection can be achieved. So the Internet is no longer used to reach
> A & B. It is used to reach A & B in most optimal way for a given
> application. 
>
> "deaggregation" and calling names those who do it :). I bet no one is
> doing that just for fun. 
>
> Enterprises are doing it to provide the best level of service. ISPs do
> it to serve the needs of their customers. It is feasible to enhance
> BGP to aggregate when it no longer makes sense to carry more specific
> prefixes - let's rethink this. 
>
> Thx,
> R.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Antonio Prado <[email-masked]>
Date: Tue, 5 Nov 2019 10:23:47 +0100

> beyond the point that they make any difference any longer. 

hi,

just for one second let's think of de-aggregating (well, trying to) an
IPv6 /29 in 2^19 /48 or of similar jokes like that.

(i know: BCP, filtering, routing hygiene, netiquette‽)

altogether, in that corner case, the best result would be cracking a
poor peer's engine, the worst...
--
antonio

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 19 Nov 2019 18:35:44 +0000

What happened to the original draft?

I can think of a high CPU risk in implementation if a covering
route covers thousands of specifics and goes away. Not to
mention the traffic loss as the specifics get readvertised.

Regards,
Jakob.

From: GROW <[email-masked]> On Behalf Of Alejandro Acosta
Sent: Monday, November 4, 2019 6:56 PM
To: [email-masked]
Subject: Re: [GROW] BGP deaggregation

Hello Robert,

  I really like the way you describe the situation. And this one is a very important phrase:

"What is bad for Internet is propagating those more specific routes beyond the point that they make any difference any longer. "

  I recognize that your draft if more complicated than what I expected (sorry, my fault), but anyhow at the beginning I though: "this is so true: after the AS_PATH reaches length X or more, then it does not look necessary to propagate more specific routes". I might be wrong but I can not think in any single situation.

Alejandro,

- - -

Thx,
R.

"Noxious Routing"?

Nick

GROW mailing list

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 19 Nov 2019 16:21:45 -0800

Hi!

Russ evolved the draft with a couple of different names and co-authors.
The last version was this:

https://datatracker.ietf.org/doc/draft-white-grow-overlapping-routes/

…which we presented at grow a couple of years ago.

Alvaro.

On November 20, 2019 at 2:36:23 AM, Jakob Heitz (jheitz) ([email-masked])
wrote:

---

From: Brian Dickson <[email-masked]>
Date: Wed, 20 Nov 2019 10:49:34 +0800

> related to what problem the initial announcement is trying to solve?
I just realized this question might not have had an answer, or not the
following answer at least:

Deaggregates should only go "upstream", to transit providers (and their
transit providers).

It might be possible to apply restrictions to achieve this goal, using
mechanisms made available when the "route leaks mitigation" draft gets
adopted (and deployed).

I believe it should be possible to tag the deaggregates differently than
the aggregate itself, to differentially propagate/filter them (and prevent
the deaggregates from going to peers or customers).

Or, it might be something that requires an additional community, maybe add
to the mitigation draft once adopted.

Brian (co-author on the mitigations draft)

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Nov 2019 11:17:26 +0100

Hi Brian,

Well your idea of not sending more specifics downstream would be really a
cool one if all Tier 1s would fully mesh with each other and exchange those
more specifics. Then indeed yes there would be no reason to send those
downstream.

But I am afraid this is not yet the reality we face.

Thx,
R.

---

From: Job Snijders <[email-masked]>
Date: Fri, 22 Nov 2019 00:51:33 +0000

Dear all,

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

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

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

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

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

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2019 09:38:03 +0800

> better understanding of what worked well in RPSL and what didn't.

This sounds, to me, like:
  "can I have a schema for how to publish / register communities that
all networks could agree to use, which permits machine parsing
capabilities"

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.

---

From: Job Snijders <[email-masked]>
Date: Fri, 22 Nov 2019 01:44:03 +0000

Dear all,

Below is a revision of the charter proposal.

Kind regards,

Job

Charter for GROW Working Group
===============================

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

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

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

Goals
=====

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

Milestones
==========

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 21 Nov 2019 20:59:11 -0500

> to parse to/from this, evangelize that to the networks you care to

Protobufs is a weak schema language.  Stick to yang.  

Protobufs is a fine transport for yang. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 21 Nov 2019 21:02:10 -0500

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

---

From: Job Snijders <[email-masked]>
Date: Fri, 22 Nov 2019 02:05:40 +0000

> of the old code of that name.

Correct.

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

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2019 10:19:06 +0800

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 21 Nov 2019 22:22:39 -0500

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

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 Nov 2019 19:42:05 -0800

On November 22, 2019 at 9:44:18 AM, Job Snijders wrote:

Job:

Hi!

I have a couple of comments.

...
> and safe default behavior of implementations.

It is important to highlight somewhere that protocol changes (to, for
example, meet that "safe default behavior") are to be developed in the
WG chartered with maintaining the specific protocol.  idr for BGP, in
close coordination with grow, of course.

idr is also in the process of discussing an update to their charter.
An important highlight in the text there will be precisely that.

> working group charged with standardizing a next generation inter-domain

I don't think I understand what you mean by "suggest course
corrections or intervene".  The current Charter ends this sentence
with "suggest course corrections", what is the meaning/intent of
"intervene"?  How does that look as a WG?

...
> Jul 2021 - "Devise a BGP Community Description System" to IESG

Maybe this is explained somewhere else (??)...what is that?  Is it
simply best practices/recommendations on how to structure the contents
of communities, or something else?

Thanks!!

Alvaro.

---

From: <[email-masked]>
Date: Fri, 22 Nov 2019 03:44:26 +0000

Hi Job,

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.

Best Wishes
Thomas

> On 22 Nov 2019, at 09:44, Job Snijders <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 22 Nov 2019 04:13:13 +0000

Dear Alvaro,

Thank you for your comments.

On Thu, Nov 21, 2019 at 07:42:05PM -0800, Alvaro Retana wrote:
> > Finally, where appropriate, the GROW documents the operational
> > aspects of measurement, monitoring, policy, security, and VPN
> > infrastructures, and safe default behavior of implementations.
> 

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

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

As an example RFC 8212 comes to mind.

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

> of communities, or something else?

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

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

Kind regards,

Job

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 Nov 2019 20:27:34 -0800

Job:

Hi!

You and I already talked before the meeting, but just for the WG…

Yes, we should talk.  As I mentioned, idr is also in the process of
rechartering, so this would be a great time to be in sync.

Thanks!!

Alvaro.

On November 22, 2019 at 12:13:17 PM, Job Snijders ([email-masked]) wrote: