Re: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Thanks John, Regards, Benoit Hi Benoit, Thanks for your comments. I'll follow up on your discuss by and by, likely it will be most convenient to huddle with the other authors in Yokohama. Other comments in-line below. On Oct 15, 2015, at 6:10 AM, Benoit Claise wrote: Benoit Claise has entered the following ballot position for draft-ietf-grow-bmp-15: 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/ -- DISCUSS: -- This DISCUSS is in line with Mahesh's OPS DIR review. If BMP (which I consider like a span port feature btw) troubleshooting shows that the BGP configuration is required, then the standard way to configure BGP will be https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. I'm wondering about the link between BMP and the following draft-ietf-idr-bgp-model-00.txt YANG models: bgp-types.yang bgp-policy.yang bgp-multiprotocol.yang bgp.yang bgp-operational.yang Specifically: are we able to map the Per-Peer Header (section 4.2) and Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either because the field information come from the same reference (ex: both this draft and the idr one have the same reference for the Peer Distinguisher), or because specific references to the YANG key information is provided. I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model authors should sit down and go through the exercise of mapping the BMP data model into the YANG data model, for a couple of troubleshooting scenarios. The OPS world suffers from too many different data models (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we won't fall into the trap of defining a new one without at least providing the necessary mappings. Note: I see that sysName and sysDescr make the link with the MIB world, that's a step in the right direction. Below is Mahesh's OPS DIR review: Summary: This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. The document is on standards track and defines another monitoring method specifically for BGP. The original draft is dated 2005, long before NETCONF or YANG were defined, and when there was probably no way to view routes. With the advent of NETCONF and specifically the BGP YANG model, which is currently a WG document, it would be helpful to know how BMP stands apart. The NETCONF notification structure allows for notifications described in this draft and the ability to collect stats reports and route monitoring. It would be helpful to know how BMP compliments that capability. I don't have the expertise with NETCONF to provide an accurate comparison between the two. Perhaps someone else on the cc can chime in. -- COMMENT: -- COMMENT: - From the write-up: -- The BMP protocol has been a GROW document for quite sometime. The -- length of time has allowed the document to have multiple implementations -- completed, along with incorporating working group feedback into the spec -- and polishing the document. Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section" Noted, thank you. - following nits need to be addressed in the document. Miscellaneous warnings: == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. I've taken notice of the nit and elected to ignore the comment. Note that idnits is mistaken about the first submissi
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Wed, Oct 14, 2015 at 05:09:14PM -0400, Jeffrey Haas: > On Wed, Oct 14, 2015 at 08:47:17PM +, heasley wrote: > > For debugging purposes, I'd perfer to see ALL protocols have a "cleartext" > > option - not for normal runtime, for debugging. its darwinian, if someone > > chooses to always run cleartext. > > This is actually a big deal with regards to streaming routing protocols. > > It's been my unfortunate experience over the years that most BGP developers > have more than the usual familiarity with the implementation behaviors of > TCP. Even *normal* TCP has ugly properties that negatively impact BGP. > Introduce another couple layers between the protocol PDUs and the final set > of transports and it's a royal pain to do anything about. > > To give a simplified and common issue, when BGP peering sessions on > otherwise quiet links time out, you get to look at things like the TCP > windows to see if your PDUs ever made it out and were advertised on the wire > and acknowledged by the other side. This often requires the sequencing data > from both sides to try to pin down the problems. > > Now introduce the peculiarities of other encapsulations and their > interactions with the underlying timings of the protocol. If I'm running > TLS, how do I know that it hasn't chosen to hold up a PDU for an extra > second or two in order to either have a full enough payload to make the > crypto library happy? > > I realize that these peculiarities can be addressed in the long-run, but I > tend to see these issues as having negative consequences on the operational > stability of the underlying protocol. I may not follow you; I think that you are saying that by removing the "non-cleartext" path for purposes of debugging, you may have changed the behavior that is causing the thing that you are attempting to debug. I agree with that, but it does not discount the utility of being able to capture whats on the wire for debugging. > > I do not care if your suggested text is added or not; the existing security > > section of the draft covers the subject for me. Nor do I disagree that it > > could support TLS, just do it in a separate draft and move this one along. > > > > I suspect if you examined the idea of TLS as another one of the recommended > transport security options in the context of the existing text, you'd be > fine with that too. By which you mean that, as implied in the security section of the draft, one could run bmp over a vpn, ipsec tunnel, etc implemented external from BMP - yes, I'm happy with the existing text. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Hi Benoit, Thanks for your comments. I'll follow up on your discuss by and by, likely it will be most convenient to huddle with the other authors in Yokohama. Other comments in-line below. On Oct 15, 2015, at 6:10 AM, Benoit Claise wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-grow-bmp-15: 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/ > > > > -- > DISCUSS: > -- > > This DISCUSS is in line with Mahesh's OPS DIR review. > If BMP (which I consider like a span port feature btw) troubleshooting > shows that the BGP configuration is required, then the standard way to > configure BGP will be > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. > I'm wondering about the link between BMP and the following > draft-ietf-idr-bgp-model-00.txt YANG models: > > bgp-types.yang > bgp-policy.yang > bgp-multiprotocol.yang > bgp.yang > bgp-operational.yang > > Specifically: are we able to map the Per-Peer Header (section 4.2) and > Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either > because the field information come from the same reference (ex: both this > draft and the idr one have the same reference for the Peer > Distinguisher), or because specific references to the YANG key > information is provided. > I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model > authors should sit down and go through the exercise of mapping the BMP > data model into the YANG data model, for a couple of troubleshooting > scenarios. The OPS world suffers from too many different data models > (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we > won't fall into the trap of defining a new one without at least providing > the necessary mappings. Note: I see that sysName and sysDescr make the > link with the MIB world, that's a step in the right direction. > > > Below is Mahesh's OPS DIR review: > > Summary: > This document defines a protocol, BMP, that can be used to monitor BGP > sessions. BMP is intended to provide a convenient interface for > obtaining route views. Prior to introduction of BMP, screen-scraping was > the most commonly-used approach to obtaining such views. The design > goals are to keep BMP simple, useful, easily implemented, and minimally > service-affecting. BMP is not suitable for use as a routing protocol. > > The document is on standards track and defines another monitoring method > specifically for BGP. The original draft is dated 2005, long before > NETCONF or YANG were defined, and when there was probably no way to view > routes. With the advent of NETCONF and specifically the BGP YANG model, > which is currently a WG document, it would be helpful to know how BMP > stands apart. The NETCONF notification structure allows for notifications > described in this draft and the ability to collect stats reports and > route monitoring. It would be helpful to know how BMP compliments that > capability. I don't have the expertise with NETCONF to provide an accurate comparison between the two. Perhaps someone else on the cc can chime in. > -- > COMMENT: > -- > > COMMENT: > - From the write-up: > > -- The BMP protocol has been a GROW document for quite sometime. The > -- length of time has allowed the document to have multiple > implementations > -- completed, along with incorporating working group feedback into the > spec > -- and polishing the document. > > Btw, don't forget, for future documents, the experimental RFC 6982 > "Improving Awareness of Running Code: The Implementation Status Section" Noted, thank you. > - following nits need to be addressed in the document. > > Miscellaneous warnings: > > > > == The document seems to contain a disclaimer for pre-RFC5378 work, but > was > first submitted on or after 10 November 2008. The disclaimer is > usually > necessary only for documents that revise or obsolete older RFCs, and > that > take significant amounts of text from those RFCs. If you can > contact all > authors of the source material and they are willing to grant the > BCP78 > rights to the IETF Trust, you can and should remove the disclaimer. > > Otherwise, the disclaimer
Re: [GROW] Kathleen Moriarty's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS)
On 10/15/15 2:36 PM, John Scudder wrote: > On Oct 13, 2015, at 10:06 PM, Kathleen Moriarty > wrote: >> >> It would be nice if there >> was an MTI for transport > > I owe you a proper reply, but can you decode "MTI" for me please? > MTI = Mandatory To Implement. Brian signature.asc Description: OpenPGP digital signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Kathleen Moriarty's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS)
On Oct 13, 2015, at 10:06 PM, Kathleen Moriarty wrote: > > It would be nice if there > was an MTI for transport I owe you a proper reply, but can you decode "MTI" for me please? Thanks, – John ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Stephen Farrell's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
I'll reply to this at greater length later, but for now let me associate myself with Jeff and Heas's comments. --John > On Oct 14, 2015, at 12:44 PM, Stephen Farrell > wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-grow-bmp-15: 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/ > > > > -- > DISCUSS: > -- > > > Apologies in advance for the rant, but this is a new > protocol and not something deployed for decades that can't > be fixed. (At least so says the write-up.) > > The state of security here is just sad. It reminds me of the > 1980's. And introducing new protocols without improving that > goes against very long held IETF consensus that protocols > need to have some actually usable strong security mechanism > defined. It seems the wg here get that but are choosing to > do nothing about it - I mean in their day-jobs, not that > writing RFC text is "doing something." The responses to the > secdir review seem to make it clear that the claim that > IPsec can be used is mythical, so this discuss to ask that > the security considerations properly document the utter > absence of any modern way to secure this protocol and not > pretend that there are ways that can be used to secure this > in the real world. I would suggest text that simply says > that: > > "This is an inherently insecure protocol for no particularly > good reason and mostly due to the lack of implementation of > basic security mechanisms (SSH, TLS) but also due to a lack > of customer/operator pressure to ensure those are present, > usable and interoperate, despite evidence that attacks on > the links over which this data will be sent are ongoing." > > I'd not be surprised if you preferred some other text:-) > > > -- > COMMENT: > -- > > > Separate to the discuss, I have some non-blocking points, > that I think resonate with Kathleen's discuss: > > Why is using TLS not a no-brainer for this? Given the likes > of the Belgacom and Gemalto reports, I would love to > understand why people are still willing to buy and sell > equipment without such basic features. The "explanation" > that nobody needs it or nobody provides it seems off base > here - this is new code and a new interface, and the > relevant security protocols (SSH, IPsec and TLS) are all > nearly or more than 20 years old. And that is all the more > the case for a new protocol like this that is not likely in > the critical path and where the monitoring statiion may be > off to the side so the traffic flows via BMP in places where > BGP doesn't go implying different threat levels, that may > need different protection. > > My best guess as to causes for now is that people are just > used to doing nothing and have done that for so long they > seem to think that doing nothing is the only possibility. > (That's how business models get disrupted isn't it?) Can you > educate me some more on this? > > (And yes, I get that all the stuff as to why AO isn't > available for BGP, but this is not BGP. It's our apparent > need to keep the security level down at the "crap" marker > that I don't get.) > > > ___ > 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] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Typo in one email address. Corrected now. Regards, Benoit Benoit Claise has entered the following ballot position for draft-ietf-grow-bmp-15: 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/ -- DISCUSS: -- This DISCUSS is in line with Mahesh's OPS DIR review. If BMP (which I consider like a span port feature btw) troubleshooting shows that the BGP configuration is required, then the standard way to configure BGP will be https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. I'm wondering about the link between BMP and the following draft-ietf-idr-bgp-model-00.txt YANG models: bgp-types.yang bgp-policy.yang bgp-multiprotocol.yang bgp.yang bgp-operational.yang Specifically: are we able to map the Per-Peer Header (section 4.2) and Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either because the field information come from the same reference (ex: both this draft and the idr one have the same reference for the Peer Distinguisher), or because specific references to the YANG key information is provided. I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model authors should sit down and go through the exercise of mapping the BMP data model into the YANG data model, for a couple of troubleshooting scenarios. The OPS world suffers from too many different data models (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we won't fall into the trap of defining a new one without at least providing the necessary mappings. Note: I see that sysName and sysDescr make the link with the MIB world, that's a step in the right direction. Below is Mahesh's OPS DIR review: Summary: This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. The document is on standards track and defines another monitoring method specifically for BGP. The original draft is dated 2005, long before NETCONF or YANG were defined, and when there was probably no way to view routes. With the advent of NETCONF and specifically the BGP YANG model, which is currently a WG document, it would be helpful to know how BMP stands apart. The NETCONF notification structure allows for notifications described in this draft and the ability to collect stats reports and route monitoring. It would be helpful to know how BMP compliments that capability. -- COMMENT: -- COMMENT: - From the write-up: -- The BMP protocol has been a GROW document for quite sometime. The -- length of time has allowed the document to have multiple implementations -- completed, along with incorporating working group feedback into the spec -- and polishing the document. Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section" - following nits need to be addressed in the document. Miscellaneous warnings: == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-idr-error-handling has been published as RFC 7606 . ___
[GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)
Benoit Claise has entered the following ballot position for draft-ietf-grow-bmp-15: 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/ -- DISCUSS: -- This DISCUSS is in line with Mahesh's OPS DIR review. If BMP (which I consider like a span port feature btw) troubleshooting shows that the BGP configuration is required, then the standard way to configure BGP will be https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. I'm wondering about the link between BMP and the following draft-ietf-idr-bgp-model-00.txt YANG models: bgp-types.yang bgp-policy.yang bgp-multiprotocol.yang bgp.yang bgp-operational.yang Specifically: are we able to map the Per-Peer Header (section 4.2) and Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either because the field information come from the same reference (ex: both this draft and the idr one have the same reference for the Peer Distinguisher), or because specific references to the YANG key information is provided. I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model authors should sit down and go through the exercise of mapping the BMP data model into the YANG data model, for a couple of troubleshooting scenarios. The OPS world suffers from too many different data models (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we won't fall into the trap of defining a new one without at least providing the necessary mappings. Note: I see that sysName and sysDescr make the link with the MIB world, that's a step in the right direction. Below is Mahesh's OPS DIR review: Summary: This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. The document is on standards track and defines another monitoring method specifically for BGP. The original draft is dated 2005, long before NETCONF or YANG were defined, and when there was probably no way to view routes. With the advent of NETCONF and specifically the BGP YANG model, which is currently a WG document, it would be helpful to know how BMP stands apart. The NETCONF notification structure allows for notifications described in this draft and the ability to collect stats reports and route monitoring. It would be helpful to know how BMP compliments that capability. -- COMMENT: -- COMMENT: - From the write-up: -- The BMP protocol has been a GROW document for quite sometime. The -- length of time has allowed the document to have multiple implementations -- completed, along with incorporating working group feedback into the spec -- and polishing the document. Btw, don't forget, for future documents, the experimental RFC 6982 "Improving Awareness of Running Code: The Implementation Status Section" - following nits need to be addressed in the document. Miscellaneous warnings: == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-idr-error-handling has been published as RFC 7606 ___ GROW mailing list GROW@ietf.org https:
