[GROW] Upcoming meeting note(s)

2022-03-22 Thread Christopher Morrow
Howdy GROW Folks!
For those in Vienna, happy sleeping time, see you in the 'morning'? :)
For those not in Vienna (or not sleeping), but whom have presentations to
present at the presentation time... (roughly 15 hrs from 'now') Please send
your presentation materials along to:
  grow-cha...@ietf.org

so that we'll be able to properly load up the Meetecho dolla-bill-gun with
slides.

thanks!
-chris

(I believe this would mean slides are required from:
  Paolo - BMP E-bit TLV
  Sasha - NRTM v4
  Camillo - bmp-yang
)
___
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)

2022-03-22 Thread Jakob Heitz (jheitz)
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.

Regards,
Jakob.


> On Mar 21, 2022, at 10:31 PM, Zhuangshunwan  wrote:
> 
> Hi Sriram and all,
> 
> IMO, for the scenario described in the following email (AS4 and AS3 are P2P 
> connection; AS3 and AS1 are connected via a RS and being treated as a P2P 
> connection ), it can be determined that AS-PATH: AS4 AS3 AS1 is a route leak 
> if one of the following conditions is met:
> 1. If AS1 is a Tier 1 ISP;
> 2. AS3 is not included in the set of C2P AS numbers set registered by AS1;
> 3. Determine that AS1 and AS3 are P2P relationships (one of the ways is to 
> obtain them is: a) Create a P2P relationships database; b) lookup in the P2P 
> relationships database);
> 4. AS4 detects that AS3 and AS1 are interconnected through IXP (for example, 
> Traceroute), which is equivalent to a specific way of obtaining the P2P 
> relationship between AS1 and AS3 in branch 3.
> 5. Make sure that AS3 is not the Customer of AS1 (it may be P2P, that is, 
> branch 3;(or) it may be P2C).
> 
> Thanks,
> Shunwan
> 
>> -Original Message-
>> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
>> Sent: Tuesday, March 22, 2022 5:09 AM
>> To: Jakob Heitz (jheitz) ; Jeffrey Haas 
>> Cc: sidr...@ietf.org; grow@ietf.org; Zhuangshunwan
>> ; Nick Hilliard 
>> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
>> Server question)
>> 
>> Hi Jakob,
>> 
>>> To be clear, I'm talking about BGP devices that do not insert their ASN into
>> the AS path.
>> 
>> Even if you assume that all route servers are transparent, what would you
>> like to propose to solve the following problem?
>> 
>> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral 
>> peer) --->
>> AS4 (validating AS)
>> 
>> The arrows indicate the direction of the flow of the Update. Let us say that
>> the RS is transparent.
>> 
>> AS4 is the receiving/validating AS. The AS path is {AS3 AS1}. Do you agree
>> this is a route leak as seen at AS4? The question is how will AS4 detect it?
>> What ASPAs should be in place?
>> 
>> Suppose the RS-clients (i.e., AS1 and AS3) have ASPAs each attesting the RS's
>> AS (i.e., AS2) as a provider. That is all that it takes for AS4 to be able 
>> to detect
>> the leak.
>> 
>> Is there another way? Do we assume that AS1 and AS3 have some other ISP
>> provider(s) for which they have ASPA attestation?
>> 
>> In this solution, AS4 does not have to know anything about the presence of
>> an RS, etc.
>> 
>> This solution works fine even if the RS happens to be non-transparent.
>> 
>> In an earlier related thread,
>> 
>> https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1=I2a05YrOEY
>> rRRdEg1ZHOOln6BCw
>> 
>> Nick Hillard and Rob Mosher left the door slightly open for a possibility 
>> that
>> there might be a rare RS out there that is non-transparent.
>> 
>> Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow