Re: [GROW] Genart last call review of draft-ietf-grow-bmp-local-rib-10
Hi Thomas, Thank you for your review and catching these nits. Please see my comments marked [tievens] inline. You can see my pending PR (https://github.com/TimEvens/draft-ietf-grow-bmp-loc-rib/pull/22) for all these changes. Once approved, I'll submit revision 11. On 3/20/21, 3:33 AM, "Thomas Fossati via Datatracker" wrote: Reviewer: Thomas Fossati Review result: Ready with Issues Nits: * Figure 1: * a couple of '+' are missing in the top-right and bottom-right corners of the Adj-RIB-In (Post) box; [tievens] Updated. * "e.g." => "e.g.," in multiple places; [tievens] Updated. * A few acronyms are not expanded: * IGP, BGP-LS, SPF, CSPF. VRF, ASN, BGP-ID, RD (route distinguisher?) [tievens] I've updated these abbreviations following https://tools.ietf.org/html/rfc7322#section-3.6. I suppose the statement "The exception is an abbreviation that is so common that the readership of RFCs can be expected to recognize it immediately" is a bit subjective. * Section 1.1 * "directly effects" => "directly affects" [tievens] Updated. * Section 3 * "an instance of an instance of BGP-4" => "an instance of BGP-4" [tievens] Updated. * Section 5 * "post-policy" => "Post-Policy" * "ie." => "i.e.," [tievens] Updated. * Section 5.1 * "in The Loc-RIB, expressed" => "in the Loc-RIB, expressed" [tievens] Updated. * Section 5.2.1 * Consider using "Peer Up" instead of "Peer UP" for consistency with the capitalisation use in RFC7854 (also in Sections 5.3, 5.4.1, 6.1, 6.1.1, 6.1.3, and 8.3) [tievens] Updated to Peer Up. * Section 5.3 * "peer Down" => "Peer Down" [tievens] Updated. * Section 6.1 * "local router emulated peer." maybe "locally emulated peer." [tievens] Updated. * Section 6.1.1 * "since it represents the same Loc-RIB instance" => "since they represents the same Loc-RIB instance" [tievens] Updated. Editorial improvements: * Section 1.1 * I had some troubles parsing: "Complexities introduced by the lack of access to Loc-RIB in order to derive (e.g. correlate) peer to router Loc-RIB:", in particular the bit "in order to derive (e.g. correlate)". Is it "in order to derive (i.e., correlate)" or "in order to derive (or correlate)" or "in order to correlate"? [tievens] How about changing it to: "Complexities introduced when correlating a received Adj-RIB-In as a router Loc-RIB:" * What does "suppresses more specifics" mean? Is there a term missing? [tievens] I've updated it to: "more specific prefixes" * What does "derive a Loc-RIB to a router" mean? Is it "derive the Loc-RIB of a router" instead? [tievens] Yes. Updated. * I find this "The BGP-IDs and session addresses to router correlation requires additional data" a bit hard to parse. Maybe re-flow it as: "Correlating BGP-IDs and session addresses to a router requires additional data" [tievens] Updated to use your re-flow… * Section 4.1 * I find "to distinguish that it represents Loc-RIB with or without RD and local instances" a bit hard to parse. I suggest rephrasing it to make it clearer. [tievens] Changed to: "A new peer type is defined for Loc-RIB to distinguish that it represents the router Loc-RIB, which may have a route distinguisher (RD)." * Section 5 * Re: setting the F flag. It'd help if you put a forward ref to Section 6.1.2 here. (Before getting to 6.1.2 I got baffled by F; in particular, it was not clear to me from the surrounding text what is the monitoring station supposed to do with partial information without knowing exactly how much and what kind of info has been left out.) [tievens] Updated. Slight rewording: "As described in Section 6.1.2, a subset of Loc-RIB routes MAY be sent to a BMP collector by setting the F flag." * Section 5.2 * Should add-paths be ADD-PATH instead? If so, maybe you could also add an informative reference to RFC7911 [tievens] Updated to ADD-PATH with reference. * In "The duplication allows the BMP receiver to use existing parsing" could you clarify what "existing parsing" mean? [tievens] Updated to: "Repeat of the same Sent Open Message. The duplication allows the BMP receiver to parse the expected received OPEN message as defined in section 4.10 of [RFC7854]." * Section 5.5 * Why would the receiver decide not to ignore a Route Mirror message? And what would happen if it decided so? I'm asking because I don't understand the reasons for a SHOULD rather than a MUST here. [tievens] Updated to clarify. "Section 4.7 of [RFC7854] defines Route Mirroring for verbatim duplication of messages received. This is not applicable to Loc-RIB considering PDUs are originated by the router. Any received Route Mirroring messages SHOULD be ignored." * Section 6.1.1 * In "There MUST be multiple emulated peers for each Loc-RIB instance" I am unsure whether what you want to say is that "there MUST be
Re: [GROW] is TCP the right layer for BMP session resumption?
Hi Tim, Many thanks for the feedback and input. Much appreciated. My apology for late reply. In section 5 of draft-tppy-bmp-seamless-session https://tools.ietf.org/html/draft-tppy-bmp-seamless-session-00#section-5 The BMP session lifecycle (not to be confused with TCP session lifecycle) is extended with this draft. The BMP session no longer closes with the TCP session. Once the TCP TFO session closes, a BMP session timeout counter starts counting down. If the TCP TFO session is re-established within this time frame, than the BMP session is considered to be "up" during the TCP TFO reestablishment time. The TCP back pressure from BMP monitoring station to the router occurs under congestion. Therefore buffering at the monitored router for the BMP session occurs during normal BMP session lifetime. With draft-tppy-bmp-seamless-session, we make use of this buffer mechanism. Different is that it is being used not only in congestion, but also between re-establishment of the TCP TFO session (not to be confused with the BMP session). As you pointed out, it is important that BMP message type peer_up and peer_down are not being lost during the re-establishment of the TCP TFO session. For that very purpose we described in section 5 that buffering must occur for all BMP message types which is including BMP peer_up, peer_down, statistics, route-mirroring and route-monitoring. I take that as an input to more clearly state that in the draft. Jakob made an interesting input that for BMP buffer optimization purposes only withdrawals of route-monitoring messages should be buffered. I agree that BMP lacks of a mechanism that the monitoring station can request a BMP route-monitoring refresh to the monitored router. I agree as well that if that mechanism would be present, than the BMP session lifecycle should be re-adjusted to disable/enable initial BMP RIB dump with route-monitoring or not. Where I am unsure is wherever it makes sense to implement BMP route-refresh within the BMP session protocol or not. Therefore changing BMP to be a bi-directional protocol. Here I like to get the feedback from the GROW mailing list. If you do see value in BMP route-refresh as well, how granular it should be, and wherever it should be part of the BMP session or not. Best wishes Thomas -Original Message- From: Tim Evens (tievens) Sent: Friday, March 12, 2021 10:36 PM To: Graf Thomas, INI-NET-TCZ-ZH1 ; Jakob Heitz (jheitz) ; rainsword.w...@huawei.com; rob...@raszuk.net; j...@dataplane.org Cc: grow@ietf.org Subject: Re: [GROW] is TCP the right layer for BMP session resumption? The use of UDP vs TCP is use-case specific. For example, are you logging and don't care if you miss messages or are you maintaining RIB states for applications like SDN? In terms of accurate logging (ordered regardless of timestamp) and maintaining state… TCP is required otherwise we introduce out-of-order and loss recovery complexities. BGP PDU order is required in order to track changes and to maintain accurate RIB states. While a SEQ number in BMP can help to re-sequence messages, that puts a lot on every BMP receiver/client. For example, BMP receivers will now have to buffer messages and re-sequence them to ensure proper ordering when processing. If buffers are exceeded, what happens to those messages and how would the BMP receiver request those missing messages/pdus? Regardless of how, this adds complexity to both the sender and receiver. IMO, this is not addressing the problem of RIB dumps or picking up where you left off on reconnect. The draft suggests to use TCP_FAST_OPEN, which I believe adds more complexity while not solving the other challenges relating to RIB dumps/refreshes. It doesn't address PEER UP handling on reconnect, how to handle peers that change or are new during the no-connection time, and on how to request a peer refresh when needed. It also doesn't address the buffer exhaustion problem on the sender (router) side. IMO, the sender should be configured using buffer sizes per receiver and not based on time. The amount of time is relative to the number of updates. For example, a refresh to update policies will flood/exhaust buffers quickly in seconds while normal updates may last for minutes without buffer exhaustion. There are at least three problems with RIB dumps/reconnects to be solved: 1) Transient reconnects due to network failures, restarts of receivers, etc. are resulting in unnecessary INITs, RIB dumps, and PEER UPs. A PEER UP normally means that the receiver invalidates all previous RIB entries as it does not know if things were changed/removed during the gap (from last PEER UP/DOWN) period. A RIB dump is expected to refresh the peer RIB upon a PEER UP. IMO, what we need is application level control so the BMP receiver can send a control message to the sender to indicate what's needed per-peer. For example, a receiver restart (new
[GROW] Secdir last call review of draft-ietf-grow-bmp-local-rib-10
Reviewer: Chris Lonvick Review result: Has Nits Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. The authors state in the Security Considerations section that the same considerations that are documented in Section 11 of RFC 7854 also apply to this document. I see no reason to doubt that and I believe that is appropriate for this document. The second and third sentences of the Security Considerations section may need to be reworked. Although I skimmed the rest of the document, these were the only nits I could see. For the second sentence, rather than: Implementations of this protocol SHOULD require to establish sessions with authorized and trusted monitoring devices. Perhaps, Implementations of this protocol SHOULD require +monitored routers+ to establish +secure+ sessions with authorized and trusted monitoring -devices-+stations+. The term "monitoring devices" is not used anywhere else in the document, and only once in RFC 7854. On the other hand "monitoring stations" is used extensively in both. For the third sentence, rather than: It is also believed that this document does not add any additional security considerations. Perhaps, It is also believed that this document does not add any +features that require any+ additional security considerations. Best regards, Chris ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt
Hi Mike & Authors I would like to start my thanking the authors in formulating this much needed GROW Best Practice draft to help tackle the elephant in the room on the use of excessive pretending by operators on the internet and documenting ramifications from excessive pretending. I would recommend changing the draft from Informational to BCP as this is truly a worthy cause to standardize. I can help provide some more operations feedback to help make this draft a BCP for operators use of prepending and routing policies. The draft is very well written as you have a fine team of authors. Few additions to section 2 from a Tier 1 such as Verizon from a NOC and operations standpoint. There are a lot of permutations you can get into and I think most are covered here already. >From an operations POV the general goal of the NOC is monitoring traffic and traffic pattern shifts as well as taking links out of service for upgrades and maintenance. In those instances links are prepended costed out so they don’t take traffic in an active / backup setup. In general the goal is to have all inter provider links to other carrier to load balance traffic as evenly as possible some simple and so more complex policies involving prepending. May want to mention prepend is typically outbound and conditional local preference is used inbound within for path preference within the operators core. There maybe some cases where prepend is done inbound to cost out a link but generally not done as a lower prepend coming from a peering AS could alter the preferred path within the operators AS and have unwanted consequences. Also the negative ripple effects of outbound prepend done multiple times in the same outbound direction by multiple providers chained together cascading effect of a growing as path effects that can lead to issues such as route leaking. Counter prepends in opposing directions by non directly connected peers ripple effect of the path vector with excessive prepending. May also want to talk about BGP atomic aggregates and as-set and care to be taken with aggregation and LPM matching leaked route preference over aggregate can lead to unwanted traffic pattern changes. Use cases: Conditional preference and prepending making all links conditionally preferred and active or backup based on set of conditions. Conditionally prefer one ISP over another ISP same or different ASBR. Conditionally prefer one ASBR over another same site or between multiple sites. This typically for conditional or non conditional would be done via local preference within the operators AS not AS prepend inbound. Conditionally use one path exclusively and other path solely as backup. In the diagram I would make it more clear showing A and B as part of AS 1 and D and C part of AS 2 and E and F part of AS 3. So typically within an operator core to most providers use conditional local preference inbound to cost out a link and use local preference since it’s above as-path in BGP path selection so that even if E sent a 2x prepend outbound that ripple into the providers AS won’t impact the routing so B will still route through C and not reroute through shorter path through D. Local preference is non transitive so the operators AS is not affected, however a downstream provider connected to AS 1 would see the 2x sent by E and create that ripple effect possibly alter the pathing. That is also another adverse affect of using prepending inbound as that prepending as well can have a cascading adverse effect. The cascading prepending adverse effect can happen in both directions. The issue with prepending as a method of costing out a link has similar adverse cascading affects with IGP costing of transit links having the same type of rippling cascading type adverse affect. Under alternatives to AS Path prepending for inbound we could mention what I stated to use conditional or non conditional local preference as an alternative to prepending. Another option to prepending is use of a conditional weight. Weight is at the top of the path selection so have to be carful and make conditional to account for failover and all scenarios. Under best practices mention conditional prepending if you have to prepend and not ever use non conditional prepending. Kind Regards Gyan On Thu, Mar 18, 2021 at 11:36 PM Michael McBride < michael.mcbr...@futurewei.com> wrote: > *>*Is this going to update BCP194/RFC7454? I don't see any reference in > the draft. > > > > We probably should. Good suggestion. I was thinking updating 8195 but 7454 > appears more appropriate. > > > > We will update the draft, based upon comments from last week, and add 7454 > unless we hear otherwise. > > > > Thanks, > > mike > > > > On Tue, Feb 9, 2021 at 11:29 AM wrote: > > > 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 : AS Path Prepending >
