Re: [GROW] IXP Route Server question
Hi Sriram, > 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". > IMO, the ASPA verification draft regards the relationship between RS and RS-client as "peer-to-peer", maybe my understanding is wrong, I will read the ASPA verification draft again. BR, Shunwan > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, > Kotikalapudi (Fed) > Sent: Thursday, March 10, 2022 11:31 AM > To: Nick Hilliard > Cc: grow@ietf.org; sidr...@ietf.org > Subject: Re: [GROW] IXP Route Server question > > 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? > > 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". > > Sriram > > -Original Message- > From: Nick Hilliard > Sent: Tuesday, March 8, 2022 4:28 PM > To: Sriram, Kotikalapudi (Fed) > Cc: grow@ietf.org; sidr...@ietf.org > Subject: Re: [GROW] IXP Route Server question > > Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: > > This question has relevance to the ASPA method for route leak > > detection. > > > > Is it possible that an ISP AS A peers with a customer AS C via a > > non-transparent IXP AS B? > > IOW, the AS path in routes propagated by the ISP A for customer C's > > prefixes looks like this: A B C. > > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in > > the middle between an ISP and its customer? > > 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. > > Some organisations provide transit over IXPs, but it's a minority thing. > It would be very peculiar if an organisation provided transit over an IXP via > an RS. > > Some organisations provide transit to ASNs over a direct physical connection > while maintain peering with their customer over an IXP port. > Usually this happens by accident, but occasionally it can happen by design. > > The answer to your question is that it would be technically possible, but it > would be so peculiar and stupid that it should be considered a mistake in the > situations where it was intentional. In all other situations, it would be a > leak. > Generally it would be safe to assume that this sort of configuration was in > error. > > Nick > ___ > 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
Camilo, > On Mar 7, 2022, at 5:59 PM, Camilo Cardona wrote: > On 7/3/22, 22:32, "Jeffrey Haas" wrote: >>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? Alvaro prodded IDR that it was at IETF last call. Since the BGP module is looking to make use of TCP-AO, it got some extra scrutiny. That, plus the fact that anyone who does any serious BGP or BMP troubleshooting usually ends up a lesser expert on TCP and wants good troubleshooting... :-) >>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. This one was a mistake on my part. You're covered! >>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. Understood. The "type enumeration" works, but so would making it an identity. The IETF YANG maintenance rules effectively push you to maintain enumerations by publishing an update to the module. However, if you define a base identity for this bit of config and create the "all" case, you're covered for current purposes. At a later date if you want to add other identities via augmentation rather than a full module re-issue, you can do so. For example, "all-customers", "all-ebgp" or other such stuff. > >>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. Yeah, there's choices here. The critical one is I think that you want your config state for your stations to be somewhat centralized while your "here's what I monitor" to be network-instance aware. Exactly what that looks like probably will take some discussion. I don't have a strong opinion yet! > >>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. The model is basically "clear session foo". If you look at the bgp-model, you'll see that under neighbor context, there's a clear action. Its presence under the neighbor means that you have semantic clarity about what you're taking action on. Contrast this vs. a global action that requires parameters. It's a style point. I would tend to recommend the per neighbor yang actions because the validation considerations are handled by its presence there. I.e. "is this a configured entity." -- Jeff > ___ 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
From: GROW on behalf of Camilo Cardona
Sent: 07 March 2022 10:06
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.
prefix bmp seems more than adequate to me - ietf in the name but not in the
prefix
import must have a reference and the reference must be Normative References for
the I-D
YANG must be plain text - I am always suspicious of [] as in
"[RFC-to-be]: BMP YANG Module";
an enum with only one value could do with an explanation
looking at how it is used, I do not understand it
your ip type include the zone - is this intended?
leaf destination-port {
type inet:ip-address;
looks like an oxymoron
statistics interval has no units
statistics commonly have a discontinuity leaf
unit32 may be small for counters
actions commonly have a NACM default deny-all
' BGP data is sensible for security considerations. '
looks a bit odd
IANA considerations are incomplete - you must register the prefix
YANG needs references, BGP. BMP!. etc
This e-mail comes from two addresses neither of which are the address in the
I-D; I wonder if they will bounce:-(
Have a 'nice' day,
Tom Petch
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] IXP Route Server question
Sounds good. Thank you so much for the discussions and info. Sriram -Original Message- From: Ben Maddison Sent: Friday, March 11, 2022 2:23 AM To: Nick Hilliard Cc: Sriram, Kotikalapudi (Fed) ; grow@ietf.org; sidr...@ietf.org Subject: 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
