Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
See one typo. From: GROW on behalf of "Acee Lindem (acee)" Date: Monday, July 11, 2022 at 10:45 AM To: Gyan Mishra , Yingzhen Qu Cc: IDR List , "grow@ietf.org grow@ietf.org" , lsr Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol Hi Gyan, From: GROW on behalf of Gyan Mishra Date: Monday, July 11, 2022 at 1:41 AM To: Yingzhen Qu Cc: IDR List , "grow@ietf.org grow@ietf.org" , lsr Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol Hi Yingzhen So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 already supports instances, how is the GT instance differentiated from any other routed instance? Did you read the draft? The main difference is that since OSPF-GT is generalized to be used for non-routing, there is installation of routes. “No installation of routes”… OSPF-GT neighbors need not be directly attached (or come with complex OSPF Virtual-Link considerations and processing). Depending on the application, the extent to which the “condition of reachability” is enforced MUST be described in the document describing the application usage of OSPF-GT. For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an opaque option code for GTI. For OSPFV3 it would use an OSPFV3 function code for GTI. So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a OSPF GTI neighbor ? It could be but that is just one OSPF-GT use case and would need to be described in a separate draft. Would you still need a standard routed OSPF neighbor for reachability or I guess you could put a static route on the controller across the NBI for reachability. Yes. Is that correct? Are there any operators implementations of this using OSPF GTI in place of BGP-LS? You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in place of BGP-LS is yet to be written, it would be very strange indeed if it were already deployed. RFC 6823 provides the same GTI solution for ISIS. Yes and no, OSPF-GT is able to cover a much wider range of applications than RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) being much more flexible than IS-IS. Are there any operators implementations of this using OSPF GTI in place of BGP-LS? No - answered above. Thanks, Acee Kind Regards Gyan On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu mailto:yingzhen.i...@gmail.com>> wrote: Hi, Since we’re discussing possible solutions, I’d like to bring up the draft: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ We just submitted a new version. The name of the document is changed to “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a possible replacement of BGP-LS. Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. It uses the reachability info calculated by routing protocols, OSPF, ISIS or static routing etc.. It provides mechanisms to advertise non-routing information, and remote neighbor is supported. Reviews and comments are welcome. Thanks, Yingzhen On Jul 9, 2022, at 5:33 PM, Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: During the interim meeting we should keep it open to discuss all possible alternatives to BGP-LS. Thanks Gyan On Sat, Jul 9, 2022 at 4:45 PM Susan Hares mailto:sha...@ndzh.com>> wrote: Jeff: An interim sounds like a good plan. [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, · Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. · Refining any potential non-BGP solutions is outside of the scope of IDR. [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic. Sue Hares From: Jeff Tantsura mailto:jefftant.i...@gmail.com>> Sent: Saturday, July 9, 2022 3:40 PM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr mailto:l...@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan Hares mailto:sha...@ndzh.com>>; grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>> Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to accommodate a good discussion during IETF114 (we got only 1 slot), however would be happy to provide a platform for an interim. The topic is important and personally (being a very large BGP-LS user) I’d like to see it progressing. Cheers, Jeff On Jul 8, 2022, at 14:44, Robert Raszuk mailto:rob...@raszuk.net>> wrote: Hi Acee, Yes, by all means input from the operator's community is needed. It can be collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We have already seen input from some operators and their opinion on a
Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol
Hi Gyan, From: GROW on behalf of Gyan Mishra Date: Monday, July 11, 2022 at 1:41 AM To: Yingzhen Qu Cc: IDR List , "grow@ietf.org grow@ietf.org" , lsr Subject: Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol Hi Yingzhen So with OSPFV2 using RFC 6549 would support multiple instances or OSPFV3 already supports instances, how is the GT instance differentiated from any other routed instance? Did you read the draft? The main difference is that since OSPF-GT is generalized to be used for non-routing, there is installation of routes. OSPF-GT neighbors need not be directly attached (or come with complex OSPF Virtual-Link considerations and processing). Depending on the application, the extent to which the “condition of reachability” is enforced MUST be described in the document describing the application usage of OSPF-GT. For OSPFV2 it would use Opaque LSA Type 9,10,21 similar to RSVP-TE with an opaque option code for GTI. For OSPFV3 it would use an OSPFV3 function code for GTI. So the NBI BGP-LS peering to the PCE/SDN controller would be replaced with a OSPF GTI neighbor ? It could be but that is just one OSPF-GT use case and would need to be described in a separate draft. Would you still need a standard routed OSPF neighbor for reachability or I guess you could put a static route on the controller across the NBI for reachability. Yes. Is that correct? Are there any operators implementations of this using OSPF GTI in place of BGP-LS? You mean OSPF-GT… Since the draft to describe the details of using OSPF-GT in place of BGP-LS is yet to be written, it would be very strange indeed if it were already deployed. RFC 6823 provides the same GTI solution for ISIS. Yes and no, OSPF-GT is able to cover a much wider range of applications than RFC 683. This is due mostly to OSPF (and especially OSPFv3 with extended LSAs) being much more flexible than IS-IS. Are there any operators implementations of this using OSPF GTI in place of BGP-LS? No - answered above. Thanks, Acee Kind Regards Gyan On Sun, Jul 10, 2022 at 1:04 AM Yingzhen Qu mailto:yingzhen.i...@gmail.com>> wrote: Hi, Since we’re discussing possible solutions, I’d like to bring up the draft: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ We just submitted a new version. The name of the document is changed to “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a possible replacement of BGP-LS. Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. It uses the reachability info calculated by routing protocols, OSPF, ISIS or static routing etc.. It provides mechanisms to advertise non-routing information, and remote neighbor is supported. Reviews and comments are welcome. Thanks, Yingzhen On Jul 9, 2022, at 5:33 PM, Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: During the interim meeting we should keep it open to discuss all possible alternatives to BGP-LS. Thanks Gyan On Sat, Jul 9, 2022 at 4:45 PM Susan Hares mailto:sha...@ndzh.com>> wrote: Jeff: An interim sounds like a good plan. [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, · Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. · Refining any potential non-BGP solutions is outside of the scope of IDR. [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic. Sue Hares From: Jeff Tantsura mailto:jefftant.i...@gmail.com>> Sent: Saturday, July 9, 2022 3:40 PM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr mailto:l...@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan Hares mailto:sha...@ndzh.com>>; grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>> Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to accommodate a good discussion during IETF114 (we got only 1 slot), however would be happy to provide a platform for an interim. The topic is important and personally (being a very large BGP-LS user) I’d like to see it progressing. Cheers, Jeff On Jul 8, 2022, at 14:44, Robert Raszuk mailto:rob...@raszuk.net>> wrote: Hi Acee, Yes, by all means input from the operator's community is needed. It can be collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We have already seen input from some operators and their opinion on adding and distributing more and more link state protocol and topology data in BGP. More such input is very welcome. And to your point about RFC9086 - I see nothing wrong in keeping BGP information in BGP. So IGP Monitoring Protocol does not target to shut down BGP-LS. It only aims to remov
Re: [GROW] [Lsr] [Idr] IGP Monitoring Protocol
Hi Robert, From: Lsr on behalf of Robert Raszuk Date: Sunday, July 10, 2022 at 1:32 PM To: Yingzhen Qu Cc: Gyan Mishra , Susan Hares , IDR List , "grow@ietf.org grow@ietf.org" , lsr Subject: Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol Hi Yingzhen & OSPF-GT authors, UP front I must state that anything is better to export IGP information from routers to interested nodes than using BGP for it. But to propose using OSPF to transport ISIS seems pretty brave :) I must admit it ! With that I have few questions to the proposal - assuming the use case is to distribute links state info in a point to point fashion: 1. What is the advantage - if any - to use a new OSPF instance/process to send link state data over a unicast session to a controller ? It doesn’t have to be unicast, the remote neighbor construct just extends the possibilities in OSPF-GT. With an OSPF LSDB, the obvious advantage is all the protocol machinery is in place. Note that LSDB streaming is just but one use case and of OSPF-GT. The detals of this application would be specified in a separate draft. 1. The draft is pretty silent on the nature of such a p2p session. Please be explicit if this is TCP, QUIC or what ? It is OSPF, OSPF has its own protocol identifier (89). This draft just extends OSPF. I think you’ve misinterpreted the draft. Hence, your other questions aren’t really applicable or would be answered in a draft of the OSPF/IS-IS LSDB usage of OSPF-GT. Thanks, Acee C) The draft is pretty silent on types of authentication for such sessions. Security considerations are pretty weak in that respect as well. The security considerations for OSPF-GT will be similar to those for OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. However, since OSPF-GT is not used to update OSPF routing, the consequences of attacks will be dependent on advertised non-routing information. I would actually argue that security considerations of p2p remote neighbors are actually quite different from security considerations of flooding data. Along the same lines security is not about protecting your routing ... it is much more about protecting the entire network by exposing critical information externally to non authorized parties. D) Are there any PUB-SUB options possible for OSPF-GT ? E) Is there any filtering possible for OSPF-GT ? F) Are you envisioning use of OSPF-GT proxies and if so are you planning to add this to the document ? G) How are you going to address Receivers which do not support OSPF-GT parser ? H) As you know many operators are attracted to BGP-LS based on the fact that it offers the same view of information irrespective of what is the protocol producing the data. Is there some thought on such normalization in the OSPF-GT proposal ? I) What's the take of OSPF-GT draft authors on the YANG model in respect of using it for normalization of exported data ? To summarize IMHO we should not stretch routing protocols be it OSPF, ISIS or BGP to be messengers of link state data running and to artificially force them to run in a point-to-point model between router and controller. Kind regards, Robert On Sun, Jul 10, 2022 at 7:04 AM Yingzhen Qu mailto:yingzhen.i...@gmail.com>> wrote: Hi, Since we’re discussing possible solutions, I’d like to bring up the draft: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ We just submitted a new version. The name of the document is changed to “OSPF-GT (Generalized Transport)”, and a use case is added to use OSPF-GT as a possible replacement of BGP-LS. Note: OSPF-GT is not traditional OSPF, and it’s not used to calculate routes. It uses the reachability info calculated by routing protocols, OSPF, ISIS or static routing etc.. It provides mechanisms to advertise non-routing information, and remote neighbor is supported. Reviews and comments are welcome. Thanks, Yingzhen On Jul 9, 2022, at 5:33 PM, Gyan Mishra mailto:hayabusa...@gmail.com>> wrote: During the interim meeting we should keep it open to discuss all possible alternatives to BGP-LS. Thanks Gyan On Sat, Jul 9, 2022 at 4:45 PM Susan Hares mailto:sha...@ndzh.com>> wrote: Jeff: An interim sounds like a good plan. [IDR-chair hat] Alvaro has indicated that since all of the proposal received on the IDR list are new protocol proposals, · Capturing IDR’s input on BGP-LS problems and potential solutions is appropriate for IDR as BGP-LS home. · Refining any potential non-BGP solutions is outside of the scope of IDR. [IDR-chair hat off] [rtgwg WG member] I’d love to attend an interim on this topic. Sue Hares From: Jeff Tantsura mailto:jefftant.i...@gmail.com>> Sent: Saturday, July 9, 2022 3:40 PM To: Robert Raszuk mailto:rob...@raszuk.net>> Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; lsr mailto:l...@ietf.org>>; i...@ietf.org<mailto:i...@ietf.org>; Susan Hares mailto:sha...@
Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019
I also support publication. Thanks Acee From: Idr on behalf of Jeff Tantsura Date: Thursday, July 25, 2019 at 5:49 PM To: IDR List , Susan Hares Cc: "grow@ietf.org" Subject: Re: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019 Sue, I support publication of this draft. Cheers, Jeff On Jul 25, 2019, 5:26 PM -0400, Susan Hares , wrote: Greetings IDR: The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received only 2 comments. Since this is a draft that updates an operationally needed feature, I am extending the WG LC until 8/6/2019. If you believe this draft is ready for publication, please respond to this WG LC. Sue Hares From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, July 9, 2019 9:13 AM To: 'idr wg' Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from July 9, 2019 to July 23, 2019. . Please consider if you believe this revision of RFC8203 (Administrative Shutdown) Will benefit operational networks, is technically complete, and ready for publication. In your comments, please indicate whether you “support” or “do not support” its publication. This draft contains IPR notice that causes “IPR warnings”. The authors believe that this text is automatically generated by the IETF tools and the warning is not appropriate. As the shepherd, I am investigating this issue. If you have specific knowledge on this issue, you may send it to the list or to me directly. Cheerily, Susan Hares ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Routing Directorate Last Call Review for draft-ietf-grow-bmp-adj-rib-out-05.txt
Hi Tim, Changes look good for Routing Directorate review. Thanks, Acee From: "Tim Evens (tievens)" Date: Thursday, June 20, 2019 at 3:10 PM To: Acee Lindem , "draft-ietf-grow-bmp-adj-rib-...@ietf.org" , " (rtg-...@ietf.org)" Cc: Routing Directorate , "grow@ietf.org" Subject: Re: [GROW] Routing Directorate Last Call Review for draft-ietf-grow-bmp-adj-rib-out-05.txt Hi Acee, Thank you so much for the review and diff of changes. I've made all the requested changes. We already had the terminology change from the art view. We'll update the security section based on their review considering they may have some other suggestions. You can see the changes at https://github.com/TimEvens/draft-ietf-grow-bmp-adj-rib-out/pull/12/files . After the security review, we should be set to publish the final as revision 6. Thanks! Tim On 6/20/19, 10:11 AM, "GROW on behalf of Acee Lindem (acee)" mailto:grow-boun...@ietf.org> on behalf of a...@cisco.com<mailto:a...@cisco.com>> wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-bmp-adj-rib-out-05.txt Reviewer: Acee Lindem Review Date: June 20, 2018 IETF LC End Date: Not started yet. Intended Status: Standards Track Summary: The document extends BGP Monitoring Protocol to support per-peer Pre-Policy and Post-Policy Adj-RIB-Out monitoring similar to RFC 7854 support of Adj-RIB-In. The document is ready for publication. Comments: A well-written clear and concise document. Major Issues: N/A Minor Issues: Use updated boilerplate text for “Reserved Words”. You will be undoubtedly asked to explain why the Adj-RIB-Out support doesn’t add any additional security considerations. However, I’ll leave that the security reviewers so that they can fulfill their divine mandate of securing the Internet. Nits: See attached diff including Peer Up and Peer Down capitalization consistent with RFC 7854. Thanks, Acee ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Routing Directorate Last Call Review for draft-ietf-grow-bmp-adj-rib-out-05.txt (inline diff since attachment seems to have blocked)
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-bmp-adj-rib-out-05.txt Reviewer: Acee Lindem Review Date: June 20, 2018 IETF LC End Date: Not started yet. Intended Status: Standards Track Summary: The document extends BGP Monitoring Protocol to support per-peer Pre-Policy and Post-Policy Adj-RIB-Out monitoring similar to RFC 7854 support of Adj-RIB-In. The document is ready for publication. Comments: A well-written clear and concise document. Major Issues: N/A Minor Issues: Use updated boilerplate text for “Reserved Words”. You will be undoubtedly asked to explain why the Adj-RIB-Out support doesn’t add any additional security considerations. However, I’ll leave that the security reviewers so that they can fulfill their divine mandate of securing the Internet. Nits: See diff below including Peer Up and Peer Down capitalization consistent with RFC 7854. *** draft-ietf-grow-bmp-adj-rib-out-05.txt.orig2019-06-20 11:44:59.0 -0400 --- draft-ietf-grow-bmp-adj-rib-out-05.txt 2019-06-20 12:46:24.0 -0400 *** *** 85,91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 ! 9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 --- 85,91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 ! 9.3. Peer Up Information TLV . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 *** *** 96,102 1. Introduction BGP Monitoring Protocol (BMP) defines monitoring of the received !(e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before any policy has been applied. The Adj-RIB-In post-policy conveys to a BMP receiver all RIB data after policy filters and/or modifications --- 96,102 1. Introduction BGP Monitoring Protocol (BMP) defines monitoring of the received !(e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. The Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before any policy has been applied. The Adj-RIB-In post-policy conveys to a BMP receiver all RIB data after policy filters and/or modifications *** *** 120,136 use-case for enabling post-policy monitoring. In order for a BMP receiver to receive any BGP data, the BMP sender !(e.g. router) needs to have an established BGP peering session and actively be receiving updates for an Adj-RIB-In. Being able to only monitor the Adj-RIB-In puts a restriction on what !data is available to BMP receivers via BMP senders (e.g. routers). This is an issue when the receiving end of the BGP peer is not enabled for BMP or when it is not accessible for administrative reasons. For example, a service provider advertises prefixes to a customer, but the service provider cannot see what it advertises via BMP. Asking the customer to enable BMP and monitoring of the Adj- !RIB- In is not feasible. This document updates the BGP Monitoring Protocol (BMP) RFC 7854 [RFC7854] peer header by adding a new flag to distinguish Adj-RIB-In --- 120,136 use-case for enabling post-policy monitoring. In order for a BMP receiver to receive any BGP data, the BMP sender !(e.g., router) needs to have an established BGP peering session and actively be receiving updates for an Adj-RIB-In. Being able to only monitor the Adj-RIB-In puts a restriction on what !data is available to BMP receivers via BMP
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] WG Adoption Call: draft-scudder-grow-bmp-registries-change 2018.09.25-2018.10.09
I also support adoption. Acee On 9/25/18, 1:06 PM, "GROW on behalf of Tim Evens (tievens)" wrote: I support adoption of this document. On 9/25/18, 9:04 AM, "GROW on behalf of Job Snijders" wrote: Dear working group, Feedback from the working group seems to indicate a preference to follow regular procedures. So, we will do so! The author of draft-scudder-grow-bmp-registries-change [1] requested the chairs to consider issuing a call for working group adoption. Here is the abstract: "This document updates RFC 7854, BGP Monitoring Protocol (BMP) by making a change to the registration procedures for several registries. Specifically, any BMP registry with a range of 32768-65530 designated "Specification Required" has that range re- designated as "First Come First Served". [1]: https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt Please take a moment to read and evaluate the document and let the working group know whether you'd like to continue work on this document as working group or not. We'll close the call on 2018-10-09 Kind regards, Job ___ 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] Making BMP registries FCFS
I support adoption as well.
Thanks,
Acee
From: GROW on behalf of Job Snijders
Date: Friday, September 21, 2018 at 7:55 AM
To: Joel Jaeggli
Cc: "grow@ietf.org grow@ietf.org"
Subject: Re: [GROW] Making BMP registries FCFS
Read the doc, looks fine to me. I support adoption.
Let’s give folks a few more days to comment.
Kind regards,
Job
On Fri, 21 Sep 2018 at 09:06, Joel Jaeggli
mailto:joe...@bogus.com>> wrote:
Sent from my iPhone
On Sep 20, 2018, at 22:33, Christopher Morrow
mailto:christopher.mor...@gmail.com>> wrote:
Hello Grow Folks,
This seems like a sane plan ... I or Job can either unilaterally accept this,
or ask for adoption...
If there's enough immediate call to avoid the 2wk call for adoption I'd be
happy to just put it on the docket...
I think you can adopt it and move on. Support making registries low effort as
a general principle.
On Thu, Sep 20, 2018 at 1:12 AM John Scudder
mailto:j...@juniper.net>> wrote:
Hi All,
A while ago we talked about this. I finally wrote a draft for it,
https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt:
Abstract
This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
making a change to the registration procedures for several
registries. Specifically, any BMP registry with a range of
32768-65530 designated "Specification Required" has that range re-
designated as "First Come First Served".
It's super short, 3 pages including all the boilerplate. I'd like to propose it
as a WG item (and ideally, move it quickly to WGLC).
Thanks,
--John
P.S.: I'm one of the designated experts for those registries ("Specification
Required" requires designated experts who review all requests). So I have the
ulterior motive of trying to get rid of work. :-)
___
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
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Lsr] [OPSAWG] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
> On Jul 6, 2018, at 8:59 AM, Randy Bush wrote: > >> Why anyone would need BMP wrapper to monitor IGP ? > > probably similar reasons that folk seem to need bgp-ls to get the > is-is/ospf databases. is-is and ospf have decades of complexity > layered on un-simple bases. so we seek yet another layer of gunk > through which to see them more 'simply.' > > i would say an optimistic view might be that it will take a couple > more decades to gunk up bgp-ls and bmp so that we want yet another > layer. but it would appear that my optimism is not warranted. Those who forget the past are condemned to repeat it… Acee > > randy > > ___ > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Hi Robin,
I know for a fact that there have been applications written that do passive
monitoring using IS-IS and simply advertising yourself in overload mode.
Additionally, given that all routes in an area have the same LSDB, you don't
really have the same requirements as BGP.
With respect to scalability, I believe the advantage of the YANG models is more
in terms of consumption and having a single network programmability paradigm
rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF,
gNMI, and streaming telemetry are happening now irrespective of your proposal.
I agree that a custom protocol will result in fewer bits on the wire and
potentially less processing on the network device. However, I certainly don't
believe that this alone is a reason to do it.
Thanks,
Acee
On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin" wrote:
Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing
NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not
satisfactory for these models does not define config/oper of all features of
specific protocol and these models have much relation with each other and it is
difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the
existing YANG models such as the packets of control protocol which should be
monitored but not defined in YANG models.
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.
We would like to define the NMP based on the usecases. That is, a specific
set of parameters exported by NMP can satisfy the purpose of a specific
usecase. Thus the protocol can be deployed incrementally.
Best Regards,
Robin
-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) ; Lizhenbin
; grow@ietf.org; ops...@ietf.org
Cc: l...@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology
Research Dept. NW)
Subject: Re: [Lsr] [GROW] FW: New Version Notification for
draft-gu-network-mornitoring-protol-00.txt
Robin,
Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much
better and more scalable approach to what has been proposed in the draft, since
we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg.
How do you propose to corelate operational state to configuration?
gRPC provides high performance RPC framework to streaming the telemetry
data that is structured, easy to consume and extend.
I'm not going to go into technical discussion, however would appreciate
your response as to why NMP (please do not restate the points in the section 4
of the draft, they are quite incorrect)
Thanks!
Cheers,
Jeff
On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)"
wrote:
Hi Robin,
I'm not arguing to deprecate BMP. What I am arguing is that the fact
that BMP was created 15 years ago doesn't necessarily mean we should create an
analogous IMP for IS-IS given the current IETF OPS technologies and the fact
that faster link speeds and Moore's law facilitate deployment of these new OPS
technologies. Anyway, I looked at the agenda and I will definitely attend GROW
on Wednesday afternoon for the discussion.
Thanks,
Acee
On 7/3/18, 6:40 AM, "Lizhenbin" wrote:
Hi Acee,
Thank for your attention to the new draft. Please refer to my reply
inline.
Best Regards,
Robin
-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee
Lindem (acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW)
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for
draft-gu-network-mornitoring-protol-00.txt
Hi Yunan, Shunwan, and Zhenbin,
What are the advantages of inventing a new protocol over just using
YANG and NETCONF, RESTCONF, or gNMI?
[Robin] In the draft we simply mention the difference between NMP
and protocols you mentioned for the management plane. Though there is maybe
some overlap between the two types of protocols, the protocols you mentioned is
not enough for monitoring the control protocol. For example, would we like to
use YANG and NETCONF, RESTCONF, or gNMI to export the packets of control
protocols such as update message of BGP and/or ISIS PDU, etc. for the purpose
of monitoring?
O
Re: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Hi Robin,
On 7/5/18, 6:35 AM, "Lizhenbin" wrote:
Hi Acee,
It is not described clearly in the draft that reusing BMP is also a
possible option for monitoring IGP. We will refine the draft.
It doesn't matter where you put it, it is still an alternate paradigm for IS-IS
management.
Expect to have more discussion with you in IETF 102.
I'm sure we will. I really don't think this meets the "stick to the wall" test
for GROW.
Thanks,
Acee
Thanks,
Robin
-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; grow@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW)
; l...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for
draft-gu-network-mornitoring-protol-00.txt
Hi Robin,
I'm not arguing to deprecate BMP. What I am arguing is that the fact that
BMP was created 15 years ago doesn't necessarily mean we should create an
analogous IMP for IS-IS given the current IETF OPS technologies and the fact
that faster link speeds and Moore's law facilitate deployment of these new OPS
technologies. Anyway, I looked at the agenda and I will definitely attend GROW
on Wednesday afternoon for the discussion.
Thanks,
Acee
On 7/3/18, 6:40 AM, "Lizhenbin" wrote:
Hi Acee,
Thank for your attention to the new draft. Please refer to my reply
inline.
Best Regards,
Robin
-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee Lindem
(acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW)
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for
draft-gu-network-mornitoring-protol-00.txt
Hi Yunan, Shunwan, and Zhenbin,
What are the advantages of inventing a new protocol over just using
YANG and NETCONF, RESTCONF, or gNMI?
[Robin] In the draft we simply mention the difference between NMP and
protocols you mentioned for the management plane. Though there is maybe some
overlap between the two types of protocols, the protocols you mentioned is not
enough for monitoring the control protocol. For example, would we like to use
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols
such as update message of BGP and/or ISIS PDU, etc. for the purpose of
monitoring?
Operators and vendors are doing this anyway. A second alternative would
be to listen passively in IS-IS (or OSPF for that matter). Why would anyone
want this?
[Robin] In fact we tried the method you proposed. From our point of
view, the basic design principle should be that the monitoring entity should be
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the
monitoring. For example, for the method of listening passively, if there are
multiple hops between the listener and the network devices, it has to set up a
tunnel as the virtual link for direct connection. But the TCP-based monitoring
protocol need not care about it.
As far as where it belongs, we have a rather full agenda in LSR so I
don't think we want to devote time to it there at IETF 102.
[Robin] Though the WG the draft should belong to is not determined yet,
we think the work belongs to OPS area and send the notice to GROW WG and
OPSAWG. We also applied for the presentation in the two WGs. We should have
copied the notice to the related WGs of RTG area. So the LSR WG and RTGWG WG
mailing list are added. More comments and suggestions are welcome.
Thanks,
Acee
On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology
Research Dept. NW)"
wrote:
Dear GROW & OPSAWG WGs,
We have proposed a Network Monitoring Protocol (NMP) for the
control plane OAM. NMP for ISIS is illustrated in this draft to showcase the
benefit and operation of NMP. Yet, we haven't decided which WG it belongs to.
Comments and suggestions are very welcome!
Thank you!
Yunan Gu
Huawei Technologies Co. Ltd
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin
; Guyunan (Yunan Gu, IP Technology R
Re: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt
Hi Yunan, Shunwan, and Zhenbin, What are the advantages of inventing a new protocol over just using YANG and NETCONF, RESTCONF, or gNMI? Operators and vendors are doing this anyway. A second alternative would be to listen passively in IS-IS (or OSPF for that matter). Why would anyone want this? As far as where it belongs, we have a rather full agenda in LSR so I don't think we want to devote time to it there at IETF 102. Thanks, Acee On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" wrote: Dear GROW & OPSAWG WGs, We have proposed a Network Monitoring Protocol (NMP) for the control plane OAM. NMP for ISIS is illustrated in this draft to showcase the benefit and operation of NMP. Yet, we haven't decided which WG it belongs to. Comments and suggestions are very welcome! Thank you! Yunan Gu Huawei Technologies Co. Ltd -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: 2018年7月2日 20:07 To: Zhuangshunwan ; Lizhenbin ; Guyunan (Yunan Gu, IP Technology Research Dept. NW) Subject: New Version Notification for draft-gu-network-mornitoring-protol-00.txt A new version of I-D, draft-gu-network-mornitoring-protol-00.txt has been successfully submitted by Yunan Gu and posted to the IETF repository. Name: draft-gu-network-mornitoring-protol Revision: 00 Title: Network Monitoring Protocol (NMP) Document date: 2018-07-02 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt Status: https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/ Htmlized: https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol Abstract: To enable automated network OAM (Operations, administration and management), the availability of network protocol running status information is a fundamental step. In this document, a network monitoring protocol (NMP) is proposed to provision the information related to running status of IGP (Interior Gateway Protocol) and other control protocols. It can facilitate the network troubleshooting of control protocols in a network domain. Typical network issues are illustrated as the usecases of NMP for ISIS to showcase the necessity of NMP. Then the operations and the message formats of NMP for ISIS are defined. In this document ISIS is used as the illustration protocol, and the case of OSPF and other control protocols will be included in the future version. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ 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] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
Hi Chris, While the ATN in not THE Global Routing system, it is A Global Routing system that, at least in this proposal, is based on BGP. Hence, I think the GROW community is an excellent place for review. I would not liken it to RFC 4364 VPNs though since the overlay network is not tightly coupled to the underlay network and, in the current proposal, both the underlay and overlay are using the global VRF. The overlay routes simply resolve their nexthops over the underlay routes which will, in many cases, also be BGP routes. A better analogy than RFC 4364 are commercial SD-WAN implementations which avail tunnels over multiple networks including the Internet. Thanks, Acee From: "Templin, Fred L" <fred.l.temp...@boeing.com> Date: Tuesday, March 13, 2018 at 11:56 AM To: Christopher Morrow <christopher.mor...@gmail.com> Cc: "grow@ietf.org" <grow@ietf.org>, "Saccone, Gregory T" <gregory.t.sacc...@boeing.com>, Gaurav Dawra <gdawra.i...@gmail.com>, Acee Lindem <a...@cisco.com> Subject: RE: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network Hi Chris, >it's bad for bgp on the global scale, but in a VPN scenario you're talking >about ~10k routes? (number of planes concurrently in the air) and transitions >at a rate of 100/second? 500/second? (what rate is >expected at 10k planes? at >100k planes?) The model is that each airplane gets one or more IPv6 prefixes and acts as a mobile network. So, it has a mobile router on board, and uses the IPv6 prefixes to number its downstream-attached devices and networks – an airborne Internet of Things. The IPv6 prefixes stay the same wherever the plane roams to (more on that below). But, the plane’s underlying data link connections can be changing very dynamically, e.g., switch from SATCOM to cellular, update QoS due to signal fading, etc. >For quick/dirty numbers: >https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/ > >says there are 25k planes (round numbers) planes that I think qualify in your >pool. You are very correct to check on the current numbers of planes. For civil aviation, we currently see tens of thousands. But, the system should be flexible to support several orders of magnitude more than that with the multitudes of unmanned aircraft expected to be coming into the airspace in the near future. >why would you change ip addressing on the plane? having them keep their >addressing seems simpler and more conducive to stability, no? Right, the airplane’s on-board IPv6 prefixes used for downstream IoT addressing never change. It is the plane’s upstream data link addresses that can change dynamically, i.e., in the same way that a cellphone’s WiFi and/or 4G addresses can change. Again, the design is to keep mobility-related churn out of BGP in the core of the network and to keep the churn out in the edges of the network. Thanks - Fred From: Christopher Morrow [mailto:christopher.mor...@gmail.com] Sent: Tuesday, March 13, 2018 8:24 AM To: Templin, Fred L <fred.l.temp...@boeing.com> Cc: grow@ietf.org; Saccone, Gregory T <gregory.t.sacc...@boeing.com>; Gaurav Dawra <gdawra.i...@gmail.com>; Acee Lindem (acee) <a...@cisco.com> Subject: Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network On Tue, Mar 13, 2018 at 10:58 AM, Templin, Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote: Hi Chris, >yup, sure what I was proposing is that they DO participate. >I could see a world where the plane has a simple BGP instance, and some >orchestration does the equivalent of the mobile cell hand-off for hand-devices: > "about to leave AS1, start peering with AS2, ... drop peering with AS1" With the Connexion By Boeing experience, we have proof that frequent injections and withdrawals of prefixes due to mobility is bad for BGP. Plus, aircraft are it's bad for bgp on the global scale, but in a VPN scenario you're talking about ~10k routes? (number of planes concurrently in the air) and transitions at a rate of 100/second? 500/second? (what rate is expected at 10k planes? at 100k planes?) For quick/dirty numbers: https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/ says there are 25k planes (round numbers) planes that I think qualify in your pool. multi-link entities that often have multiple data links operational simultaneously, where each data link connects to a data link service provider network that may know nothing about BGP internally. And, we want to avoid tunneling over the low data rate wireless data links themselves. >I imagine each plane could even maintain more than one live BGP session with >the ground stations, even. It's good to hear that the expected churn is low, >tha
