Re: [GROW] [Lsr] IGP Monitoring Protocol
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 remove 100% of non BGP sourced information from it. Controllers which today listen to BGP-LS need a number of information sources and that spread will only keep increasing as more inputs are becoming necessary for its computations. Regards, Robert. On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) wrote: > Hi Robert, > > > > *From: *Robert Raszuk > *Date: *Friday, July 8, 2022 at 4:36 PM > *To: *Acee Lindem > *Cc: *lsr , IDR List , Susan Hares < > sha...@ndzh.com> > *Subject: *Re: [Lsr] IGP Monitoring Protocol > > > > Hi Acee, > > > > Thank you. I was not planning to present it in the upcoming IETF. > > > > > Let’s see how many stakeholders actually want to this protocol - then we > can talk about a WG home. > > > > An alternative approach could be to see how many stakeholders do not want > to further (for no good reason) to trash BGP. That to me would be in this > specific case a much better gauge. > > > > In that case, it seems to me that this discussion should be relegated to > IDR. Note that there is already non-IGP information transported in BGP-LS, > e.g., Egress Peer Engineering (https://datatracker.ietf.org/doc/rfc9086/). > I implemented this on our data center routers (NXOS) years and it is solely > BGP specific. > > > > Thanks, > > Acee > > > > Kind regards, > > Robert > > > > > > On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) wrote: > > Speaking as WG chair: > > > > *From: *Lsr on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Friday, July 8, 2022 at 3:21 PM > *To: *lsr > *Cc: *IDR List , Susan Hares > *Subject: *[Lsr] IGP Monitoring Protocol > > > > Dear LSR WG, > > > > Based on ongoing discussion in respect to the future of BGP-LS I > committed myself to put together an alternate proposal. > > > > The main goal is not to just publish a -00 version of the draft using > different encapsulation. The goal is to make a useful tool which can help > to export link state information from network elements as well as assist in > network observability. > > > > The IGP Monitoring Protocol (IMP) draft has been posted and should be > available at: > > > > https://datatracker.ietf.org/doc/draft-raszuk-lsr-imp/ > > > > One of the key points I wanted to accomplish was full backwards > compatibility with TLVs defined for BGP-LS. In parallel other formats > (optional) are also supported. > > > > The PUB-SUB nature or FILTERING capabilities are in the spec however as > noted in the deployment section there is no expectation that this should be > supported directly on routers. Concept of Producer's Proxies has been > introduced to support this added functionality as well as provide fan-out > (analogy to BGP route reflectors). > > > > I encourage everyone interested to take a look and provide comments. At > this point this document is nothing more than my individual submission. > Offline I have had few conversations with both operators and vendors > expressing some level of interest in this work. How we proceed further (if > at all :) depends on WG feedback. > > > > Kind regards, > > Robert. > > > > PS, I do believe this work belongs in LSR WG pretty squerly. > > > > Let’s see how many stakeholders actually want to this protocol - then we > can talk about a WG home. By stakeholders, I mean operators and vendors > who are committed to implementing and deploying it - not simply those who > you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is > full (with multiple agenda items not making the cut). > > > > Thanks, > > Acee > > > > > > > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposing a well-known BGP community for Anycast
+1 mh 8 juillet 2022 21:19 "Randy Bush" a écrit: >> Meaning, please add a note to the security considerations saying don't >> trust communities (this one included) from untrusted sources. See rfc >> 7999 S6. > > because A trusts B, A does not know B's inbound security model. so B > could have accepted the community from C with conditions less strict > than A would have applied. > > don't trust communities. treat this community as a clue, not a fact. > > randy > > ___ > 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] Proposing a well-known BGP community for Anycast
> Meaning, please add a note to the security considerations saying don't > trust communities (this one included) from untrusted sources. See rfc > 7999 S6. because A trusts B, A does not know B's inbound security model. so B could have accepted the community from C with conditions less strict than A would have applied. don't trust communities. treat this community as a clue, not a fact. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposing a well-known BGP community for Anycast
Fri, Jul 08, 2022 at 05:13:37PM +0200, Robert Raszuk: > > I do not understand Robert's issues with this community. > > Let me say that I like it from operational perspective. > > However from routing perspective I have doubts on how this community is > going to be originated and how it is going to be used. > I do not preceive these concerns to be unique to this community. rfc7999 (BLACKHOLE) is of little difference, for eg. The draft and comments on the WG ML have noted a few uses, besides it being informational. > Example 1: Hyperscaler has global POP footprint and is offering anycast > services for its VPCs. So lot's of prefixes are going to be marked as such. > Is the expectations that ISPs will/shall use it ? maybe; that is their decision, not ours nor the originating AS's. They might ignore BLACKHOLE, GRACEFUL SHUT, or no_export too. They might choose to ignore (or not) it only from Hyperscaler. They might have a specific agreement with Hyperscalar to observe the community. > Example 2: Enterprise is injecting same prefix from different locations. It > could be anycast or not. Or maybe as mentioned one host route within such > /24 is true anycast. Is ISP suppose to alter their local pref according to > such marking ? Even if there is no really ANYCAST service behind at all ? They might; both are their decision. They might not observe the community for prefixes shorther than /24 (/64). They might just not ignore (use) the MEDs received. They might not observe it for prefixes with an AS_PATH greater than 1 AS. They might advertise the more specific with no-export. > Example 3: How do we detect misuse and accidental or purpose marking by > malicious guys in the middle ? you know that is not possible today. You can choose to craft your policy to limit from whom it is accepted or have other constraints, just as with any other community. Seems like we've been over this for other communities. Besides Jeff's requested changes (your Ex 2 & 3), perhaps you just want prefix lengths addressed? ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposing a well-known BGP community for Anycast
> I do not understand Robert's issues with this community. Let me say that I like it from operational perspective. However from routing perspective I have doubts on how this community is going to be originated and how it is going to be used. Example 1: Hyperscaler has global POP footprint and is offering anycast services for its VPCs. So lot's of prefixes are going to be marked as such. Is the expectations that ISPs will/shall use it ? Example 2: Enterprise is injecting same prefix from different locations. It could be anycast or not. Or maybe as mentioned one host route within such /24 is true anycast. Is ISP suppose to alter their local pref according to such marking ? Even if there is no really ANYCAST service behind at all ? Example 3: How do we detect misuse and accidental or purpose marking by malicious guys in the middle ? Thx, R. On Fri, Jul 8, 2022 at 5:01 PM heasley wrote: > Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas: > > > > > > > On Jul 7, 2022, at 11:50 AM, Robert Raszuk wrote: > > > But most if not all of those do not affect intradomain traffic > engineering rules. > > > > > > So I think Jeff's point is how much trust is needed to overwrite your > own > > > policy in selecting exit points and overwriting your EPE policy, TE > policy, Local Pref etc ... > > > > Exactly. > > > > > And I think misuse of those can happen even over direct peerings if > the overall objective is > > > to avoid double checking the community against prefix lists. > > > > Exactly. > > Meaning, please add a note to the security considerations saying don't > trust > communities (this one included) from untrusted sources. See rfc 7999 S6. > > What a receiver's policy does with the community (or several other > well-knowns or another AS'es self-defined) is their decision. The document > clearly dictates that a bgp implementation SHOULD NOT (imo MUST NOT) apply > [automatic] special handling of the community. I do not understand > Robert's > issues with this community. > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Proposing a well-known BGP community for Anycast
Thu, Jul 07, 2022 at 12:21:27PM -0400, Jeffrey Haas: > > > > On Jul 7, 2022, at 11:50 AM, Robert Raszuk wrote: > > But most if not all of those do not affect intradomain traffic engineering > > rules. > > > > So I think Jeff's point is how much trust is needed to overwrite your own > > policy in selecting exit points and overwriting your EPE policy, TE policy, > > Local Pref etc ... > > Exactly. > > > And I think misuse of those can happen even over direct peerings if the > > overall objective is > > to avoid double checking the community against prefix lists. > > Exactly. Meaning, please add a note to the security considerations saying don't trust communities (this one included) from untrusted sources. See rfc 7999 S6. What a receiver's policy does with the community (or several other well-knowns or another AS'es self-defined) is their decision. The document clearly dictates that a bgp implementation SHOULD NOT (imo MUST NOT) apply [automatic] special handling of the community. I do not understand Robert's issues with this community. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] draft-lucente-grow-bmp-tlv-ebit-02 - review/comment
Hi Paolo, I reviewed https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit-02 and have some minor nits and simplifications in wording to be considered. Best wishes Thomas Change from Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standard product. To Vendors need the ability to define proprietary Information Elements for various reasons such as delivering a pre-standard product. Change from This This would align with Also for code point assignment to be eligible, an IETF document needs to be adopted at a Working Group and in a stable condition. To This aligns also with code point assignments where a document needs to be at stable condition in IETF Working Group first. Change from shipped to network operators to be tested there as well. To shipped to network operators for testing. Change from This would align with This document re-defines the format of IANA- registered TLVs in a backward compatible manner with respect to previous documents and existing IANA allocations; To This document re-defines the format of IANA- registered TLVs in a backward compatible manner with respect to previous documents and existing IANA allocations; Change from The encoding specified in this document applies to all existing BMP Message Types and their namespaces defined in Future BMP Message Types MUST make use of the TLV encoding defined in this document. To The TLV encoding specified in this document applies to all existing and future BMP Message Types and their namespaces. . smime.p7s Description: S/MIME Cryptographic Signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
