Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
Hi Jeff, Thank you. We are now in sync with you. The design focuses only on transparent RS (i.e., the RS ASN does not appear in the AS path in BGP). We are assuming that non-transparent RS is rare/abnormal. It turns out that the solution that works for transparent RS also works for non-transparent RS with no extra effort. Just an observation, not saying that the non-transparent RS case has any importance. I have a talk in SIDROPS on Friday where the WG discussions will be summarized and a solution presented: "ASPA Verification Procedures: Enhancements and RS Considerations". Sriram From: Jeffrey Haas Sent: Monday, March 21, 2022 12:43 PM To: Zhuangshunwan Cc: Jakob Heitz (jheitz) ; Gyan Mishra ; Sriram, Kotikalapudi (Fed) ; Ben Maddison ; sidr...@ietf.org; grow@ietf.org Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question) Two comments here: If the BGP Speaker is inserting itself into the AS_PATH, it's not really a Route Server in the traditional sense. A normal BGP Speaker can happily pass along routes via eBGP peering with the nexthop unchanged with all devices that it shares a common nexthop subnet with. My recommendation is to not to try to consider these devices a Route Server. For ASPA purposes, just add the BGP connections to the inputs. If providers are unhappy with having a IXP router's AS in the ASPA data and thus lose the desired ASPA filtering properties, the IXP should install a real route server. -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
Ok. You are saying that's illegal. A RS rule is that clients cannot be customers or providers of other clients. That's fine, but it has nothing to do with ASPA. Write it into another draft. Regards, Jakob. -Original Message- From: Sidrops On Behalf Of Sriram, Kotikalapudi (Fed) Sent: Wednesday, March 23, 2022 12:45 PM To: Jakob Heitz (jheitz) ; Zhuangshunwan ; Jeffrey Haas Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question) >If AS1 attests that AS3 is its provider, then there is no leak. >That would be weird, but is it illegal? No that wouldn't work. If you propose that then for an Update that is propagating in the opposite direction, you would also want the reverse: 'AS3 attests that AS1 is its provider'. That would make AS1 and AS3 siblings. Then the leak in question will not be detected (the ASPA verification outcome will be Valid)! We considered and dismissed it before: https://mailarchive.ietf.org/arch/msg/grow/bfchBrjqMqvMRoP7WrPR-OKOXT8/ Sriram ___ Sidrops mailing list sidr...@ietf.org https://www.ietf.org/mailman/listinfo/sidrops ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
>If AS1 attests that AS3 is its provider, then there is no leak. >That would be weird, but is it illegal? No that wouldn't work. If you propose that then for an Update that is propagating in the opposite direction, you would also want the reverse: 'AS3 attests that AS1 is its provider'. That would make AS1 and AS3 siblings. Then the leak in question will not be detected (the ASPA verification outcome will be Valid)! We considered and dismissed it before: https://mailarchive.ietf.org/arch/msg/grow/bfchBrjqMqvMRoP7WrPR-OKOXT8/ Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
If AS1 attests that AS3 is its provider, then there is no leak. That would be weird, but is it illegal? Regards, Jakob. -Original Message- From: Sriram, Kotikalapudi (Fed) Sent: Wednesday, March 23, 2022 12:01 PM To: Zhuangshunwan ; Jakob Heitz (jheitz) ; Jeffrey Haas Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question) Hi Shunwan, >> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral >> peer) ---> AS4 (validating AS) >2. AS3 is not included in the set of C2P AS numbers set registered by AS1; #2 (above) from your list is what we have focused on as a solution. Please see my previous post responding to Jakob where the set of ASPAs is enumerated. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
That would work.
AS1 and AS3 could attest AS0 as provider. That would work too.
AS2 does not need an attestation, but any attestation that AS2 wants to make
will make no difference.
Regards,
Jakob.
-Original Message-
From: Sriram, Kotikalapudi (Fed)
Sent: Wednesday, March 23, 2022 11:57 AM
To: Jakob Heitz (jheitz) ; Zhuangshunwan
Cc: Jeffrey Haas ; sidr...@ietf.org; grow@ietf.org; Nick
Hilliard
Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server
question)
Hi Jakob,
>> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral
>> peer) ---> AS4 (validating AS)
...
>The AS-path at AS4 is (4 3 1).
>If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3
>declare AS3 not to be its provider. AS3 >has both sides non-customer. That's a
>leak.
Right. It seems we agree. A set of APSAs needs to be in place. They can be
enumerated as follows:
{AS1, AS2} – AS1 attests AS2 (RS) as a provider
{AS3, AS2} – AS3 attests AS2 (RS) as a provider
{AS2, AS 0} – RS (AS2) creates an ASPA with AS 0 (this is already specified in
the draft)
The first two ASPAs *implicitly* declare that AS3 is not a provider of AS1 and
vice versa. That implies that they are p2p. AS4 does not need to look at its
own ASPA. It knows it is p2p with AS3.
Specifying that each RS-client creates ASPA showing the RS as a provider is a
solution component that we (Nick, me, Shunwan, ...) seem to be converging to.
Just to be sure the focus is on transparent RS.
Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
Hi Shunwan, >> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral >> peer) ---> AS4 (validating AS) >2. AS3 is not included in the set of C2P AS numbers set registered by AS1; #2 (above) from your list is what we have focused on as a solution. Please see my previous post responding to Jakob where the set of ASPAs is enumerated. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)
Hi Jakob,
>> AS1 (RS Client) -> AS2 (RS) -> AS3 (RS Client) ---p2p (lateral
>> peer) ---> AS4 (validating AS)
...
>The AS-path at AS4 is (4 3 1).
>If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3
>declare AS3 not to be its provider. AS3 >has both sides non-customer. That's a
>leak.
Right. It seems we agree. A set of APSAs needs to be in place. They can be
enumerated as follows:
{AS1, AS2} – AS1 attests AS2 (RS) as a provider
{AS3, AS2} – AS3 attests AS2 (RS) as a provider
{AS2, AS 0} – RS (AS2) creates an ASPA with AS 0 (this is already specified in
the draft)
The first two ASPAs *implicitly* declare that AS3 is not a provider of AS1 and
vice versa. That implies that they are p2p. AS4 does not need to look at its
own ASPA. It knows it is p2p with AS3.
Specifying that each RS-client creates ASPA showing the RS as a provider is a
solution component that we (Nick, me, Shunwan, ...) seem to be converging to.
Just to be sure the focus is on transparent RS.
Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] NACM for action: Re: New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang
From: GROW on behalf of tom petch
Sent: 21 March 2022 17:15
From: Benoit Claise
Sent: 19 March 2022 17:27
Hi Tom,
Great feedback.
I would like to come back your NACM comment below.
We added "nacm:default-deny-all" to our action (in our temp version).
I have not been following the detailed history of
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-13. And I
don't know whether this point was already discussed but I was surprised
to observe that this draft does not have "nacm:default-deny-all" for its
action. Bringing this issue here since I guess we deal with the same set
of people in GROW/IDR.
Benoit
I think that this is one for IDR rather than GROW, that is it is just a
question of getting the authors to include it, not a question of good
operational practice to include or not include it. I don't think I have
commented on bgp-model lately - there is much in it that I would rather were
done differently such as how many separate modules and submodules there should
be. For the latter, I start at zero and do not count upwards.
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
___
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
