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
