Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019
I also support publication. Thanks Acee From: Idr on behalf of Jeff Tantsura Date: Thursday, July 25, 2019 at 5:49 PM To: IDR List , Susan Hares Cc: "grow@ietf.org" Subject: Re: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019 Sue, I support publication of this draft. Cheers, Jeff On Jul 25, 2019, 5:26 PM -0400, Susan Hares , wrote: Greetings IDR: The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received only 2 comments. Since this is a draft that updates an operationally needed feature, I am extending the WG LC until 8/6/2019. If you believe this draft is ready for publication, please respond to this WG LC. Sue Hares From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, July 9, 2019 9:13 AM To: 'idr wg' Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from July 9, 2019 to July 23, 2019. . Please consider if you believe this revision of RFC8203 (Administrative Shutdown) Will benefit operational networks, is technically complete, and ready for publication. In your comments, please indicate whether you “support” or “do not support” its publication. This draft contains IPR notice that causes “IPR warnings”. The authors believe that this text is automatically generated by the IETF tools and the warning is not appropriate. As the shepherd, I am investigating this issue. If you have specific knowledge on this issue, you may send it to the list or to me directly. Cheerily, Susan Hares ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
> If closer to the time of publication of this draft there is another standard that may impact decisions here, yes that would be prudent to consider. IMHO even if such standard appears *after* publication of this draft having that in apriori would be a pure plus :) Cheers, R. On Fri, Jul 26, 2019 at 7:58 PM Job Snijders wrote: > On Fri, Jul 26, 2019 at 13:54 Robert Raszuk wrote: > >> Hello Job, >> >> You'll >>> notice from the draft that once the limit is reached a CEASE >>> Notification is sent; so I am not sure if the priority truly matters in >>> context of tearing down the session. >>> >> >> And I am not sure if CEASE matters in the context of BGP Persistence >> efforts :) >> > > Good feedback. I’ll have to rely on the GROW and IDR WGs to help > understand how we view CEASE in this context and what must be done. > > >> If you have specific suggestions what text and considerations should be >>> added to the draft I would welcome that. >>> >> >> I would suggest to just add a sentence that the actual number of prefixes >> sent >> without warning or error (session drop) should be a smallest number of >> prefixes >> either which were locally configured or pushed from the peer. >> > > > If closer to the time of publication of this draft there is another > standard that may impact decisions here, yes that would be prudent to > consider. > > Kind regards, > > Job > >> ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
Hello Job, You'll > notice from the draft that once the limit is reached a CEASE > Notification is sent; so I am not sure if the priority truly matters in > context of tearing down the session. > And I am not sure if CEASE matters in the context of BGP Persistence efforts :) If you have specific suggestions what text and considerations should be > added to the draft I would welcome that. > I would suggest to just add a sentence that the actual number of prefixes sent without warning or error (session drop) should be a smallest number of prefixes either which were locally configured or pushed from the peer. Thx, R. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
On Fri, Jul 26, 2019 at 13:54 Robert Raszuk wrote: > Hello Job, > > You'll >> notice from the draft that once the limit is reached a CEASE >> Notification is sent; so I am not sure if the priority truly matters in >> context of tearing down the session. >> > > And I am not sure if CEASE matters in the context of BGP Persistence > efforts :) > Good feedback. I’ll have to rely on the GROW and IDR WGs to help understand how we view CEASE in this context and what must be done. > If you have specific suggestions what text and considerations should be >> added to the draft I would welcome that. >> > > I would suggest to just add a sentence that the actual number of prefixes > sent > without warning or error (session drop) should be a smallest number of > prefixes > either which were locally configured or pushed from the peer. > If closer to the time of publication of this draft there is another standard that may impact decisions here, yes that would be prudent to consider. Kind regards, Job > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-01.txt
Dear WG, This document of route leak detection using communities seems to address all unresolved issues from the previous versions. We believe that the proposed solution can be easily adopted by the ISPs thus reducing the number of route leaks that become globally propagated. There is one unresolved dependency - we need IANA to reserve a class for well-known transit communities. As far as I remember that there was already some work in this field. I'm eager to assist if this can help to speed up the process. пт, 26 июл. 2019 г. в 20:02, : > > 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 : Methods for Detection and Mitigation of BGP > Route Leaks > Authors : Kotikalapudi Sriram > Alexander Azimov > Filename: > draft-ietf-grow-route-leak-detection-mitigation-01.txt > Pages : 9 > Date: 2019-07-26 > > Abstract: >Problem definition for route leaks and enumeration of types of route >leaks are provided in [RFC7908]. This document describes a new well- >known Large Community that provides a way for route leak prevention, >detection, and mitigation. The configuration process for this >Community can be automated with the methodology for setting BGP roles >that is described in ietf-idr-bgp-open-policy draft. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-01 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- Best regards, Alexander Azimov ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-01.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 : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Alexander Azimov Filename: draft-ietf-grow-route-leak-detection-mitigation-01.txt Pages : 9 Date: 2019-07-26 Abstract: Problem definition for route leaks and enumeration of types of route leaks are provided in [RFC7908]. This document describes a new well- known Large Community that provides a way for route leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in ietf-idr-bgp-open-policy draft. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-01 https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
On Fri, Jul 26, 2019 at 05:16:27PM +0200, Claudio Jeker wrote: > On Fri, Jul 26, 2019 at 02:49:55PM +, Job Snijders wrote: > > My recommendation to BGP implementers would be to implement all > > three types of prefix limits. My recommendation to operators is to > > configure both pre-policy and post-policy limits, as each limit has > > different advantages in context of Internet routing. > > For BGP implementation having more then just one Loc-RIB implementing > a post-policy check is more comples and the result will depend on > which of the RIBs the count is done. For this reasons OpenBGPD only > does pre-policy inbound limits and until now nobody ever complained > about that being not good enough. In context of Internet routing the *pre* policy limit is the most useful one; so I'm happy openbgpd has it. This is the feature that helps protect against full route table leaks. On the other hand, *post* policy limits are not entirely effective against full table route leaks. I've explained the difference at the IETF 104 GROW session. The *post* policy limit is most useful if there are FIB size restrictions (for instance on a layer-3 switch with constrained ASIC); or if there are Loc-RIB memory constraints. Since the most common deployment of OpenBGPD seems to be on 'server-based routers' and 'route servers', I am not surprised so far the feature hasn't come up yet. If OpenBGPD decides not to implement post-policy limits, that is fine, it just means that OpenBGPD cannot claim compliance with the full Internet-Draft. However, when the draft is published at RFC at least openbgpd can reference *exactly* what is implemented. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
On Fri, Jul 26, 2019 at 02:49:55PM +, Job Snijders wrote: > Dear Robert, > > Thank you for your questions. > > On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote: > > I would like to raise three points in respect to this draft: > > > > Point 3: > > > > For inbound prefix limit the position if this should be pre or post > > policy should be IMHO a local configuration decision. See if I decide > > to keep full table in my Adj_RIB_In maybe just for BMP use no spec > > should prevent that. Maybe it would be worth to add this explicitly > > to the draft in addition to listing those two measurement insertion > > locations :) > > I agree that operators locally configure these limits and they > themselves choose to use no limits, pre-, post-, or a combination of > pre- + post- policy limits. > > This Internet-Draft seeks to document that both exist, and formulate > things in such a way that when a vendor claims compliance with > draft-sa-grow-maxprefix, they indicate to support all of outbound, > pre-policy inbound, and post-policy inbound. A vendor could also > indicate they only have support for "draft-sa-grow-maxprefix section 2.2 > type B", or only "type A". > > My recommendation to BGP implementers would be to implement all three > types of prefix limits. My recommendation to operators is to configure > both pre-policy and post-policy limits, as each limit has different > advantages in context of Internet routing. For BGP implementation having more then just one Loc-RIB implementing a post-policy check is more comples and the result will depend on which of the RIBs the count is done. For this reasons OpenBGPD only does pre-policy inbound limits and until now nobody ever complained about that being not good enough. -- :wq Claudio ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
Dear Robert, Thank you for your questions. On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote: > I would like to raise three points in respect to this draft: > > Point 1: > > The topic of outbound prefix limit is not new :) It has been discussed > number of times within vendors and between vendors. But one > requirement when we are talking about outbound prefix limit is which > prefixes should be sent first - which are more important then others - > so prefix prioritization in update generation and update scheduling > comes up. Are we sure that this is not going to happen here ? Sure not > in this draft, but once you build the road emergency vehicles and > regular vehicles will try to use it. And while outbound prefix limit > looks innocent the moment we start to ask for prioritizing prefixes > some bgp implementations may have a bit of hard time. We do not consider it a requirement to provide any guidance on which prefixes should be sent first. Another draft can attempt to provide guidance, or vendors can stick to their current approaches. You'll notice from the draft that once the limit is reached a CEASE Notification is sent; so I am not sure if the priority truly matters in context of tearing down the session. > Point 2: > > The draft is still silent on the question I posted to the list > regarding this idea in respect to decision which limit is more > important ? Locally configured outbound limit or pushed by prefix > limit ORF peers inbound limit ? What should be the action of the > sender when those two numbers are not equal ? I think this must be > precisely spelled out here. Can you clarify what you mean with "pushed by prefix limit ORF peers inbound limit"? As it currently stands it doesn't seem like draft-keyur-idr-bgp-prefix-limit-orf is making a lot of head-way, so it doesn't seem like there is a deployed mechanism we need to take into consideration. However, if I have to choose, I think I would prioritze the locally configured limit as one could argue that local configuration supersede instructions received from remote. If you have specific suggestions what text and considerations should be added to the draft I would welcome that. > Point 3: > > For inbound prefix limit the position if this should be pre or post > policy should be IMHO a local configuration decision. See if I decide > to keep full table in my Adj_RIB_In maybe just for BMP use no spec > should prevent that. Maybe it would be worth to add this explicitly > to the draft in addition to listing those two measurement insertion > locations :) I agree that operators locally configure these limits and they themselves choose to use no limits, pre-, post-, or a combination of pre- + post- policy limits. This Internet-Draft seeks to document that both exist, and formulate things in such a way that when a vendor claims compliance with draft-sa-grow-maxprefix, they indicate to support all of outbound, pre-policy inbound, and post-policy inbound. A vendor could also indicate they only have support for "draft-sa-grow-maxprefix section 2.2 type B", or only "type A". My recommendation to BGP implementers would be to implement all three types of prefix limits. My recommendation to operators is to configure both pre-policy and post-policy limits, as each limit has different advantages in context of Internet routing. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-lucente-bmp-tlv
I support adoption as an upcoming co-author. Thanks, Thomas From: GROW On Behalf Of Paolo Lucente Sent: Thursday, July 25, 2019 8:06 PM To: grow@ietf.org grow@ietf.org Subject: [GROW] Request WG Adoption for draft-lucente-bmp-tlv Dear GROWers, We would like to request WG adoption for https://datatracker.ietf.org/doc/draft-lucente-bmp-tlv/ that was presented (*) yesterday. Can you please let us know your thoughts? Thanks, Paolo (*) https://datatracker.ietf.org/meeting/105/materials/slides-105-grow-draft-lucente-grow-bmp-tlv-00 smime.p7s Description: S/MIME Cryptographic Signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Request WG Adoption for draft-lucente-bmp-tlv
Support the adoption of this draft. Shunwan From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Paolo Lucente Sent: Friday, July 26, 2019 2:06 AM To: grow@ietf.org grow@ietf.org Subject: [GROW] Request WG Adoption for draft-lucente-bmp-tlv Dear GROWers, We would like to request WG adoption for https://datatracker.ietf.org/doc/draft-lucente-bmp-tlv/ that was presented (*) yesterday. Can you please let us know your thoughts? Thanks, Paolo (*) https://datatracker.ietf.org/meeting/105/materials/slides-105-grow-draft-lucente-grow-bmp-tlv-00 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
