Re: [GROW] Agenda and Slides
On Thu, Nov 21, 2019 at 1:47 PM Christopher Morrow wrote: > > Howdy Grow Folks! > The agenda > (https://datatracker.ietf.org/meeting/106/materials/agenda-106-grow-01) This is still the agenda > has 4 presentations on deck, of which I see only 1 set of slides so far... > if you are to present tomorrow ... please send slides 'now'. > I now have slides from everyone except Ms Gu... please send along slides :) > -chris > co-chair > (I'm looking at you Colin... directly) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
Dear all,
On Mon, Oct 28, 2019 at 07:21:13PM +, Job Snijders wrote:
> Milestones
> ==
>
> Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
> Feb 2020 - "BMP Peer Up Message Namespace" to IESG
> Apr 2020 - "Revision to Registration Procedures for Multiple BMP Registries"
> to IESG.
> Jul 2020 - “Document negative consequences of de-aggregating received routes
> for traffic engineering purposes” - to IESG
> Nov 2020 - "TLV support for BMP Route Monitoring and Peer Down Messages" to
> IESG.
> Jan 2021 - “A BCP on using IRR and RPKI data to improve filtering of BGP
> peering sessions” to IESG or via “Evolving Documents”
Perhaps as a milestone we can also add an effort to create a mechanism
to allow mapping integer values in BGP {Classic, Extended, Large, Wide}
Communities to semantics by devising a system to express equivalence
relations for use in Internet inter-domain routing.
The above is a fancy way of saying that documentation like
https://www.us.ntt.net/support/policy/routing.cfm is not anywhere close
to being programmatically interpretable, and perhaps we can do better.
In a way RPSL was an attempt to address the problem space, but now in
2019/2020 the solution space maybe has expanded, and we now have a
better understanding of what worked well in RPSL and what didn't.
I'd like to add: September 2020 - "Devise a BGP Community Description System"
Kind regards,
Job
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Agenda and Slides
ok, we now have all slides :) thanks everyone! On Fri, Nov 22, 2019 at 8:49 AM Christopher Morrow wrote: > > On Thu, Nov 21, 2019 at 1:47 PM Christopher Morrow > wrote: > > > > Howdy Grow Folks! > > The agenda > > (https://datatracker.ietf.org/meeting/106/materials/agenda-106-grow-01) > > This is still the agenda > > > has 4 presentations on deck, of which I see only 1 set of slides so far... > > if you are to present tomorrow ... please send slides 'now'. > > > > I now have slides from everyone except Ms Gu... please send along slides :) > > > -chris > > co-chair > > (I'm looking at you Colin... directly) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
On Fri, Nov 22, 2019 at 8:51 AM Job Snijders wrote:
>
> Dear all,
>
> On Mon, Oct 28, 2019 at 07:21:13PM +, Job Snijders wrote:
> > Milestones
> > ==
> >
> > Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG
> > Feb 2020 - "BMP Peer Up Message Namespace" to IESG
> > Apr 2020 - "Revision to Registration Procedures for Multiple BMP
> > Registries" to IESG.
> > Jul 2020 - “Document negative consequences of de-aggregating received
> > routes for traffic engineering purposes” - to IESG
> > Nov 2020 - "TLV support for BMP Route Monitoring and Peer Down Messages" to
> > IESG.
> > Jan 2021 - “A BCP on using IRR and RPKI data to improve filtering of BGP
> > peering sessions” to IESG or via “Evolving Documents”
>
> Perhaps as a milestone we can also add an effort to create a mechanism
> to allow mapping integer values in BGP {Classic, Extended, Large, Wide}
> Communities to semantics by devising a system to express equivalence
> relations for use in Internet inter-domain routing.
>
> The above is a fancy way of saying that documentation like
> https://www.us.ntt.net/support/policy/routing.cfm is not anywhere close
> to being programmatically interpretable, and perhaps we can do better.
>
> In a way RPSL was an attempt to address the problem space, but now in
> 2019/2020 the solution space maybe has expanded, and we now have a
> better understanding of what worked well in RPSL and what didn't.
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.
> I'd like to add: September 2020 - "Devise a BGP Community Description System"
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
Dear all, Below is a revision of the charter proposal. Kind regards, Job Charter for GROW Working Group === The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, monitoring, policy, security, and VPN infrastructures, and safe default behavior of implementations. GROW will also advise various working groups, specifically the IDR and SIDROPS working groups, with respect to whether it is addressing the relevant operational and routing security needs of networks, and where appropriate, suggest course corrections or intervene. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. Goals = * Develop and document Best Current Practises for operations in the Internet routing system. * Develop and document the operational aspects of securing the Internet routing system including management of filtering and routing leaks. * Analyse, document and provide best practice characteristics of running BGP at large scale * Provide analysis, feedback and assistance for other IETF working groups when their subject matter impacts on the global Internet routing ecosystem. * Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP) * Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit (MRT) Milestones == Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG Apr 2020 - "BMP Peer Up Message Namespace" to IESG Jun 2020 - "Revision to Registration Procedures for Multiple BMP Registries" to IESG. Oct 2020 - "Document negative consequences of de-aggregating received routes for traffic engineering purposes" to IESG Jan 2021 - "A BCP on using IRR and RPKI data to improve filtering of BGP peering sessions" to IESG or via "Evolving Documents" Mar 2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to IESG. Jul 2021 - "Devise a BGP Community Description System" to IESG ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
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] Proposed updates to GROW charter
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
On Fri, Nov 22, 2019 at 1:58 AM Jeffrey Haas wrote: > > 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. Correct. Reworded: "Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format" Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
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) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
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
On November 22, 2019 at 9:44:18 AM, Job Snijders wrote: Job: Hi! I have a couple of comments. ... > Finally, where appropriate, the GROW documents the operational aspects > of measurement, monitoring, policy, security, and VPN infrastructures, > and safe default behavior of implementations. It is important to highlight somewhere that protocol changes (to, for example, meet that "safe default behavior") are to be developed in the WG chartered with maintaining the specific protocol. idr for BGP, in close coordination with grow, of course. idr is also in the process of discussing an update to their charter. An important highlight in the text there will be precisely that. > GROW will also advise various working groups, specifically the IDR and > SIDROPS working groups, with respect to whether it is addressing the > relevant operational and routing security needs of networks, and where > appropriate, suggest course corrections or intervene. Finally, > operational requirements developed in GROW can also be used by any new > working group charged with standardizing a next generation inter-domain > routing protocol. I don't think I understand what you mean by "suggest course corrections or intervene". The current Charter ends this sentence with "suggest course corrections", what is the meaning/intent of "intervene"? How does that look as a WG? ... > 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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
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 wrote: > > Dear all, > > Below is a revision of the charter proposal. > > Kind regards, > > Job > > Charter for GROW Working Group > === > > The Border Gateway Protocol (BGP) is fundamental to the operation of the > Internet. In recent years, occurrences of BGP related operational issues > have increased, and while overall understanding of the default-free > routing system has improved, there is still a long and growing list of > concerns. Among these are routing table growth rates, interaction of > interior and exterior routing protocols, dynamic properties of the > routing system, and the effects of routing policy on both the size and > dynamic nature of the routing table. In addition, new and innovative > uses of BGP, such as the use of BGP as a signaling protocol for some > types of Virtual Private Networks, have created new and unexpected > operational issues. > > The purpose of the GROW is to consider the operational problems > associated with the IPv4 and IPv6 global routing systems, including but > not limited to routing table growth, the effects of the interactions > between interior and exterior routing protocols, and the effect of > address allocation policies and practices on the global routing system. > Finally, where appropriate, the GROW documents the operational aspects > of measurement, monitoring, policy, security, and VPN infrastructures, > and safe default behavior of implementations. > > GROW will also advise various working groups, specifically the IDR and > SIDROPS working groups, with respect to whether it is addressing the > relevant operational and routing security needs of networks, and where > appropriate, suggest course corrections or intervene. Finally, > operational requirements developed in GROW can also be used by any new > working group charged with standardizing a next generation inter-domain > routing protocol. > > Goals > = > > * Develop and document Best Current Practises for operations in the > Internet routing system. > * Develop and document the operational aspects of securing the Internet > routing system including management of filtering and routing leaks. > * Analyse, document and provide best practice characteristics of running > BGP at large scale > * Provide analysis, feedback and assistance for other IETF working > groups when their subject matter impacts on the global Internet > routing ecosystem. > * Provide stewardship and maintenance for the BGP Monitoring Protocol (BMP) > * Provide stewardship and maintenance for the Multi-Threaded Routing Toolkit > (MRT) > > Milestones > == > > Jan 2020 - "Support for Local RIB in BGP Monitoring Protocol (BMP)" to IESG > Apr 2020 - "BMP Peer Up Message Namespace" to IESG > Jun 2020 - "Revision to Registration Procedures for Multiple BMP Registries" > to IESG. > Oct 2020 - "Document negative consequences of de-aggregating received routes > for traffic engineering purposes" to IESG > Jan 2021 - "A BCP on using IRR and RPKI data to improve filtering of BGP > peering sessions" to IESG or via "Evolving Documents" > Mar 2021 - "TLV support for BMP Route Monitoring and Peer Down Messages" to > IESG. > Jul 2021 - "Devise a BGP Community Description System" to IESG > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow smime.p7s Description: S/MIME Cryptographic Signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Information model for BGP Communities (Was: Proposed updates to GROW charter)
Forking this thread. On Fri, Nov 22, 2019 at 03:44:26AM +, thomas.g...@swisscom.com wrote: > Very good input regarding „Devise a BGP Community Description System > to IESG. > > I think a YANG informational BGP community modell might be the right > thing to do. I would volunteer to support such an approach. > > I think it is good to keep the charter generic. I like your proposal. > > I would be interested to know if others on the mailing list share my > opinion on using YANG information model. I would suggest to talk technology specifics in a new thread, and would also like to suggest we first get a better handle on the goal and problem space definition. This probably is a quite large project. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
Dear Alvaro, Thank you for your comments. On Thu, Nov 21, 2019 at 07:42:05PM -0800, Alvaro Retana wrote: > > Finally, where appropriate, the GROW documents the operational > > aspects of measurement, monitoring, policy, security, and VPN > > infrastructures, and safe default behavior of implementations. > > It is important to highlight somewhere that protocol changes (to, for > example, meet that "safe default behavior") are to be developed in the > WG chartered with maintaining the specific protocol. idr for BGP, in > close coordination with grow, of course. > > idr is also in the process of discussing an update to their charter. > An important highlight in the text there will be precisely that. I agree that IDR governs BGP and is expected to be its overall architect, gatekeeper, primary caretaker. But IDR is not the *only* group to influence aspects of the BGP Protocol. > > GROW will also advise various working groups, specifically the IDR > > and SIDROPS working groups, with respect to whether it is addressing > > the relevant operational and routing security needs of networks, and > > where appropriate, suggest course corrections or intervene. Finally, > > operational requirements developed in GROW can also be used by any > > new working group charged with standardizing a next generation > > inter-domain routing protocol. > > I don't think I understand what you mean by "suggest course > corrections or intervene". The current Charter ends this sentence > with "suggest course corrections", what is the meaning/intent of > "intervene"? How does that look as a WG? As an example RFC 8212 comes to mind. I would like to suggest that we have a phone call with the IDR and GROW chairs, you, and Warren, to have a dialogue to explore what what is on people's minds and how we want to express that in charters. > > Jul 2021 - "Devise a BGP Community Description System" to IESG > > Maybe this is explained somewhere else (??)...what is that? Is it > simply best practices/recommendations on how to structure the contents > of communities, or something else? Over time it has come up a couple of times that it would be beneficial to have a framework that allows operators to inform each other what the semantics are of locally significant BGP communities (of any flavor). This morning I interjected the idea https://mailarchive.ietf.org/arch/msg/grow/8k5gaWqU1fB4ItlRASv5Q7mUiUM, no further documentation exists other than in our memories. In other words: a way to programmatically tell each other that "Community 1" means X and "Community 2" means Y in NTT's network, and in AT&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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposed updates to GROW charter
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 (j...@ntt.net) wrote: 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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
