Re: [GROW] Barry Leiba's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)
Hi Barry, Thanks for catching that. PR https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/pull/14 should correct this. The rendered txt is https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/blob/iana_admin_label/draft-ietf-grow-bmp-adj-rib-out.txt Thanks, Tim On 7/16/19, 9:46 AM, "Barry Leiba" wrote: Thanks, Paolo: the updates take care of the DISCUSS and all but one of the editorial comments. It's a little hard to tell from the github PR, but it looks like the extra text in Section 9.3 is still there (after the addition of "byte"): << The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character. >> The second sentence appears to be a paste error and shouldn't be there... yes? Thanks for addressing my comments! Barry On Tue, Jul 16, 2019 at 12:19 PM Paolo Lucente wrote: > > > Hi Barry, > > Thanks for your comments. I hope it is felt that the following edits address them: > > https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd > > Paolo > > On 10 Jul 2019, at 08:21, Barry Leiba via Datatracker wrote: > > Barry Leiba has entered the following ballot position for > draft-ietf-grow-bmp-adj-rib-out-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ > > > > -- > DISCUSS: > -- > > Two small points that will be trivial to address: > > — Section 4 — > > The existing flags are defined in section 4.2 [RFC7854] and the > remaining bits are reserved for future use. They SHOULD be > transmitted as 0 and their values MUST be ignored on receipt. > > Why “SHOULD”? That’s inconsistent with Section 4.2 of 7854, which says “MUST”. > Failing to set the reserved bits to 0 will cause interoperability problems > with future extensions. > > The following fields in the Per-Peer Header are redefined: > > You aren’t redefining them completely, right? Don’t you mean, “When the O flag > is set to 1, the following fields in the Per-Peer Header are redefined:” ? > > > -- > COMMENT: > -- > > Some editorial comments: > > Throughout: there are five instances of “use-case”. “Use case” should not be > hyphenated (unless it’s used as a modifier, which it isn’t here). > > — Section 1 — > > An example of pre-policy verses post-policy is > > You mean “versus”, with a “u” (and also a second time later in the section). > > This document updates section > 4.2 [RFC7854] per-peer header by adding a new flag > > That’s an odd way to do the citation. Also, “per-peer header” is misplaced: > > NEW > This document updates the per-peer header in section 4.2 of [RFC7854] by adding > a new flag END > > The other places in the document that say “section 4.2 [RFC7854]” should also > be changed to “section 4.2 of [RFC7854]”. > > — Section 6.3.1 — > > The Information field contains a free-form > UTF-8 string whose length is given by the Information Length > field. > > As one UTF-8 character can be more than one byte, it’s best to specify whether > the length is in bytes or characters. I would say, “whose byte length is > given” (also in Section 9.3) > > — Section 9.3 — > The sentence, “The value is administratively given by the Information Length > field.” appears to be a copy/paste error, and should be deleted. > > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Barry Leiba's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)
Thanks, Paolo: the updates take care of the DISCUSS and all but one of the editorial comments. It's a little hard to tell from the github PR, but it looks like the extra text in Section 9.3 is still there (after the addition of "byte"): << The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character. >> The second sentence appears to be a paste error and shouldn't be there... yes? Thanks for addressing my comments! Barry On Tue, Jul 16, 2019 at 12:19 PM Paolo Lucente wrote: > > > Hi Barry, > > Thanks for your comments. I hope it is felt that the following edits address > them: > > https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd > > Paolo > > On 10 Jul 2019, at 08:21, Barry Leiba via Datatracker > wrote: > > Barry Leiba has entered the following ballot position for > draft-ietf-grow-bmp-adj-rib-out-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ > > > > -- > DISCUSS: > -- > > Two small points that will be trivial to address: > > — Section 4 — > > The existing flags are defined in section 4.2 [RFC7854] and the > remaining bits are reserved for future use. They SHOULD be > transmitted as 0 and their values MUST be ignored on receipt. > > Why “SHOULD”? That’s inconsistent with Section 4.2 of 7854, which says > “MUST”. > Failing to set the reserved bits to 0 will cause interoperability problems > with future extensions. > > The following fields in the Per-Peer Header are redefined: > > You aren’t redefining them completely, right? Don’t you mean, “When the O > flag > is set to 1, the following fields in the Per-Peer Header are redefined:” ? > > > -- > COMMENT: > -- > > Some editorial comments: > > Throughout: there are five instances of “use-case”. “Use case” should not be > hyphenated (unless it’s used as a modifier, which it isn’t here). > > — Section 1 — > > An example of pre-policy verses post-policy is > > You mean “versus”, with a “u” (and also a second time later in the section). > > This document updates section > 4.2 [RFC7854] per-peer header by adding a new flag > > That’s an odd way to do the citation. Also, “per-peer header” is misplaced: > > NEW > This document updates the per-peer header in section 4.2 of [RFC7854] by > adding > a new flag END > > The other places in the document that say “section 4.2 [RFC7854]” should also > be changed to “section 4.2 of [RFC7854]”. > > — Section 6.3.1 — > > The Information field contains a free-form > UTF-8 string whose length is given by the Information Length > field. > > As one UTF-8 character can be more than one byte, it’s best to specify whether > the length is in bytes or characters. I would say, “whose byte length is > given” (also in Section 9.3) > > — Section 9.3 — > The sentence, “The value is administratively given by the Information Length > field.” appears to be a copy/paste error, and should be deleted. > > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Roman Danyliw's No Objection on draft-ietf-grow-bmp-adj-rib-out-06: (with COMMENT)
Hi Roman, Thanks for your comments. Please see my replies to Alvaro and Benjamin. Paolo > On 11 Jul 2019, at 03:15, Roman Danyliw via Datatracker > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-grow-bmp-adj-rib-out-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ > > > > -- > COMMENT: > -- > > I support Ben’s DISCUSS about the Peer Down and Up Notification (i.e., Section > 6.3). > > Section 8, I also share Alvaro’s and Ben’s concern about whether any new > information is leaked if pre- and post-policy information is combined > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Benjamin Kaduk's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)
Hi Benjamin, Thanks for your comments. The following edits address most of them: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/2134855587c0b98f24533aa66d76e05f3fa6ed29#diff-42c33450ab1d1f6d1ec35e9a12c7bf24 My comments inline: On 9 Jul 2019, at 00:40, Benjamin Kaduk via Datatracker mailto:nore...@ietf.org>> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-grow-bmp-adj-rib-out-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ -- DISCUSS: -- The "Peer Up message Information" TLV type seems under-specified and under-motivated. (It is not mentioned in Abstract or Introduction.) Why does it need to be defined in this document, and what role is it expected to play? Who is the expected audience for it? Is it limited to the "group name"-like functionality described in Section 7.1? Why is cleartext appropriate, and are there any potential privacy considerations for any potential use cases? I’d +1 the reply from Jeff on this. -- COMMENT: -- Section 1 An example of pre-policy verses post-policy is when an inbound policy applies attribute modification or filters. Pre-policy would contain information prior to the inbound policy changes or filters of data. Post policy would convey the changed data or would not contain the filtered data. Can applying policy ever act as injecting new data? Yes. Jeff Haas proposed the edit below to draft-ietf-grow-bmp-loc-rib-04 — would the same/a similar edit address your point? https://github.com/paololucente/draft-ietf-grow-bmp-loc-rib/blob/master/draft-ietf-grow-bmp-local-rib.txt#L682-L684 Separately, I'd ask whether it's worth mentioning the new statistics types in the Introduction (skipping them from the Abstract is probably understandable). My feeling is that mentioning new statistics tyeps is too much detail for the introduction as well. While they integral part of the draft, they are not part of the core concept. Section 4 o Peer Address: The remote IP address associated with the TCP session over which the encapsulated PDU is sent. o Peer AS: The Autonomous System number of the peer from which the encapsulated PDU was sent. o Peer BGP ID: The BGP Identifier of the peer from which the encapsulated PDU was sent. I am not sure whether I'm reading these properly. Backing up, in regular RFC 7854 BMP, we have a BMP sender (router) that is speaking BGP to (presumably many) peers. These Peer Address/AS/BGP-ID fields are attributes of the BGP connections the router has to its peers, and are talking about how the data is coming in. For the Adj-RIB-Out version that we're defining in this document, we want to flip the sense, so that we are talking about what the router is sending on its outgoing BGP connections. In this way, the content being sent over BMP still reflects the origin of the BGP data, which makes sense. What's tripping me up is that we still talk about "the peer from which the encapsulated PDU was sent" -- IIUC this is "peer" in the "BGP peering" sense, so the data being sent over BMP is the local data from the router. Do we need to say "peer" at all, here, then? So, "The AS number for which the encapsulated PDU was sent", and "The BGP Identifier for which the encapsulated PDU was sent”? You are right. I catched this before in fact you see the “Peer Address” description actually makes sense; we forgot to edit accordingly the other two, Peer AS and Peer BGP ID. I did the edit now. o Timestamp: The time when the encapsulated routes were advertised (one may also think of this as the time when they were installed in the Adj-RIB-Out), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation- dependent. Are leap seconds included in this value? (Yes, I see that this language is basically taken directly from RFC 7854, which also left it underspecified.) I would propose to leave it underspecified as well, leaving it implementation specific. Section 5.1 Some attributes are set when the BGP message is transmitted, such as next- hop. Adj-RIB-Out Post-Policy
Re: [GROW] Alvaro Retana's Yes on draft-ietf-grow-bmp-adj-rib-out-06: (with COMMENT)
Hi Alvaro, Thanks for your comments. I hope it is felt that the following edits address them: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/76a68ad43b8b4352382f459fdf9c36ce0695a2f3#diff-42c33450ab1d1f6d1ec35e9a12c7bf24 Paolo PS: as part of addressing a comment of Barry Leiba i further edited the text of the xref to be “section 11 of”, see here: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd#diff-42c33450ab1d1f6d1ec35e9a12c7bf24R474 On 3 Jul 2019, at 22:34, Alvaro Retana via Datatracker mailto:nore...@ietf.org>> wrote: Alvaro Retana has entered the following ballot position for draft-ietf-grow-bmp-adj-rib-out-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ -- COMMENT: -- I am balloting Yes because I think this is important and needed work. However, I think the Security Considerations section is incomplete. Right now it just says: "It is not believed that this document adds any additional security considerations." The text should at least point to the Security Considerations from rfc7854. In §5.2, this example is offered: "a comparison between pre-policy and post-policy can be used to validate the outbound policy". While validation is the expected use case, it would be relatively simple to reconstruct the outbound policy itself. This fact means that the new functionality allows BMP receivers to learn information about the monitored peer that otherwise would not be available, which may result in loss of privacy, the ability to craft a route to bypass specific policy, etc.. The point that I'm making here goes beyond gaining unauthorized access to BMP data (which is mentioned in rfc7854), to the potential ability to figure out policy and then craft attacks based on that knowledge. The mitigation is of course to establish these sessions with authorized *and* trusted peers. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Barry Leiba's Discuss on draft-ietf-grow-bmp-adj-rib-out-06: (with DISCUSS and COMMENT)
Hi Barry, Thanks for your comments. I hope it is felt that the following edits address them: https://github.com/paololucente/draft-ietf-grow-bmp-adj-rib-out/commit/f3a9cb578d6f1a93c207f328f4f912c52cda6bcd Paolo On 10 Jul 2019, at 08:21, Barry Leiba via Datatracker mailto:nore...@ietf.org>> wrote: Barry Leiba has entered the following ballot position for draft-ietf-grow-bmp-adj-rib-out-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ -- DISCUSS: -- Two small points that will be trivial to address: — Section 4 — The existing flags are defined in section 4.2 [RFC7854] and the remaining bits are reserved for future use. They SHOULD be transmitted as 0 and their values MUST be ignored on receipt. Why “SHOULD”? That’s inconsistent with Section 4.2 of 7854, which says “MUST”. Failing to set the reserved bits to 0 will cause interoperability problems with future extensions. The following fields in the Per-Peer Header are redefined: You aren’t redefining them completely, right? Don’t you mean, “When the O flag is set to 1, the following fields in the Per-Peer Header are redefined:” ? -- COMMENT: -- Some editorial comments: Throughout: there are five instances of “use-case”. “Use case” should not be hyphenated (unless it’s used as a modifier, which it isn’t here). — Section 1 — An example of pre-policy verses post-policy is You mean “versus”, with a “u” (and also a second time later in the section). This document updates section 4.2 [RFC7854] per-peer header by adding a new flag That’s an odd way to do the citation. Also, “per-peer header” is misplaced: NEW This document updates the per-peer header in section 4.2 of [RFC7854] by adding a new flag END The other places in the document that say “section 4.2 [RFC7854]” should also be changed to “section 4.2 of [RFC7854]”. — Section 6.3.1 — The Information field contains a free-form UTF-8 string whose length is given by the Information Length field. As one UTF-8 character can be more than one byte, it’s best to specify whether the length is in bytes or characters. I would say, “whose byte length is given” (also in Section 9.3) — Section 9.3 — The sentence, “The value is administratively given by the Information Length field.” appears to be a copy/paste error, and should be deleted. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Path marking using BMP - TLVs
Hi Yunan, > Regarding your suggestion of adding a "ECMP" path type, well, the currently > defined "0x0004 -- Primary Path" path type should do the work. In fact, the > so-called "Primary Path" in this draft refers to all the ECMP paths > (including the "Best path"). Of course, we can further work on the naming. Just to clarify. There can be multiple primary paths and one of it will be the best path as well. Correct? If yes perfect. Thank you. > May I ask the use case for your proposal of adding "the reason why it is > considered ECMP" reason string? When troubleshooting BGP, one of the most use cases are why a path is not installed for forwarding. One reason can be because of various configuration knobs such as: Configuration Guide - IP Unicast Routing - BGP Configuration - Configuring BGP Load Balancing https://support.huawei.com/enterprise/en/doc/EDOC114198/19f9347b/configuring-bgp-load-balancing - maximum load-balancing (maximum-path) - load-balancing as-path-relax At the end we will search within BMP local-RIB collected metrics the same way as you would do on CLI described in this document. The big difference is that we will do it across all the routing contexts and across the network. Thus, much more efficiently. Configuration Guide - IP Unicast Routing - BGP Configuration - Verifying the BGP Route Selection and Load Balancing Configuration https://support.huawei.com/enterprise/en/doc/EDOC114198/6efe04ed/verifying-the-bgp-route-selection-and-load-balancing-configuration I always have the closed loop operation in mind as well. What BMP metrics do I need so that I can trigger a configuration change to achieve the desired intend. The intend is that I want a certain selection of paths be ECMP. Two possible use cases can happen: - To many are installed. Some of them are undesired. - To less are installed. Some should but aren't. If they are not installed, we should see them in "Non-installed path" or perhaps "Backup path" or "Best external path". > Do you have any specific reason string in mind for the ECMP paths? If they are installed then it would be great to understand in the ECMP decision process of the router within the routing context which was the last decision step. For instance: - AS-PATH relax - eBGP multipath - iBGP multipath - eiBGP multipath draft-lapukhov-bgp-ecmp-considerations-02 shows what possibilities we have. If we see a route marked as ECMP with "eBGP multipath" but was not intend to be part of ECMP, we could remove the configuration line "maximum load-balancing ebgp" and verify if desired route is now marked as "Non-installed path" or perhaps "Backup path" or "Best external path". I hope this makes sense. Feedback very welcome. Kind regards Thomas Graf Network Engineer Datacenter Functions Telefon +41-58-223 84 01 Mobile +41-79-728 80 12 thomas.g...@swisscom.com Swisscom (Schweiz) AG IT, Network & Infrastructure Datacenter Functions Binzring 17 8045 Zürich www.swisscom.com Postadresse: Binzring 17 8045 Zürich -Original Message- From: Guyunan (Yunan Gu, IP Technology Research Dept. NW) Sent: Monday, July 15, 2019 11:52 AM To: Graf Thomas, INI-ONE-WSN-DCF ; juancamilo.card...@imdea.org; grow@ietf.org; pa...@ntt.net Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org Subject: RE: [GROW] Path marking using BMP - TLVs Hi Thomas, Thanks a lot for your comments on the draft, and your elaboration on the usage of Path Marking TLV! Regarding your suggestion of adding a "ECMP" path type, well, the currently defined "0x0004 -- Primary Path" path type should do the work. In fact, the so-called "Primary Path" in this draft refers to all the ECMP paths (including the "Best path"). Of course, we can further work on the naming. Thanks for sharing the ECMP reference: raft-lapukhov-bgp-ecmp-considerations-02. May I ask the use case for your proposal of adding "the reason why it is considered ECMP" reason string? Well, it's easy for me to understand that users may wonder why a path is "non-best". Do you have any specific reason string in mind for the ECMP paths? BR, Yunan -Original Message- From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] Sent: Friday, July 12, 2019 8:44 PM To: juancamilo.card...@imdea.org; grow@ietf.org; pa...@ntt.net; Guyunan (Yunan Gu, IP Technology Research Dept. NW) Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org Subject: RE: [GROW] Path marking using BMP - TLVs Hi Camilo, Paulo and Yunan, Thank you very much for this exciting and very useful draft. This will make draft-ietf-grow-bmp-local-rib even more useful. On top of having access to all (not only to the best) BGP paths in BGP local RIB, thanks to this draft, we will finally understand how these BGP paths are installed in RIB/FIB. We will be able to get an network
