Re: [GROW] IXP Route Server question
Hi Sriram, On 03/10, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: [...] > > The ASPA verification draft treats the relationship of RS to > > RS-client as similar to that of Provider to Customer. Seems > > reasonable? The AS of an RS client includes the RS's AS in its ASPA > > as a "Provider". > > yes, this is reasonable. > Essential, I would think: how could a far end relying party know that an AS in the middle of a received AS_PATH is a non-transparent IXP RS in order to apply any other treatment? A special mark in the ASPA itself perhaps, but yuk ;-) Cheers, Ben signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: Nick and all, Thank you. What you all shared/discussed is very useful info. Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Good to know that. Well, that means there can be an occasional RS that is non-transparent. When there is a non-transparent RS, could there be big ISPs (Tier-1, Tier-2) present there as RS-clients? I would seriously doubt it. There are some "Tier 1" and "Tier 2" providers who peer using route servers at IXPs, but it's a bit unusual (and entertaining to hear them strenuously denying that this ever happens). Non-transparent RS's were used until a couple of years ago but I'm not aware of any left at this point. Even when non-transparent RS's were more widespread, I would have expected the intersection of these two groups to be null, and that if there were an intersection, the Tier1/Tier2 providers would not be upset if those paths were dropped / marked as invalid. The ASPA verification draft treats the relationship of RS to RS-client as similar to that of Provider to Customer. Seems reasonable? The AS of an RS client includes the RS's AS in its ASPA as a "Provider". yes, this is reasonable. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang
Hello Jeffrey, Thanks for your comments, some answers inline: On 7/3/22, 22:32, "Jeffrey Haas" wrote: Camilo, A few quick notes from an eyeball review of the draft: You probably care about what's going on for the tcp yang module. I've prodded that item in a separate response. JCC: Ack! We will look at that. Are you planning to include that also in the BGP one? For your connections, just put in the full 4-tuple; i.e. local-port. JCC: We are missing that local port, ack. For your address family list, perhaps consider the BGP yang identity afi-safi-type. We're hoping that as the bgp-yang work wraps up we'll have the expected types in a common registry that can be extensibly maintained. I see you're using this for the "name" for address-family filters. JCC: We do reference the BGP one for AFIs, don’t we? Let us know where we are missing that reference as the idea is indeed to leverage the BGP model as much as possible. For your "bmp_peer_types", consider having it be an identity. They're easy to maintain in the yang language, while enumerations tend to require a fully model update. JCC: Also here, please check that "peer" is already an union between the remote-address of the BGP model, the peer-type of the same model, and the bmp one. We added the last one because we couldn’t find a way of signaling "ALL", and we wanted to be explicit, but we can check other options. How were you planning on monitoring other network-instances? E.g. the ribs for vrf-X? JCC: My naïve answer would be to place it under the network-instance that it corresponds, such as the BGP model does, but I am sure there are tons of caveats to explore. Consider moving your action to be a per-station action. See for example the actions in the bgp yang model. JCC: The action currently points to a single station. Maybe I am misunderstanding your observation here though. -- Jeff > On Mar 7, 2022, at 5:06 AM, Camilo Cardona wrote: > > Hi Grow, > > We just submitted a new draft proposing a yang module for configuring and managing BMP on a device. > > It would be nice to get some comments, observations, etc. > > Grow Chairs, will it be possible to get a 5 minute slot in the next session to give an overview of this module? > > Thanks, > Camilo Cardona > > > >> >> On 7/3/22, 10:51, "internet-dra...@ietf.org" wrote: >> >> >> A new version of I-D, draft-cptb-grow-bmp-yang-01.txt >> has been successfully submitted by Camilo Cardona and posted to the >> IETF repository. >> >> Name: draft-cptb-grow-bmp-yang >> Revision: 01 >> Title: BMP YANG Module >> Document date: 2022-03-07 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt >> Status: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/ >> Htmlized: https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang >> Diff: https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01 >> >> Abstract: >> This document proposes a YANG module for BMP (BGP Monitoring >> Protocol) configuration and monitoring. A complementary RPC triggers >> a refresh of the session of a BMP station. >> >> >> >> >> 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] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang
Thanks Tim! We will consider your points for next version, together with the recommendations from Jeffrey. Camilo From: "Tim Evens (tievens)" Date: Monday, 7 March 2022 at 19:05 To: Camilo Cardona , Camilo Cardona Cc: "grow-cha...@ietf.org" , "grow@ietf.org" Subject: Re: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang // Connection, missing tcp tuning params // like keep-alives, segment sizes, etc. TCP keep-alives SHOULD be enabled by default if possible. The ability to tune them is also important. Window sizes have been a challenge over higher latency BMP sessions. We should be able to adjust/configure scaling/etc. In addition to TCP tuning, I do like the ability to configure an initiation delay as well as backoff timers. If the BMP session is flapping, then at some point it should backoff and wait a little longer. Thanks, Tim On 3/7/22, 2:08 AM, "GROW" wrote: Hi Grow, We just submitted a new draft proposing a yang module for configuring and managing BMP on a device. It would be nice to get some comments, observations, etc. Grow Chairs, will it be possible to get a 5 minute slot in the next session to give an overview of this module? Thanks, Camilo Cardona > > On 7/3/22, 10:51, "internet-dra...@ietf.org" > wrote: > > >A new version of I-D, draft-cptb-grow-bmp-yang-01.txt >has been successfully submitted by Camilo Cardona and posted to the >IETF repository. > >Name: draft-cptb-grow-bmp-yang >Revision: 01 >Title: BMP YANG Module >Document date: 2022-03-07 >Group: Individual Submission >Pages: 14 >URL: > https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt >Status: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/ >Htmlized: > https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang >Diff: > https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01 > >Abstract: > This document proposes a YANG module for BMP (BGP Monitoring > Protocol) configuration and monitoring. A complementary RPC triggers > a refresh of the session of a BMP station. > > > > >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] IETF 113 GROW meeting agenda (draft)
Job and Chris: [WG chair hat on] Did you receive my request on behalf of IDR WG on VPN Prefix limits on the grow email list? Will you be asking this question at IETF 113? [WG chair hat off] [WG participant hat on] I'm personally pleased to see an inbound prefix limit Proposal at IDR. Thank you, Sue -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders Sent: Thursday, March 10, 2022 4:41 AM To: grow@ietf.org Subject: [GROW] IETF 113 GROW meeting agenda (draft) Hi all, Here is the current draft GROW @ IETF 113 agenda: https://datatracker.ietf.org/meeting/113/materials/agenda-113-grow-00.txt Please let the chairs know if you'd also like to contribute agenda items. Kind regards, Job & Chris ___ 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] IETF 113 GROW meeting agenda (draft)
Hi all, Here is the current draft GROW @ IETF 113 agenda: https://datatracker.ietf.org/meeting/113/materials/agenda-113-grow-00.txt Please let the chairs know if you'd also like to contribute agenda items. Kind regards, Job & Chris ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
