Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018)
I support publishing this document. However, I have a small concern about it. It seems to recommend that "set community X" should remove all well-known communities by default. However, the default removal of certain well-known communities like "NO_EXPORT" by "set community X" itself surprises many novices to BGP policy, and this behavior has caused more than one unintentional route leak. So, I believe IOS XR's behavior has advantages, yet it does create surprise when compared to other router OSes, as discussed currently in the document. Therefore, I believe that the document should at least discuss the advantages of not removing all well-known communities by default, even if in the end it recommends removing all well-known communities by default. Thanks On Mon, Dec 10, 2018 at 9:26 AM Job Snijders wrote: > Dear all, > > So far we only received one note in support of publication. Before > declaring consensus one way or another I'd prefer if we have more > feedback to work with. > > Your feedback is crucial to the IETF publication proces, so please > take a few minutes to read the document and consider whether you are > in favor of publication or have objections. > > We'll extend the WGLC with another week to allow the working group to > provide feedback. > > Kind regards, > > JobOn Tue, Nov 6, 2018 at 11:56 AM Nick Hilliard wrote: > > > > Christopher Morrow wrote on 06/11/2018 04:34: > > > Please have a read/review/comment and let's see if we can close out and > > > move forward by the end of the month. > > > > no comments to add. please publish. > > > > Nick > > > > ___ > > 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 > -- === 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
Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)
Acee, On Mon, Dec 10, 2018 at 10:45:15PM +, Acee Lindem (acee) wrote: > Just because a piece of information is useful doesn't necessarily mean it > should be part of the BGP local RIB. In many cases, the BGP process and > the Global RIB are deaggregated. If we wish to overload BMP with returning > the contents Global-RIB, then it should be a separate table. Be mindful that having worked on the RFC 4271 revision, I'm a bit particular about BGP definitions and abstraction details. One of the details that was always an awkward fit was where routes entered the BGP abstract models. I've already posted it, but let's post it again: : 9.4. Originating BGP routes : :A BGP speaker may originate BGP routes by injecting routing :information acquired by some other means (e.g., via an IGP) into BGP. :A BGP speaker that originates BGP routes assigns the degree of :preference (e.g., according to local configuration) to these routes :by passing them through the Decision Process (see Section 9.1). By pedantic definition, this is how we get things into Loc-Rib. I'm not the one who chose the name of the draft we're discussing, but if we're going to talk "loc-rib", let's at least be clear. Customers want one of two use cases and I have customers who want them both: 1. The route in loc-rib as used for forwarding to avoid needing a parallel BGP session. 2. The best bgp route. The current draft, due to the way Loc-Rib is specified in 4271, isn't crystal clear in terms of what we'll get in the above case. In the loc-rib draft, section 1.1 talks about deriving the state by monitoring an adjacent system's adj-rib-in. This corresponds to 1 above, except when BGP advertises something it doesn't use for forwarding. See prior commentson the rib-out spec. Section 5 of the draft has the following: : 5. Loc-RIB Monitoring : :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. There is no "BGP Instance Loc-Rib". What I believe is intended by the authors is "The Loc-Rib in an implementation wherein the BGP routing state is segregated". The "have not been redistributed" also implies a specific implementation model that is also not necessarily congruent with 4271. And that's *FINE*. But the text needs to be cleaned up if so. That would push it up to #2 in my two cases. But for the customers that need #1? You've just told that part of the user-base "go run parallel BGP". Or, alternatively, "hey, Jeff, we're not covering your use case, copy 90% of the loc-rib draft text and add more code points". Or perhaps finally, "ah, we understand the distinction, how do we simply ship a single loc-rib draft that covers both". But that's only a conversation to have after we've gotten over the definition phase. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018)
Support. It's a useful document. BTW, it's useful to collect more default behaviors that vary from vendor to vendor: https://tools.ietf.org/id/draft-zhuang-grow-monitoring-bgp-parameters-00.txt Comments and cooperation are welcome！ Thanks, Shunwan -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders Sent: Monday, December 10, 2018 11:27 PM To: Nick Hilliard Cc: GROW List Subject: Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018) Dear all, So far we only received one note in support of publication. Before declaring consensus one way or another I'd prefer if we have more feedback to work with. Your feedback is crucial to the IETF publication proces, so please take a few minutes to read the document and consider whether you are in favor of publication or have objections. We'll extend the WGLC with another week to allow the working group to provide feedback. Kind regards, JobOn Tue, Nov 6, 2018 at 11:56 AM Nick Hilliard wrote: > > Christopher Morrow wrote on 06/11/2018 04:34: > > Please have a read/review/comment and let's see if we can close out > > and move forward by the end of the month. > > no comments to add. please publish. > > Nick > > ___ > 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 last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)
Hi Jeff, On 12/10/18, 5:33 PM, "GROW on behalf of Jeffrey Haas" wrote: [Note, message reordered and reformatted for quoting clarity] Tim, Thank you for your patience for my response. On Tue, Nov 20, 2018 at 05:42:37AM +, Tim Evens (tievens) wrote: > On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" wrote: > > Jeff Haas said: > > > I do wish to get this point resolved. We have inconsistent pressure from our own customer base as to whether they want to monitor best bgp vs. > > > "please give me something to let me stop needing parallel BGP sessions for active route state". > > > > [Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a method to send best ecmp group to BMP Station. > > BMP client can signal add-paths capability to BMP Station via BMP Peer UP message, then BMP Station will know that the client will send multiple NLRI for one destination. > > That is my understanding. > > Per my limited knowledge about BMP, I don't understand why we need "parallel BGP sessions for active route state", Sorry. Can you explain it in detail? > > Best route for sure, unless add-paths is used. I would like to understand > your use-case more... When you mention the customer has to use "parallel > BGP sessions for active route state," are you saying that the customer > needs to establish multiple "monitoring" BGP peering sessions in order to > obtain what would have been available via BMP Adj-RIB-In Post Policy > monitoring? Today, customers running stock BMP (RFC 7854) often tend to have a parallel BGP peering session with their routers to monitoring stations. This permits them, in many cases, to correlate the results of BGP received paths vs. path selection. Sticking with a simplified example with BGP running its path selection solely on BGP routes, the active route in the system's RIB may end up being non-BGP. Typical examples are static routes, or IGP routes winning out over BGP routes. I.e. "administrative distance". The route used for forwarding will be the active route in the RIB. BGP itself will advertise the active route in most implementations in most circumstances. The issue in a simplified example: If the active route for a destination is a static route, a customer may want to know this vs. the best BGP route. This is needed to check why forwarding is happening as expected. Why not use rib-out? Because other BGP features may cause a route that isn't the active route to be sent. E.g. best-external. The problem is thus: Does the customer want to receive a loc-rib feed vs. the route being actively used for forwarding, or do they want to see the best BGP route? We've had requests for both, depending on use case - typically "BGP monitoring and path analysis" vs. "forwarding validation vs. route selection". Just because a piece of information is useful doesn't necessarily mean it should be part of the BGP local RIB. In many cases, the BGP process and the Global RIB are deaggregated. If we wish to overload BMP with returning the contents Global-RIB, then it should be a separate table. Thanks, Acee A further complicating factor is that some implementations let non-BGP routes be effectively injected into the BGP route selection process in ways that make "best route using BGP route selection" somewhat more ambiguous. --- Add-paths is also somewhat ambiguous, I think, in a loc-rib context as it is specified in the current draft. If we are to send only the contents of the rib, is the path-id intended to reflect the learned path-id from a given peer's route? If so, I'm a bit confused by Shunwan's point about ecmp groups. This is because in order to safely send the ecmp contributors via add-paths encoding, we must overwrite the received path-id and locally generate it. Clearly we do this in a rib-out context, but that's not what I thought we were discussing here. -- 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] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)
[Note, message reordered and reformatted for quoting clarity] Tim, Thank you for your patience for my response. On Tue, Nov 20, 2018 at 05:42:37AM +, Tim Evens (tievens) wrote: > On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" > wrote: > > Jeff Haas said: > > > I do wish to get this point resolved. We have inconsistent pressure from > > > our own customer base as to whether they want to monitor best bgp vs. > > > "please give me something to let me stop needing parallel BGP sessions > > > for active route state". > > > > [Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a > > method to send best ecmp group to BMP Station. > > BMP client can signal add-paths capability to BMP Station via BMP Peer > > UP message, then BMP Station will know that the client will send multiple > > NLRI for one destination. > > That is my understanding. > > Per my limited knowledge about BMP, I don't understand why we need > > "parallel BGP sessions for active route state", Sorry. Can you explain it > > in detail? > > Best route for sure, unless add-paths is used. I would like to understand > your use-case more... When you mention the customer has to use "parallel > BGP sessions for active route state," are you saying that the customer > needs to establish multiple "monitoring" BGP peering sessions in order to > obtain what would have been available via BMP Adj-RIB-In Post Policy > monitoring? Today, customers running stock BMP (RFC 7854) often tend to have a parallel BGP peering session with their routers to monitoring stations. This permits them, in many cases, to correlate the results of BGP received paths vs. path selection. Sticking with a simplified example with BGP running its path selection solely on BGP routes, the active route in the system's RIB may end up being non-BGP. Typical examples are static routes, or IGP routes winning out over BGP routes. I.e. "administrative distance". The route used for forwarding will be the active route in the RIB. BGP itself will advertise the active route in most implementations in most circumstances. The issue in a simplified example: If the active route for a destination is a static route, a customer may want to know this vs. the best BGP route. This is needed to check why forwarding is happening as expected. Why not use rib-out? Because other BGP features may cause a route that isn't the active route to be sent. E.g. best-external. The problem is thus: Does the customer want to receive a loc-rib feed vs. the route being actively used for forwarding, or do they want to see the best BGP route? We've had requests for both, depending on use case - typically "BGP monitoring and path analysis" vs. "forwarding validation vs. route selection". A further complicating factor is that some implementations let non-BGP routes be effectively injected into the BGP route selection process in ways that make "best route using BGP route selection" somewhat more ambiguous. --- Add-paths is also somewhat ambiguous, I think, in a loc-rib context as it is specified in the current draft. If we are to send only the contents of the rib, is the path-id intended to reflect the learned path-id from a given peer's route? If so, I'm a bit confused by Shunwan's point about ecmp groups. This is because in order to safely send the ecmp contributors via add-paths encoding, we must overwrite the received path-id and locally generate it. Clearly we do this in a rib-out context, but that's not what I thought we were discussing here. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018)
Dear all, So far we only received one note in support of publication. Before declaring consensus one way or another I'd prefer if we have more feedback to work with. Your feedback is crucial to the IETF publication proces, so please take a few minutes to read the document and consider whether you are in favor of publication or have objections. We'll extend the WGLC with another week to allow the working group to provide feedback. Kind regards, JobOn Tue, Nov 6, 2018 at 11:56 AM Nick Hilliard wrote: > > Christopher Morrow wrote on 06/11/2018 04:34: > > Please have a read/review/comment and let's see if we can close out and > > move forward by the end of the month. > > no comments to add. please publish. > > Nick > > ___ > 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
