Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jakob Heitz (jheitz)]

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)

[Jakob Heitz (jheitz)]

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)

[Jakob Heitz (jheitz)]

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)

[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

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jakob Heitz (jheitz)]

To be clear, I'm talking about BGP devices that do not insert their ASN into 
the AS path.
I understand that route leaks can happen after a route server.
My point is that such a route leak is of no concern to ASPA.

Regards,
Jakob.

From: Jeffrey Haas 
Sent: Monday, March 21, 2022 9:43 AM
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



On Mar 21, 2022, at 11:48 AM, Zhuangshunwan 
mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
 wrote:

+1
I think Jacob's suggestion is reasonable.
I once worked on a route leak analysis project. There is a first step in that 
project, which is to clear the IXP’s AS number added to the AS-PATH by the 
non-transparent RS.
The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” (where 
ASx and ASy are RS-clients connected in BGP via the RS) will be corrected to 
“AS1 - ASx - ASy - ASn”.
With this process, we can exclude the influence of non-transparent RS on the 
accuracy of route-leak analysis.

Kind Regards,
Shunwan

From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
Sent: Monday, March 21, 2022 11:13 PM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>; Sriram, 
Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org<mailto:sidr...@ietf.org>; grow@ietf.org<mailto:grow@ietf.org>; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org<mailto:sidr...@ietf.org>; grow@ietf.org<mailto:grow@ietf.org>; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detect

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jakob Heitz (jheitz)]

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops  On Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan ; Nick Hilliard 
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detection of the apex in the AS path at the RS (not 
visible in the path) and inversion (non-upward flow) after the RS is obscured 
with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is 
evaluated as "attested not Provider". That means that the detection of 
apex/inversion at the RS (though not visible in the path) is effectively not 
missed out by the procedure with #2.

Thank you.

Sriram

-Original Message-
From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard mailto:n...@foobar.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
grow@ietf.org; sidr...@ietf.org
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server 
question)

Nick (and all),

I was also rereading/reviewing Section 5.3 and had similar thoughts about the 
two options you outlined. As you noted, "the approach in Section 5.3 gives a 
workable outcome".  However...

>... the RS should be treated as a provider by the rs client; the rs client 
>should include the RS ASN in its SPAS; the rs client should evaluate ASPA as 
>if the RS ASN were included in the path; the rs should evaluate clients as 
>customers

Yes, I agree that "the rs client should include the RS ASN in its SPAS." 
Alexander and I have talked about this, and he mentioned that this would be 
added to the draft.

Yes, I also feel that it is a better option that the RS client adds the ASN of 
the transparent RS to the AS path (for ASPA validation purposes only) and 
applies the downstream ASPA algorithm. Algorithmically this seems more 
appropriate. This is also better from a diagnostics point of view (if the need 
ever arises) because in this approach the relevant ASPA is used for validating 
the hop from the AS just before the RS to the RS.

That said, I think there is a bigger issue about transparent RS in the middle 
of the AS path. Maybe this is what Ben's question was hinting at. I think you 
are also raising this issue when you say:

>RSs do not partake in traffic forwarding, so they are not part of the data 
>path between two ASNs; they're only part of the signaling path between the two 
>ASNs.  This is a useful hack from a practical point of view, but it causes 
>algorithmic breakage in places which assume congruency between the data plane 
>and the signaling plane.  One of these places is AS path verification.

> ASPA verification should proceed as if the two rs-client ASNs were 
> directly connected and each should treat the other as a provider

Gyan>I understand the issue with the 

Re: [GROW] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

Rayhaan wanted to know if the peer accepted his route.
A looking glass is a different thing in many ways.

Several years ago Ignas pointed out that you can use this
information to know whether to install a backup on your
side for the route. Backup routes in the forwarding hardware
are expensive, so it would be good to know if your peer
is using your route before installing a backup for it.

BGP has a peer-to-peer only signaling mechanism: ORF.
Can we invent an ORF for it?

Rayhaan, please let me know if I'm on or off track
for your use case.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of heasley
Sent: Monday, April 26, 2021 4:23 PM
To: Christopher Morrow 
Cc: grow@ietf.org grow@ietf.org 
Subject: Re: [GROW] BGP Looking Glass Capability

Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow:
> (as normal netizen)
> 
> On Mon, Apr 26, 2021 at 3:33 PM Randy Bush  wrote:
> 
> > > Place LG info in peeringdb.com & peeringdb's api.
> >
> > +1
> >
> 
> huh,I had thought this was already actually included in peeringdb?
> 
>Looking Glass URL http://route-server.ip.att.net
> 

afict, its just a string, which does not provide a standard way to
represent location/geo.  i presume from earlier comments, that something
more structured is desired.

___
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] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

If we do that, we should secure it with the router certificate
https://tools.ietf.org/html/rfc8209
Then the URL should be secured with DNSSec, or why don't we just put the
IP address in place of the hostname portion of the URL?

Regards,
Jakob.

From: GROW  On Behalf Of Gyan Mishra
Sent: Sunday, April 25, 2021 6:37 PM
To: Rayhaan Jaufeerally (IETF) 
Cc: idr@ietf. org ; grow@ietf.org
Subject: Re: [GROW] BGP Looking Glass Capability


+1 on the new AFI idea.  I would support developing the new draft.

Out of al the ideas proposed I think the new AFI seems to be the best method of 
achieving the BGP looking glass capability and propagation of routes.

Thanks

Gyan

On Sun, Apr 25, 2021 at 7:25 PM Rayhaan Jaufeerally (IETF) 
mailto:i...@rayhaan.ch>> wrote:
Thanks for the history Robert, I should have read the authors list more closely 
on that draft :)

From that description it seems that it was more circumstances at the time 
rather than push back on the implementation itself which is good news for 
trying to revive it,

I'll try and rework the draft to use the operational message and see which 
common parts are useful here, then reply to the list / IDR with the updated 
draft,

Cheers,
Rayhaan

On Mon, Apr 26, 2021 at 12:48 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Rayhaan,

I guess a good starting point would be to reach out to IDR folks / authors of 
the operational message draft and get their input as to why it didn't progress 
further since that would be useful to guide any revival attempts.

Good idea. As I am co-author of this draft taking the liberty to do it right 
here :)

A bit of history  - in min 2010 I wrote 
https://tools.ietf.org/html/draft-raszuk-bgp-diagnostic-message-00.

Then we spoke about it, trimmed a bit and formed what we considered most 
important operationally into 
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The draft was having good support during the IDR WG adoption and hence it 
became WG doc.

Since then most of the authors left the vendor world and our influence to 
implement it in significant commercial BGP code bases was no longer sufficient. 
Yet vendors told we will implement it if customers ask for it. So we are 9+ 
years and still I am not sure if anyone cares much about switching phone and 
email channels between NOCs into more programmatic way.

Yet we do see from time to time a pop request to some form to tell peer ascii 
strings like sms by BGP, pass some well known address, etc ...

I think this is the fundamental challenge in how we operate peering relations. 
I have seen a lot of good automation happening in the IX world, but when trying 
to establish BGP sessions today it seems still emails, xls, word documents 
style ...

While it does not need to be all TLVs as listed in the 
https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 draft but I 
think operational message is indeed needed.

Cheers,
R.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BGP Looking Glass Capability

[Jakob Heitz (jheitz)]

This is a great thing to do, but I would not use a BGP capability to do it.
The capability is signaled only in the BGP OPEN message, at the start of the 
session.
Changes cannot be signaled without bouncing the session.
The BGP capability is only exchanged with neighbors.
Perhaps we could do it with a new address family or
standardize the form of the URL, say invent a new top level domain: 
.lookingglass
and then the URL could be the ASN followed by the TLD, for example:
23456.lookingglass for AS 23456.

Regards,
Jakob.

From: GROW  On Behalf Of Rayhaan Jaufeerally (IETF)
Sent: Saturday, April 24, 2021 6:38 AM
To: grow@ietf.org
Subject: [GROW] BGP Looking Glass Capability

Dear GROW chairs and participants,

I would like to propose draft-jaufeerally-bgp-lg-cap-00 
(https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a mechanism 
for in-band dissemination of looking glass endpoints in BGP, using a new OPEN 
message capability.

The rationale behind this is to facilitate automation around eBGP peering, for 
example  to make it possible to automatically detect if the peer has accepted 
some routes which are expected to be accepted.

I'm aware that the underlying RFC8522 is an informational RFC and leaves some 
details unspecified for the response format (i.e. a schema for the 
queries/responses) but I believe that can be further refined in other works 
independent to this proposal.

I would like to hear what the WG thinks, if this is a reasonable proposal which 
fits into the broader charter of GROW?

Thanks,
Rayhaan
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

[Jakob Heitz (jheitz)]

When the collector sees a route with AS-PATH length 5 with a community on it, 
that does not imply that the community traveled through 5 AS hops. The 
community could have been added at any of the ASes in the path. Where does the 
data show that any communities transited any AS boundaries?

Regards,
Jakob.


> On Apr 1, 2021, at 2:06 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> There may be a knob that AS operators have for permitting transitivity, but 
> we need to look at measurements to understand whether or not operators 
> actually allow transitivity to EC and LC.
> 
> NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared on 
> the GROW list in May 2020:
> https://mailarchive.ietf.org/arch/msg/grow/JPD1-hhSvVXIZbUlNQ_1hmzD6IA/
> 
> A portion is copied below. The AS path length (# unique ASes) distributions 
> for BGP updates with Communities (Regular, Large, and Extended) are shown 
> here. It is evident that both LC and EC propagate multiple AS hops. Mass 
> stripping of LC or EC at the first hop is not evident.  The peak happens at 
> AS path length 4 or 5 and that is good. That is the behavior that is helpful 
> for route leak solution. The solution can still function even if some ASes 
> strip. We can do some more detailed studies if needed. 
> 
> *
> RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To 
> 2020-04-30 00:55)
> *
> # Updates = 1075583 (Total)
> # (Regular) COMMUNITY = 859239 (79.89%)
> AS path length distribution =1: 170 (0.02%)2: 44803 (5.21%)3: 
> 141072 (16.42%)4: 276271 (32.15%)5: 238325 (27.74%)6: 114158 
> (13.29%)7: 31365 (3.65%)8: 9018 (1.05%)9: 2690 (0.31%)10: 811 
> (0.09%)11: 358 (0.04%)12: 169 (0.02%)13: 22 (0%)14: 7 (0%)
> 
> # LARGE_COMMUNITY = 152818 (14.21%)
> AS path length distribution =2: 5655 (3.7%)3: 17205 (11.26%)4: 
> 54372 (35.58%)5: 45492 (29.77%)6: 22065 (14.44%)7: 6422 (4.2%)
> 8: 1068 (0.7%)9: 397 (0.26%)10: 71 (0.05%)11: 35 (0.02%)12: 
> 26 (0.02%)13: 6 (0%)14: 4 (0%)
> 
> # EXTENDED COMMUNITIES = 44606 (4.15%)
> AS path length distribution =2: 2269 (5.09%)3: 7435 (16.67%)4: 
> 17657 (39.58%)5: 11600 (26.01%)6: 3967 (8.89%)7: 1221 (2.74%)
> 8: 371 (0.83%)9: 57 (0.13%)10: 19 (0.04%)11: 8 (0.02%)12: 1 
> (0%)13: 1 (0%)
> *
> 
> Sriram
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

[Jakob Heitz (jheitz)]

No community is transitive.
Not even the transitive extended communities.

In all BGP code I've worked in, not just Cisco, a configuration
is required to send communities of any kind to an ebgp session.
By default, no communities are sent to ebgp sessions.
That's a good thing, because network operators don't want
junk in the routes transiting across their networks, causing
churn and memory consumption.

Path attributes are transitive.
However, several years ago, approximately coinciding with the
development of RFC7660, there was massive thrust to get attributes
blocked too. Now we implement path attribute filtering
and many network operators use it.

Regards,
Jakob.

-Original Message-
From: Sriram, Kotikalapudi (Fed)  
Sent: Wednesday, March 31, 2021 10:17 AM
To: Jeffrey Haas 
Cc: Susan Hares ; i...@ietf.org; grow@ietf.org; 
draft-heitz-idr-w...@ietf.org
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks 
Solution

Jeff,

Thank you for the response. My comments inline.

>You can thus just get a FCFS extended community from a
>transitive space TODAY and
>it'd probably do most of what you want.  One of the beneficial properties
>that extended communities have is the transitivity is at least understood
>and well deployed.

I was hoping for a confirmation of that nature. So, that is good to hear.

>That said, there's still no guarantee that some operator may choose to just 
>delete them all at an ASBR.

Yep. It is not a perfect world. But are you suggesting that no community-based 
approach (EC or LC or ?) is worth pursuing? 

>...the headache you're going through is trying to avoid the work of creating a 
>new attribute. 

There is already a separate draft in IDR that has passed WGLC, and it uses a 
new transitive BGP Path Attribute 'Only to Customer (OTC)':
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
We view that as a longer-term solution, while the EC/LC-based approach is meant 
to be deployed quickly.  

>A discussion I'd suggest is that we've had a need for a "BGP routing
>security" attribute where we can put these various proposals:
>- It's not a victim of existing community practices.
>- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
>- It can be extensible so new components can be added incrementally.

In the above, are you suggesting BGP Path Attribute or a new type of Community 
that comes with transitivity guarantees?

Sriram

From: Jeffrey Haas 
Sent: Wednesday, March 31, 2021 12:13 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Susan Hares; i...@ietf.org; grow@ietf.org; draft-heitz-idr-w...@ietf.org
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks 
Solution

Sriram,

(Clearly I'm not Sue...)

Extending the observation I've just made to Gyan, the headache you're going
through is trying to avoid the work of creating a new attribute.  A result
of this is a lot of work trying to proscriptively change how people operate
their networks for more general features.

Extended communities have functionally behaved as more of a protocol control
mechanism in their general history.  They already have behaviors that permit
them to be selectively transitive or non-transitive across ASes.
Operationally, they MAY be stripped by policy, but sanitization practices
for them are significantly less codified than RFC 1997 communities.  You can
thus just get a FCFS extended community from a transitive space TODAY and
it'd probably do most of what you want.  One of the beneficial properties
that extended communities have is the transitivity is at least understood
and well deployed.

That said, there's still no guarantee that some operator may choose to just
delete them all at an ASBR.

A discussion I'd suggest is that we've had a need for a "BGP routing
security" attribute where we can put these various proposals:
- It's not a victim of existing community practices.
- Policy might still interact with it, but the baseline maintenance
  expectations can be set for it.
- It can be extensible so new components can be added incrementally.

While I understand a motivation for putting this in communities is "faster
deployment", take the other example from the life of large communities: when
there's sufficient interest, the feature will show up pretty fast.

-- Jeff (the best time to plant a tree is ten years ago. the second best
time is now...)


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

[Jakob Heitz (jheitz)]

You can make a distinction between "cost out" and "de-prefer".
"Cost out" is for removing all traffic from the path so that it can be removed.
"de-prefer" is to make it a backup in case the preferred path fails.
"cost out" should be done with the graceful shutdown community if it is 
supported.

Another note: weight is not signaled in the BGP protocol. It stays in the 
router.

Regards,
Jakob.

From: GROW  On Behalf Of Gyan Mishra
Sent: Monday, March 29, 2021 1:22 AM
To: Michael McBride 
Cc: grow@ietf.org; i-d-annou...@ietf.org
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


Hi Mike & Authors

I would like to start my thanking the authors in formulating this much needed 
GROW Best Practice draft to help tackle the elephant in the room on the use of 
excessive pretending by operators on the internet and documenting ramifications 
from excessive pretending.

I would recommend changing the draft from Informational to BCP as this is truly 
a worthy cause to standardize.  I can help provide some more operations 
feedback to help make this draft a BCP for operators use of prepending and 
routing  policies.

The draft is very well written as you have a fine team of authors.

Few additions to section 2 from a Tier 1 such as Verizon from a NOC and 
operations standpoint.

There are a lot of permutations you can get into and I think most are covered 
here already.

From an operations POV the general goal of the NOC is monitoring traffic and 
traffic pattern shifts as well as taking links out of service for upgrades and 
maintenance.  In those instances links are prepended costed out so they don’t 
take traffic in an active / backup setup.

In general the goal is to have all inter provider links to other carrier to 
load balance traffic as evenly as possible some simple and so more complex 
policies involving prepending.

May want to mention prepend is typically outbound and conditional local 
preference is used inbound within for path preference within the operators core.
There maybe some cases where prepend is done inbound to cost out a link but 
generally not done as a lower prepend coming from a peering AS could alter the 
preferred path within the operators AS and have unwanted consequences.

Also the negative ripple effects of outbound prepend done multiple times in the 
same outbound direction by multiple providers chained together cascading effect 
of a growing as path effects that can lead to issues such as route leaking.

Counter prepends in opposing directions by non directly connected peers ripple 
effect of the path vector with excessive prepending.

May also want to talk about BGP atomic aggregates and as-set  and care to be 
taken with aggregation and LPM matching leaked route preference over aggregate 
can lead to unwanted traffic pattern changes.

Use cases:

Conditional preference and prepending making all links conditionally preferred 
and active or backup based on set of conditions.

Conditionally prefer one ISP over another ISP same or different ASBR.

Conditionally prefer one ASBR over another same site or between multiple sites. 
This typically for conditional or non conditional would be done via local 
preference within the operators AS not AS prepend inbound.

Conditionally use one path exclusively and other path solely as backup.

In the diagram I would make it more clear showing A and B as part of AS 1 and D 
and C part of AS 2 and E and F part of AS 3.

So typically within an operator core to most providers use conditional local 
preference inbound  to cost out a link and use local preference since it’s 
above as-path in BGP path selection so that even if E sent a 2x prepend 
outbound that ripple into the providers AS won’t impact the routing so B will 
still route through C and not reroute through shorter path through D.  Local 
preference is non transitive so the operators AS is not affected, however a 
downstream provider connected to AS 1 would see the 2x sent by E and create 
that ripple effect possibly alter the pathing.  That is also another adverse 
affect of using prepending inbound as that prepending as well can have a 
cascading adverse effect.

The cascading prepending adverse effect can happen in both directions.  The 
issue with prepending as a method of costing out a link has similar adverse 
cascading affects with IGP costing of transit links having the same type of 
rippling cascading type adverse affect.

Under alternatives to AS Path prepending for inbound we could mention what I 
stated to use conditional or non conditional local preference as an alternative 
to prepending. Another option to prepending is use of a conditional weight. 
Weight is at the top of the path selection so have to be carful and make 
conditional to account for failover and all scenarios.

Under best practices mention conditional prepending if you have to prepend and 
not ever use non conditional prepending.

Kind Regards

Gyan


On Thu, Mar 18, 2021 at 11:36 PM 

Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

[Jakob Heitz (jheitz)]

Thanks Thomas.
I agree to remove the netflow reference.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com  
Sent: Sunday, March 7, 2021 10:20 PM
To: michael.mcbr...@futurewei.com; dmad...@kentik.com; jefftant.i...@gmail.com; 
rob...@raszuk.net; Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt

Dear authors,

Speaking as a network operator, I think your draft has merit and I agree BGP 
as-path prepending is misused on the Internet and a best common practice draft 
is welcomed.

I like to comment on section 3.4
https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-03#section-3.4

You are referring to the impact of BGP as-path length onto IPFIX.

To my current knowledge, there are only 4 well known IPFIX entities registered 
at IANA related to BGP as-path

https://www.iana.org/assignments/ipfix/ipfix.xhtml

IE16 bgpSourceAsNumber
IE17 bgpDestinationAsNumber
IE128 bgpNextAdjacentAsNumber
IE129 bgpPrevAdjacentAsNumber

None of them contain the entire BGP as-path array. Only the first or last BGP 
ASN of the path array for source and destination IPv4/6 address of the flow.

The reason to my knowledge is that for UDP transport, which is one of the 
options to export IPFIX and the most supported, does not support segmentation. 
Thus limiting IPFIX of the amount data records and values within a record which 
can be exposed per message even to a lower value than RFC 7011 defines with 
65535 bytes as maximum message size.

https://tools.ietf.org/html/rfc7011#section-10
https://tools.ietf.org/html/rfc7011#section-10.3.3

The BGP as-path array could be potentially be exposed with code points from the 
private enterprise number space. If that would be the case than same 
operational considerations would apply than in RFC 8549 section 7 described 
since BGP communities are also array's.

https://tools.ietf.org/html/rfc8549#section-7

Therefore I either recommend to remove the IPFIX/Netflow relevant part from the 
draft or clearly state the scenario where with private enterprise number BGP 
as-path array is exposed and refer to example implementations as they are 
nonstandard.

Best wishes
Thomas

-Original Message-
From: GROW  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, February 9, 2021 1:30 AM
To: i-d-annou...@ietf.org
Cc: grow@ietf.org
Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : AS Path Prepending
Authors : Mike McBride
  Doug Madory
  Jeff Tantsura
  Robert Raszuk
  Hongwei Li
  Jakob Heitz
Filename: draft-ietf-grow-as-path-prepending-03.txt
Pages   : 10
Date: 2021-02-08

Abstract:
   AS Path Prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  AS Path
   Prepending is used to deprioritize a route or alternate path.  By
   prepending the local ASN multiple times, ASs can make advertised AS
   paths appear artificially longer.  Excessive AS Path Prepending has
   caused routing issues in the internet.  This document provides
   guidance,to the internet community, with how best to utilize AS Path
   Prepending in order to avoid negatively affecting the internet.


The IETF datatracker status page for this draft is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978557059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7TnSGyVp7p7innNedC5FT5ssVVOzrxYVyW6Tw5B0N90%3Dreserved=0

There are also htmlized versions available at:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2mJb%2B6acbTyMKNdkVy1UdsJQdxnELMqyh52GQkPFgm8%3Dreserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-03data=04%7C01%7CThomas.Graf%40swisscom.com%7C5a0d770557454ff09f2208d8cc91d377%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637484273978567016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qIZAlo8WOj85dXLPqQu%2BMq6cILpMdAd%2Ffye2bWYNAac%3Dreserved=0

A diff

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

homas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow=04%7C01%7CThomas.Graf%40swisscom.com%7C6f42aefe6ab345b492fd08d8e4315ba1%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637510247926518582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=zgp7tdq1q59KlkJO5t2cpsH4CU%2By22MJIpwLuLQgxLc%3D=0>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

For the router, it's not about the time, its about the buffer space.
Configure the buffer space allowed to buffer incoming updates during
the down time. If the buffer runs out, new sesssion.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com  
Sent: Wednesday, March 10, 2021 6:56 AM
To: Jakob Heitz (jheitz) ; job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Jakob and Job,

Ack on all. I would define 60 seconds to be default and configurable.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 1:12 PM
To: Job Snijders 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

I would say 60 seconds or until the client runs out of configured buffer space 
to save messages that need to be sent to the session once the new session comes 
up.

Regards,
Jakob.

-Original Message-
From: Job Snijders 
Sent: Wednesday, March 10, 2021 1:04 AM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Wed, Mar 10, 2021 at 03:08:34AM +, Jakob Heitz (jheitz) wrote:
> >From the BGP speaker (client) implementation point of view,
>
> I would do it like this:
> The client keeps a ring buffer of data it sent to the server.
> The bottom of the buffer is at a certain sequence number.
> As messages are created, that bottom moves up.
> If the server were to restart, it would send its last received 
> sequence number and session ID. If the buffer still contains the 
> sequence number, then you're in luck, else big bang restart.
> The content of the buffer could be optimized by retrieving some of the 
> information from the bgp table (adj-rib's are conceptual only) instead 
> of literally storing it. How and if any optimization is done is 
> implementation specific and not part of an RFC.

In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial numbers are 
not required, only a 'session id' (which might remain the same over the 
lifetime of the BMP client's lifetime).

A full 'big bang' restart is achieved by the server disconnecting and allowing 
reconnection twice, within the 60 second window. When combined with 
TCP_FAST_OPEN resuming a session requires 2 packets (one each way) and 
restarting a session requires 4 packets.

This way BMP remains a 'read only' protocol, but I admit this is an 
unconventional approach.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Jakob Heitz (jheitz)]

Then your proposal is not an alternative to Sriram's, but a complement. No?

Regards,
Jakob.

-Original Message-
From: Job Snijders  
Sent: Wednesday, March 10, 2021 1:12 AM
To: Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: Re: [GROW] An alternative approach to 
draft-ietf-grow-route-leak-detection-mitigation

Dear Jakob,

On Wed, Mar 10, 2021 at 02:10:24AM +, Jakob Heitz (jheitz) wrote:
> Job, your suggestion kicks a different goal than
> draft-ietf-grow-route-leak-detection-mitigation does.

Yes, I'm aware I am suggesting a different approach to solve the problem
of route leaks.

> draft-ietf-grow-route-leak-detection-mitigation tries to determine
> if your neighbor leaked the route to you.
> To do that, you need to know how your neighbor received the route
> before he sent it to you.
> That's what the ASN in the LC is for.

Right, so my proposal is that the neighbor does not (knowingly) leak 
routes to you, negating the need to additionally tag routes with more
information than "this route is intended for not-for-peers (Down Only)"

I believe the Section 6 'Only To Customer' Attribute described in
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15 can be
implemented using the existing well-known NOPEER Attribute.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

I would say 60 seconds or until the client runs out of configured buffer space 
to save messages that need to be sent to the session once the new session comes 
up.

Regards,
Jakob.

-Original Message-
From: Job Snijders  
Sent: Wednesday, March 10, 2021 1:04 AM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Wed, Mar 10, 2021 at 03:08:34AM +, Jakob Heitz (jheitz) wrote:
> >From the BGP speaker (client) implementation point of view,
>
> I would do it like this:
> The client keeps a ring buffer of data it sent to the server.
> The bottom of the buffer is at a certain sequence number.
> As messages are created, that bottom moves up.
> If the server were to restart, it would send its last
> received sequence number and session ID. If the buffer still
> contains the sequence number, then you're in luck, else
> big bang restart.
> The content of the buffer could be optimized by retrieving some
> of the information from the bgp table (adj-rib's are conceptual only)
> instead of literally storing it. How and if any optimization is
> done is implementation specific and not part of an RFC.

In the 'Sent: Tuesday, March 9, 2021 4:50 PM' email sequence/serial
numbers are not required, only a 'session id' (which might remain the
same over the lifetime of the BMP client's lifetime).

A full 'big bang' restart is achieved by the server disconnecting and
allowing reconnection twice, within the 60 second window. When combined
with TCP_FAST_OPEN resuming a session requires 2 packets (one each way)
and restarting a session requires 4 packets.

This way BMP remains a 'read only' protocol, but I admit this is
an unconventional approach.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

QUIC is not stateless.
BMP over QUIC is not BMP over UDP.
BMP requires reliable transfer.
The state to provide reliability must exist somewhere.
If not in TCP (or QUIC), then in the app.

Regards,
Jakob.

From: GROW  On Behalf Of thomas.g...@swisscom.com
Sent: Tuesday, March 9, 2021 10:21 PM
To: rob...@raszuk.net; j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow=04%7C01%7CThomas.Graf%40swisscom.com%7C65bea241318b45bcbbab08d8e343a4f7%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637509226968976552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=y%2BZBBT4FK6yI5wPMj4o24Lg4eWwkO3g9dtiHRkbpw%2F4%3D=0>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

TCP sequence numbers are for TCP only.
It would be nice if TCP were to acknowledge received data only after 
all application layers have fully processed it.
However, TCP sequence numbers are only for TCP.
The application cannot acknowledge full processing of received data
back to TCP through the socket layer.
If the application layer wants to signal full processing of received
data back to the sender, then it needs its own sequence numbers.

It's these sequence numbers that I want to be in 64 bits,
not the session ID.

Storing the withdraw messages is an optimization that would work
for monitor mode. In general, the sender has to store all data
that has not been acknowledged at the application layer
(not the TCP layer) if it is going to be retransmitted in any
subsequent TCP session. In monitor mode, the sender can retrieve
the non-withdraw messages from the information stored in the BGP table.

Regards,
Jakob.

-Original Message-
From: thomas.g...@swisscom.com  
Sent: Tuesday, March 9, 2021 10:19 PM
To: Jakob Heitz (jheitz) ; job=40fastly@dmarc.ietf.org
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Job and Jakob,

Many thanks for the good inputs which I consolidated in this reply.

In regards to TFO applicability to the BMP application.

During my initial research I was encouraged my section 6 of TFO RFC 7413 

https://tools.ietf.org/html/rfc7413#section-6

It is well understood that the original intend of the RFC is two fold:

- allow to re-establish a TCP session
- performance gain for short-lived connections

While the first is the motivation why TFO was chosen in this draft, the second 
is a welcomed by product where BMP could benefit from.

Regarding the TCP_FAST_OPEN cookie handling and the separation between 
application (BMP) and transport (TCP). The goal of the draft is that both 
sides, the BMP client and the BMP server can decide wherever the new transport 
session belongs to the previous BMP session or not. This is done on the BMP 
client side by either clearing the TCP_FAST_OPEN cookie for transport or not. 
The BMP client does not need to know the previous value. It needs only to 
distinguish between establish a new session or re-establish an existing 
session. Different to the BMP client, the BMP server does the same but instead 
of clearing the TCP_FAST_OPEN cookie for transport it sets a new, different to 
the previous, cookie.  

I like to take your input Job about the TFO applicability to the BMP 
application and do my due diligence by going to the TCPM working group and get 
their opinion. I will also do my own research on applications using TFO and for 
which purpose. I will present then that to the GROW list and the next GROW 
session. Does that make sense?

As you already pointed out the goal can be achieved not only on the TCP 
transport layer but also on the BMP application layer. There with the drawback 
that BMP is strictly speaking no longer unidirectional.

Here my proposal would be to extend the BMP Initiation Message with another TLV 
containing the BMP session identifier. I agree that the size should large 
enough to be unique and I take the input being 64 bit as a proposal. The client 
set's the BMP session identifier and the server stores it. When a BMP session 
is established, a new BMP session identifier is set be the client and stored at 
the BMP server. When the BMP client establishes the BMP session, the server 
decides wherever to reply with the previously stored value (signaling its 
state) or 0 (a new session). BMP client acts wherever on exporting its queue or 
start a new RIB dump depending if BMP session identifier is different to the 
previous or not.

Regarding the input from Jakob that not all the BMP message types should be 
queued, only BGP withdrawals. This is an interesting proposal I like to follow 
up and further like to understand it. If I understand correctly, only 
withdrawals would be queued during the re-establish time window and updates 
would be locally generated for the re-establish time window once the BMP 
session is re-established. Correct? 

Regarding the proposal of sequence numbers. It would imply that the BMP Common 
Header needs to be extended. Here I like to hear your thoughts why a session 
identifier is not enough and what benefit a sequence number would bring on the 
application layer when we already have sequence numbers on the TCP transport 
session. As you might recall, one of the objectives of the BMP hackathon was to 
detect loss of BMP messages.

Also many thanks to Jeff about the feedback in regards to BGP NSR. I agree that 
solving the goal on a TCP transport layer would prevent implications onto 
BGP/BMP application in such condition when BGP process is being restarted.

Best wishes
Thomas

-Original Message-
From: Jakob Heitz (jheitz)  
Sent: Wednesday, March 10, 2021 4:09 AM
To: Job Snijders 
Cc: draft-tppy-bmp

Re: [GROW] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

>From the BGP speaker (client) implementation point of view,
I would do it like this:
The client keeps a ring buffer of data it sent to the server.
The bottom of the buffer is at a certain sequence number.
As messages are created, that bottom moves up.
If the server were to restart, it would send its last
received sequence number and session ID. If the buffer still
contains the sequence number, then you're in luck, else
big bang restart.
The content of the buffer could be optimized by retrieving some
of the information from the bgp table (adj-rib's are conceptual only)
instead of literally storing it. How and if any optimization is
done is implementation specific and not part of an RFC.

Regards,
Jakob.

-Original Message-
From: Job Snijders  
Sent: Tuesday, March 9, 2021 4:50 PM
To: Jakob Heitz (jheitz) 
Cc: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

On Tue, Mar 09, 2021 at 08:44:18PM +0000, Jakob Heitz (jheitz) wrote:
> BMP is a one-way protocol. The BMP server sends nothing.

In the proposal at hand, the BMP server would send a client-specific
TCP_FAST_OPEN cookie (on top of TCP ACKs), and possibly eventually a TCP
RST, which is slightly more than 'nothing'... :-)

As TCP_FAST_OPEN already is a published RFC, existing BMP clients &
servers are free and able to opportunistically use TCP Fast Open. For
the sake of conversation I'll consider TCP_FAST_OPEN out-of-scope for
BMP and GROW in the rest this email.

BMP - one way protocol on reliable transport: are successive RSTs a signal?
===

In a one-way protocol where the recipient essentially is limited to 'TCP
ACK' and 'TCP RST' as response options, would it perhaps make sense to
outline a BMP protocol where both BMP client and BMP server assume more
delibrate intent from the timing of TCP reconnection events?

If the BMP client includes a 'session_id' message as its first message
towards the BMP server, then when the client loses its connection to the
BMP server, it can continue buffering messages destined for that
specific BMP server linked to the previously sent 'session_id'.

Then, if the BMP client manages to reconnect to the BMP server within 60
seconds, the client will flush all buffered messages associated with the
session_id also communicated in prior BMP sessions.

However if the BMP server closes the TCP session within that 60 seconds
buffer window, a subsequent successful reconnection would result
in the BGP client sending a new session_id followed by all 'Peer Up'
messages, because the previous BMP session (and buffer) were
terminated.

The BMP server can immediately disconnect when it receives a BMP
session_id it does not recognize (by issuing a TCP RST). When a BMP
client receives the 'second' TCP RST within 60 seconds, it can choose to
reconnect following an linear backoff model and for the duration of wait
periods exceeding 1 minute not bother buffering for 'unreachable' BMP
servers.

The heuristic is that the BMP client considers the BMP session
'resumed', iff a BMP server doesn't disconnect within 60 seconds.

The BMP server can use the session_id as input to its decision process
whether to disconnect within 60 seconds or not.

Blink once the BMP session survives... blink twice, game over!

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

[Jakob Heitz (jheitz)]

Job, your suggestion kicks a different goal than
draft-ietf-grow-route-leak-detection-mitigation does.

draft-ietf-grow-route-leak-detection-mitigation tries to determine
if your neighbor leaked the route to you.
To do that, you need to know how your neighbor received the route
before he sent it to you.
That's what the ASN in the LC is for.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, March 9, 2021 11:59 AM
To: grow@ietf.org
Subject: Re: [GROW] An alternative approach to 
draft-ietf-grow-route-leak-detection-mitigation

Dear GROW,

(Removed sidrops@ from CC)

*Wearing a Working Group participant hat*

I reviewed draft-ietf-grow-route-leak-detection-mitigation-04 and it
appears to me there is a shortcut possible in the mitigation algorithm.
This shortcut in turn negates the need to specify any ASN in the "DO
Community". Only requiring a single community opens up the path to use
existing well-known RFC 1997 community as signal between BGP nodes.

The section 4.1 leak mitigation algorithm could be revised such that if
a route path present in the Loc-RIB is considered the best path and
eligible for export to EBGP neighbors, an additional verification step
is performed.

The sender could check whether a 'DO community' is present on the route
in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured
as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB
(Policy Information Base) and thus will not be present in Adj-RIB-Out -
thus blocking a leak from happening. This places the route leak
mitigation solution one step earlier in the BGP 'supply chain' process.

There is an existing well-known BGP Community known as 'NOPEER
Community for BGP Route Scope Control', described in RFC 3765.

Similar to how the mitigation does not truly differentiate between
'Providers' and 'Lateral Peers' (if one considers routing policy puzzles
often can be solved through multiple different combinations of policy in
either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT.

The recommendation then simplifies to the following three steps:

1/ Recommend network operators to never strip the RFC 3765 Community
   upon receiving a BGP route from either an IBGP or EBGP neighbor.

2/ Recommend network operators to manually configure (or have BGP OPENv2
   speakers automatically) *add* the NOPEER Community (if it wasn't
   already present) to route paths received from a Lateral Peer or
   Provider. Then proceed with whatever Import Policy applies.

3/ Recommend network operators (or have BGP OPENv2 speakers
   automatically) block routes which contain the NOPEER Community from
   propagating towards EBGP neighbor marked as 'Lateral Peer' or
   'Provider'. The procedure stops.

4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the
   route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor.
   The NOPEER community is not removed (see step 1).

As Nick Hilliard pointed out earlier in this thread, there might be
business requirements which require the operator to override the
autnomous system's default policy, but as the NOPEER Community happens
to be 'just a BGP community', operators can do as they wish with the
received routing information. A case can be made that operators - by
default - would benefit from accepting the NOPEER community and based on
its presence prevent routes from propagating further towards EBGP
neighbors in the Peer/Provider class.

The above proposal is slightly different than the implementation
requirements stemming from honoring GRACEFUL_SHUTDOWN (where the
intention is for the inter-domain signal to be honored on EBGP-IN), the
NOPEER community essentially is best honored in EBGP-OUT policies.

Promoting inter-domain use of the NOPEER community by outlining how
correctly adding & scoping based on this community one can help mitigate
BGP route leaks. The NOPEER community being readily available in most
deployed BGP speakers for any operator wishing to use the mitigation
mechanism, this might make for a compelling argument.

In short 'Down Only' is equivalent to 'Not towards Peers & Providers:

  - in EBGP-IN set NOPEER on routes received from Peers/Providers
  - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers

The above appears incrementally deployable, and compliant with the
specification of NOPEER, and can be promoted through Network Operator
Groups by converting draft-ietf-idr-route-leak-detection-mitigation to
target Best Current Practise (BCP).

Kind regards,

Job

___
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] is TCP the right layer for BMP session resumption?

[Jakob Heitz (jheitz)]

I've seen this session resumption technique in the '90s.
BMP is a one-way protocol. The BMP server sends nothing.
Thus adding this is a significant rework of BMP.
On the router, it will require remembering all the withdraws
that occurred in the BMP serial number window, so that window will
need to be limited. If the window exceeds its maximum, then
it would still be a hard reset.
If we do this, I advocate for a 64 bit serial number.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Tuesday, March 9, 2021 4:26 AM
To: draft-tppy-bmp-seamless-sess...@ietf.org; grow@ietf.org
Subject: [GROW] is TCP the right layer for BMP session resumption?

Dear group,

Yesterday we had the pleasure to hear a report from Thomas Graf on new
BMP work.

The https://datatracker.ietf.org/doc/html/draft-tppy-bmp-seamless-session-00
document outlines a concept to allow BMP clients to resume 'an existing'
session with the BMP server, reducing the need to re-transmit
information the client 'already knows'.

I informally polled some people with the question 'thoughts on
TCP_FAST_OPEN? It was brought to my attention a userspace server daemon
is not aware whether a TCP connection was set up with FAST_OPEN or not.

Furthermore, TCP_FAST_OPEN's primary use case appears to be to reduce
the burden of TCP Three-way handshake on 'short-lived' connections, and
was *not* designed for general purpose 'session resumption'.

RFC 7413 appears to suggest TCP_FAST_OPEN can be used to jam a 'small'
message (like a HTTP 302 response to a GET request) into the SYN-ACK,
whereas BMP Session Resumption is not about 'a quick and small reply',
but rather "previously there was lots of data, are you aware of that
previous data? By the way, what will follow next is lots and lots of
more data!".

TCP_FAST_OPEN appears a poor fit for the objective of BMP Seamless
Session Resumption.

If not TCP_FAST_OPEN, then what?


Perhaps inspiration can be taken from RFC 6810's RPKI-To-Router (RTR)
protocol which leverages a "Session ID" and "Serial Number" to allow
efficient (even transport-protocol agnostic!) session resumption.

This same style of session resumption mechanism can also be found in the
RPKI Repository Delta Protocol (RRDP).

Perhaps BMP would benefit from a similar resumption mechanism to reduce
the burden on servers & clients?

I welcome insights and feedback from the working group.

Kind regards,

Job

___
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] I-D Action: draft-ietf-grow-as-path-prepending-00.txt

[Jakob Heitz (jheitz)]

Michael,

I support the document.

I would not single out the incident of August in an RFC
or indeed any other incident. BCPs are not created out
of single incidents, but from a pattern emerging out of
multiple incidents. It is enough to say that a certain
scenario can occur and has occurred.

Pre-provision of AS-prepend and then removing a prepend
to the working ISP to prefer it over the failed ISP
is not a solution.

Suppose during normal operation you prepend to both of
your transit providers. Then one of your providers
can remove your prepends to gain an advantage over
the other provider.

Suppose the AS that wants to avoid the blackhole is not
the origin AS of the route. If that AS were to pre-provision
AS-prepends, then it would lose to other providers that don't.

I notice that section 3.4 is a copy of one of my emails to
the list. I did not intend for that to be placed into an RFC,
but as some background for how memory is actually used.
For the RFC, I would rephrase it as so:

vvv
Long AS-paths cause an increase in memory usage by BGP
speakers. The memory usage is not so much a concern in the
control plane BGP implementations, but more so when AS-paths
are included in Netflow messages. Netflow is processed in
the forwarding plane, where memory is more expensive than
in the control plane.

A concern about an AS-path longer than 255 is the extra complexity
required to process it, because it needs to be encoded in
more than one AS_SEQUENCE in the AS_PATH BGP path attribute.
^^^

Having contributed actual text to the draft, I'm happy to
be co-author.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Michael McBride
Sent: Friday, October 30, 2020 12:01 PM
To: Jeffrey Haas 
Cc: grow@ietf.org
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt

Thank you Jeffrey. We just update the draft with your comments. Perhaps we can 
discuss a bit more on the upcoming grow wg call.

mike

-Original Message-
From: Jeffrey Haas  
Sent: Tuesday, October 27, 2020 1:49 PM
To: Michael McBride 
Cc: grow@ietf.org
Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt

I'm rather far behind in my mail, but hopefully current on this thread.  A few 
comments on the adopted draft:

The thing I find most worthy in this document is the discussion about how 
excessive prepending increases your vulnerability to route hijacking.
This issue will exist whenever you have a well connected peer that is willing 
to forge their AS_PATH.  It's probably worth the general nod to bgpsec because 
it implies how you don't get out of that problem without locking down the 
contents of the as path.  The well connected peer issue is inferred in 3.1.

While I agree with Jakob's comments that lead to the updated section 3.4 text, 
trying to normalize "avoid other people's bugs" is awkward at best.
3.5 similarly fits in that category.

Section 4 is a nice start to describing the solution space, but is problematic 
on a few levels:
- Scoping communities from your directly attached ISP may not help you in
  some circumstances.  
- More specifics is a hard yank on traffic - if you're even permitted to
  originate them.  If you're not lucky, your prefix is already so long from
  being a small service provider that you can't make it longer.
- BGP origin code as a high order tie-breaker is a technique that works
  well, but only at places where as-paths are of equivalent length.  For
  many situations resulting in long paths, I'm not sure that helps.


Section 5's guidance of "no more than 5 prepends" is probably fine these days, 
but that is largely a matter of the current diameter of the Internet.

Section 7 - Security Considerations - could likely use a paragraph discussing 
how long prepending may make you more vulernable to route hijacking.



Feedback on the contents done, a personal anecdote:

Just prior to 2000, I used to work for a small regional ISP.  That ISP was 
multi-homed to a tier one and two tier two providers, each of which were trying 
to fight their way into tier-one space.  Our motivations for our multihoming 
were one part resiliency, one part cheapest bandwidth for the dollar, and one 
part the fact that connectivity at the time to specific sites meant that we had 
a strong reason to use a specific provider.

It was our experience at that time that it was necessary to use prepends in the 
range of 3-5 for portions of our address space in order to try to provide 
appropriate inbound load balancing.  The number was that high because at the 
points we were trying to balance traffic for, the denseness of the Internet 
topology meant that the unpadded routes were often getting closely tied for 
path length.

Prepending wasn't a complete panacea.  We regularly experienced traffic spikes 
after traffic rebalancing until we found a prepend length that was stable 
enough.  I recognize 

Re: [GROW] Support for Enterprise-specific TLVs in BMP

[Jakob Heitz (jheitz)]

Paolo,

Thanks for letting me know about our squatting.
I was not aware of it.
I'm investigating now.

Regards,
Jakob.

-Original Message-
From: Paolo Lucente  
Sent: Monday, October 26, 2020 9:23 AM
To: Jakob Heitz (jheitz) 
Cc: grow@ietf.org
Subject: Re: [GROW] Support for Enterprise-specific TLVs in BMP


Hi Jakob,

Surely - let me send you in a separate unicast email an actual example, 
taken from the Cisco bug tracker, of proprietary information elements 
squatted in public space.

That said, i rather wonder whether, from a protocol design perspective, 
the question you ask is the right one to raise.

Paolo

On 26/10/2020 16:43, Jakob Heitz (jheitz) wrote:
> What proprietary information elements are you thinking of?
> Maybe we can standardize them.
> 
> Regards,
> Jakob.
> 
> 
>> On Oct 26, 2020, at 6:16 AM, Paolo Lucente  wrote:
>>
>> 
>> Dear GROW WG Rockstars,
>>
>> I would like to get some feedback / encourage some conversation around the 
>> topic of supporting Enterprise-specific TLVs in BMP (or 
>> draft-lucente-grow-bmp-tlv-ebit-01) so to see whether it is appropriate to 
>> ask the Chairs for WG adoption.
>>
>> Context: with the Loc-RIB (draft-ietf-grow-bmp-local-rib) and Adj-Rib-Out 
>> (RFC 8671) efforts we increased the possible vantage points where BGP can be 
>> monitored; then the goal of draft-ietf-grow-bmp-tlv is to make all BMP 
>> message types extensible with TLVs since by RFC 7854 only a subset of them 
>> do support TLVs.
>>
>> Motivation: i would like to supplement what is already written in the 
>> Introduction section of the draft "Vendors need the ability to define 
>> proprietary Information Elements, because, for example, they are delivering 
>> a pre-standards product, or the Information Element is in some way 
>> commercially sensitive.", in short prevent TLV code point squatting.
>>
>> Successful IETF-standardized telemetry protocols, ie. SNMP and IPFIX, do 
>> provision to extend standard data formats / models in order to pass 
>> enterprise-specific information - including the fact that not everything can 
>> be represented in a standard format, especially when data does touch upon 
>> internals (ie. states, structures, etc.) of an exporting device. This is 
>> also true, more recently, with the possibility to extend standard YANG 
>> models.
>>
>> In this context, in order to further foster adoption of the protocol, BMP 
>> should follow a similar path like the other telemetry protocols.
>>
>> Approach: reserving the first bit of a TLV type to flag whether what follows 
>> is a private or a standard TLV and, if private, provide the PEN in the first 
>> 4-bytes of the TLV value is a simple and successful mechanism to achieve the 
>> motivation that was merely copied from IPFIX, a case of nothing new under 
>> the Sun.
>>
>> Current feedback: the only feedback that was received was last year in 
>> Singapore and it was along the lines of: we are at IETF and we should not 
>> open the backdoor for / facilitate insertion of non-standard elements.
>>
>> Thoughts? Opinions? Tomatoes?
>>
>> Paolo
>>
>> ___
>> 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] Support for Enterprise-specific TLVs in BMP

[Jakob Heitz (jheitz)]

What proprietary information elements are you thinking of?
Maybe we can standardize them.

Regards,
Jakob.


> On Oct 26, 2020, at 6:16 AM, Paolo Lucente  wrote:
> 
> 
> Dear GROW WG Rockstars,
> 
> I would like to get some feedback / encourage some conversation around the 
> topic of supporting Enterprise-specific TLVs in BMP (or 
> draft-lucente-grow-bmp-tlv-ebit-01) so to see whether it is appropriate to 
> ask the Chairs for WG adoption.
> 
> Context: with the Loc-RIB (draft-ietf-grow-bmp-local-rib) and Adj-Rib-Out 
> (RFC 8671) efforts we increased the possible vantage points where BGP can be 
> monitored; then the goal of draft-ietf-grow-bmp-tlv is to make all BMP 
> message types extensible with TLVs since by RFC 7854 only a subset of them do 
> support TLVs.
> 
> Motivation: i would like to supplement what is already written in the 
> Introduction section of the draft "Vendors need the ability to define 
> proprietary Information Elements, because, for example, they are delivering a 
> pre-standards product, or the Information Element is in some way commercially 
> sensitive.", in short prevent TLV code point squatting.
> 
> Successful IETF-standardized telemetry protocols, ie. SNMP and IPFIX, do 
> provision to extend standard data formats / models in order to pass 
> enterprise-specific information - including the fact that not everything can 
> be represented in a standard format, especially when data does touch upon 
> internals (ie. states, structures, etc.) of an exporting device. This is also 
> true, more recently, with the possibility to extend standard YANG models.
> 
> In this context, in order to further foster adoption of the protocol, BMP 
> should follow a similar path like the other telemetry protocols.
> 
> Approach: reserving the first bit of a TLV type to flag whether what follows 
> is a private or a standard TLV and, if private, provide the PEN in the first 
> 4-bytes of the TLV value is a simple and successful mechanism to achieve the 
> motivation that was merely copied from IPFIX, a case of nothing new under the 
> Sun.
> 
> Current feedback: the only feedback that was received was last year in 
> Singapore and it was along the lines of: we are at IETF and we should not 
> open the backdoor for / facilitate insertion of non-standard elements.
> 
> Thoughts? Opinions? Tomatoes?
> 
> Paolo
> 
> ___
> 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] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

What I'm trying to say here is that just saying "do not prepend" does not help.
The purpose of as-path prepending is to de-prefer a route advertised to
one AS with respect to the same route advertised to another AS.

We need to provide people with alternative methods to de-prefer
a route. For example:

To de-prefer a route at your ISP, use the communities as published
by that ISP. They will not be susceptible to preference attacks once
they leave this ISP.

To de-prefer a route further afield in the internet, as-path prepending
works in some cases, but not all. Usually 1, 2 or 3 prepends work in most
cases. Looking glasses can be used to verify if the prepends are working.

If as-prepending does not work, an alternative is to split the prefix
to the preferred path. That means to advertise multiple more-specific
prefixes that cover the range of the original prefix.

Do we want to make these recommendations?

My example illustrates one case where as-path prepending does not
work to de-prefer a route. It shows a way that large ISPs can help to
make as-path prepending work for this case.

Regards,
Jakob.

From: GROW  On Behalf Of Jakob Heitz (jheitz)
Sent: Wednesday, August 5, 2020 8:50 PM
To: grow@ietf.org
Subject: Re: [GROW] AS_Path prepend BCP

Consider a common problem

[An Ink Drawing]
Tier1-B sets local-preference for its customer to 120
and for its peer to 100.


How does Customer cause Tier1-B to prefer the path:
Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer
instead of its default path:
Content -> Tier1-B -> Backup-Provider -> Customer
?

Solution 1
--
Customer advertises split prefixes to Regular-Provider.
Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23.
This works, but causes bigger FIBs for everybody.

Solution 2
--
Customer advertises its routes with communities published by
Tier1-B to lower its local-preference to Backup-Provider.
This requires Backup-Provider to pass communities through
and for Customer to know what Backup-Provider's upstreams are.
It is operationally cumbersome.

Solution 3
--
Tier1-B implements a route-policy like:
if as-path length ge 15 then
  set local-preference 80
endif
Then Customer can add lots of AS prepends that will actually work!!

Regards,
Jakob.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

Consider a common problem

[An Ink Drawing]
Tier1-B sets local-preference for its customer to 120
and for its peer to 100.


How does Customer cause Tier1-B to prefer the path:
Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer
instead of its default path:
Content -> Tier1-B -> Backup-Provider -> Customer
?

Solution 1
--
Customer advertises split prefixes to Regular-Provider.
Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23.
This works, but causes bigger FIBs for everybody.

Solution 2
--
Customer advertises its routes with communities published by
Tier1-B to lower its local-preference to Backup-Provider.
This requires Backup-Provider to pass communities through
and for Customer to know what Backup-Provider's upstreams are.
It is operationally cumbersome.

Solution 3
--
Tier1-B implements a route-policy like:
if as-path length ge 15 then
  set local-preference 80
endif
Then Customer can add lots of AS prepends that will actually work!!

Regards,
Jakob.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 08/12/2020 (Aug 12)

[Jakob Heitz (jheitz)]

I support adoption. Already gave comments in a separate thread.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Christopher Morrow
Sent: Wednesday, July 29, 2020 10:17 AM
To: grow-...@tools.ietf.org;  ; 
grow@ietf.org grow@ietf.org 
Subject: [GROW] [WG ADOPTION]: draft-mcbride-grow-as-path-prepend-01 - ENDS 
08/12/2020 (Aug 12)

Howdy WG Folks!
There's been significant chatter on-list about:
  draft-mcbride-grow-as-path-prepend-01

Abstract:
  "AS_Path prepending provides a tool to manipulate the BGP AS_Path
   attribute through prepending multiple entries of an AS.  AS_Path
   prepend is used to deprioritize a route or alternate path.  By
   prepending the local ASN multiple times, ASes can make advertised AS
   paths appear artificially longer.  Excessive AS_Path prepending has
   caused routing issues in the internet.  This document provides
   guidance,to the internet community, with how best to utilize AS_Path
   prepend in order to avoid negatively affecting the internet."

This work seems directly in the GROW wheelhouse, and it appears folk
on-list agree. Let's decide with a WG Adoption call for this document
and see if we should continue this work officially/etc.

Please give it a read, and comment on adoption ideals here-in.

thanks!
-chris
co-chair-persona

___
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] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

I have worked on more than one BGP implementation, but not all of them, of 
course.
On memory requirements for as-paths:
Attribute sets are shared among stored routes.
That means if two stored routes have the same attribute sets, the attribute set 
is stored only once.
As-paths are shared among attribute sets.
That means if two stored attribute sets have the same as-path, then the as-path 
is stored only once.
Storing them in the control plane is not a big problem.

However, as-paths can be sent in netflow.
Netflow is generated in the forwarding plane.
AS-paths are not stored in expensive fast memory on the forwarding plane, but 
still,
using memory on the forwarding plane has greater impact than on the control 
plane.

An as-path consists of AS_SEQUENCEs (and other elements). An AS_SEQUENCE can 
contain
a maximum of 255 ASNs. If the as-path is longer, then multiple AS_SEQUENCEs are
required. The code to parse them and create them is not often exercised and
is a potential for bugs in fresh code. The older implementations have these bugs
well and truly shaken out of them.

Regards,
Jakob.

From: GROW  On Behalf Of Michael McBride
Sent: Sunday, July 26, 2020 11:42 AM
To: grow@ietf.org
Subject: [GROW] AS_Path prepend BCP

Hello wg,

We have submitted 
https://datatracker.ietf.org/doc/draft-mcbride-grow-as-path-prepend/ which is 
intended to be a bcp in the use of AS_Path prepend based on work of Doug 
Madory. As we state in the intro: AS_Path prepending is discussed in Use of BGP 
Large Communities [RFC8195] and this document provides additional, and 
specific, guidance to operators on how to be a good internet citizen with the 
proper use of AS_Path prepend.

We would encourage feedback on this document.

thanks,
mike
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[Jakob Heitz (jheitz)]

Private ASNs are 4,200,000,000 upwards.
I am requesting a block just below that > 4,000,000,000.

Regards,
Jakob.

From: Brian Dickson 
Sent: Tuesday, February 4, 2020 5:43 PM
To: Sriram, Kotikalapudi (Fed) 
Cc: John Heasly ; Jakob Heitz (jheitz) ; 
i...@ietf.org; grow@ietf.org
Subject: Re: Question about BGP Large Communities



On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>> wrote:
> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well.

They are, by default, transitive, unless local policy is to either strip them 
or filter updates based on the values (or some portion out of the values, like 
bits 6-7).


The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when
other LCs use 4-octet ASNs in the Global Administrator field. Agree?

Only real ASNs have any reasonable expectation of collision protection and 
uniqueness, i.e. ASN values <4,000,000,000

I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider:
Why not request IANA to assign a range of 256 or 1024 or some number (?)
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.

Jakob's proposal is quite reasonable.
The 32-bit ASN RFC (don't recall it offhand) reserves all values >4,000,000,000 
as private values.
Reserving only those that start (binary) 10 is a very small slice off that 
range, near the top but not the very top.
Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T 
field, is plenty and very useful.
Only having two 32-bit values is overly limiting, IMHO.

Brian


That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -Original Message-
> From: John Heasly mailto:h...@shrubbery.net>>
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
> Cc: Sriram, Kotikalapudi (Fed) 
> mailto:kotikalapudi.sri...@nist.gov>>; Job 
> Snijders
> mailto:j...@ntt.net>>; Nick Hilliard 
> mailto:n...@foobar.org>>; John Heasly
> mailto:h...@shrubbery.net>>; 
> i...@ietf.org<mailto:i...@ietf.org>; grow@ietf.org<mailto:grow@ietf.org>; 
> idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>;
> grow-cha...@ietf.org<mailto:grow-cha...@ietf.org>; 
> a.e.azi...@gmail.com<mailto:a.e.azi...@gmail.com>; Brian Dickson
> mailto:brian.peter.dick...@gmail.com>>
> Subject: Re: Question about BGP Large Communities
>
> Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
>
> Hey Jacob,
> I'd work on that with you.  Job, Morrow and I also started a draft for
> Large WKCs, but we have not submitted anything - nor made any recent
> progress.
>
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> define local data part 1 as WKC itself, and local data part 2 to be a
> value associated.
>
> I've attached that I have written so far.  Job and Morrow may or may not
> endorse this approach at this point.
>
> -heas
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[Jakob Heitz (jheitz)]

I'm asking for 67 million AS numbers, after which there will still be over 4 
billion AS numbers,
not including the nearly 95 million private AS numbers.
That's not much more than your 1024.

Regards,
Jakob.

-Original Message-
From: Sriram, Kotikalapudi (Fed)  
Sent: Tuesday, February 4, 2020 5:29 PM
To: John Heasly ; Jakob Heitz (jheitz) 
Cc: i...@ietf.org; grow@ietf.org
Subject: RE: Question about BGP Large Communities

> > Does anyone want to co-author and suggest changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).  
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
   This document defines the BGP Large Communities attribute as an
   optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well. 

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when 
other LCs use 4-octet ASNs in the Global Administrator field. Agree?
I see Jacob's draft proposes using some portion of the first 32 bits as data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;  so no part of the first 32-bits is data.

Another idea to consider: 
Why not request IANA to assign a range of 256 or 1024 or some number (?) 
of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs?
A function (e.g., route-leak protection) that requires transitive WK-LC 
will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "type" of LC.
That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -Original Message-
> From: John Heasly 
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) 
> Cc: Sriram, Kotikalapudi (Fed) ; Job Snijders
> ; Nick Hilliard ; John Heasly
> ; i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org;
> grow-cha...@ietf.org; a.e.azi...@gmail.com; Brian Dickson
> 
> Subject: Re: Question about BGP Large Communities
> 
> Tue, Feb 04, 2020 at 08:45:40PM +, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
> 
> Hey Jacob,
> I'd work on that with you.  Job, Morrow and I also started a draft for
> Large WKCs, but we have not submitted anything - nor made any recent
> progress.
> 
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then
> define local data part 1 as WKC itself, and local data part 2 to be a
> value associated.
> 
> I've attached that I have written so far.  Job and Morrow may or may not
> endorse this approach at this point.
> 
> -heas

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[Jakob Heitz (jheitz)]

The numbers are a trade off. How would you divide the numbers?

Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk  wrote:


And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; grow@ietf.org<mailto:grow@ietf.org>; 
idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>; 
grow-cha...@ietf.org<mailto:grow-cha...@ietf.org>; 
a.e.azi...@gmail.com<mailto:a.e.azi...@gmail.com>; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).



Thank you.

Sriram







___
GROW mailing list
GROW@ietf.org<mailto: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] Question about BGP Large Communities

[Jakob Heitz (jheitz)]

A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) ; Job Snijders ; Nick 
Hilliard ; John Heasly 
Cc: i...@ietf.org; grow@ietf.org; idr-cha...@ietf.org; grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).



Thank you.

Sriram






IDR J. Heitz
Internet-Draft Cisco
Intended status: Standards TrackFebruary 4, 2020
Expires: August 7, 2020


 BGP Well Known Large Community
draft-heitz-idr-wklc-00

Abstract

   A range of BGP Autonomous System Numbers is reserved to create a set
   of BGP Well Known Large Communities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 7, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



HeitzExpires August 7, 2020 [Page 1]

Internet-Draft Well Known Large Community  February 2020


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Transitivity  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations .

Re: [GROW] BGP deaggregation

[Jakob Heitz (jheitz)]

What happened to the original draft?

I can think of a high CPU risk in implementation if a covering
route covers thousands of specifics and goes away. Not to
mention the traffic loss as the specifics get readvertised.

Regards,
Jakob.

From: GROW  On Behalf Of Alejandro Acosta
Sent: Monday, November 4, 2019 6:56 PM
To: grow@ietf.org
Subject: Re: [GROW] BGP deaggregation


Hello Robert,

  I really like the way you describe the situation. And this one is a very 
important phrase:

"What is bad for Internet is propagating those more specific routes beyond the 
point that they make any difference any longer. "

  I recognize that your draft if more complicated than what I expected (sorry, 
my fault), but anyhow at the beginning I though: "this is so true: after the 
AS_PATH reaches length X or more, then it does not look necessary to propagate 
more specific routes". I might be wrong but I can not think in any single 
situation.

  Hope your draft move forward.



Alejandro,




On 11/3/19 2:28 PM, Robert Raszuk wrote:
Folks,

Allow me to express a bit of a different view - this time from enterprise 
perspective.

Actually announcing more specifics of the block one owns has real service 
advantages. So in itself it is actually a good thing !

What is bad for Internet is propagating those more specific routes beyond the 
point that they make any difference any longer.

There was proposal to aggregate those at dynamic points where sending them no 
longer brings any service/routing advantages, but apparently at that time no 
one cared much:

https://www.ietf.org/archive/id/draft-marques-idr-aggregate-00.txt

- - -

See assume I own /19 for a global network. I can't possibly announce that block 
via all of my 20 ISP peerings globally as top requirement is not to keep the 
Internet BGP table tiny, but rather to offer best service to customers.

Further more imagine I offer various services based on geo location. For 
customers in Japan I want them to go to Japan DMZ and not float to any other 
location just because his ISP is one AS hop away from NY and two AS hops away 
from Osaka or Tokyo ISPs I peer with. So if I would attract such service to US 
I would need to carry it back to Tokyo over global WAN - disaster.

See even /24 is a very coarse limit one has to deal with. I may have few 
gateways for a given service per site not 255. And each service has completely 
different service requirements from the network characteristic. If I have 8 
ISPs there

It is very clear (at least to some) that basic BGP best path routing is 
suboptimal.. For years folks have been using SLA based routing to steer packets 
over non necessarily BGP best path between Internet endpoints. The more fine 
are the announcements the better egress path selection can be achieved. So the 
Internet is no longer used to reach A & B. It is used to reach A & B in most 
optimal way for a given application.

Let's therefore keep those points in mind while blindly bashing "deaggregation" 
and calling names those who do it :). I bet no one is doing that just for fun.

Enterprises are doing it to provide the best level of service. ISPs do it to 
serve the needs of their customers. It is feasible to enhance BGP to aggregate 
when it no longer makes sense to carry more specific prefixes - let's rethink 
this.

Thx,
R.


On Sun, Nov 3, 2019 at 8:41 PM Nick Hilliard 
mailto:n...@foobar.org>> wrote:
Gert Doering wrote on 03/11/2019 19:15:
> On Sun, Nov 03, 2019 at 03:10:29PM +, Martijn Schmidt wrote:
>>> Maybe "BGP Deaggregation Slopping" as a working title?
>> Or "Scenic BGP Deaggregation", or "BGP Globetrotting", or "BGP
>> Castaways". If anything a connotation with the sea and/or submarine
>> cables would be appropriate, I think!
>
> "BGP vandalism"

"Noxious Routing"?

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
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Jakob Heitz (jheitz)]

AS_SET can be used to reduce the AS-PATH length or to hide the actual path
but still prevent as-path loops.
AS_SET can be used to prevent distribution of a route to the ASNs in the set
without overgrowing the as-path length.
This makes the Pilosov-Kapela BGP hijack easier to do.
I support deprecation, but realize that it will never be removed :(

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Jeffrey Haas
Sent: Thursday, October 3, 2019 1:25 PM
To: Rob Foehl 
Cc: IDR ; GROW WG ; Warren Kumari 
; sidr...@ietf.org
Subject: Re: [GROW] [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- 
feedback requested

On Wed, Oct 02, 2019 at 07:45:15PM -0400, Rob Foehl wrote:
> >It'd be interesting to find out what code these folk are running. Hopefully 
> >not one of my bugs. :-)
> 
> I've never had an interaction with AS_SET that could be described as
> anything other than broken -- like, ever, from any vendor.  I'd
> prefer to see them disappear entirely, but if that doesn't happen,

As Jared noted, this was more of a common thing back-in-the-day.

For properly operating proxy aggregation, you'd generally hope that all
contributing networks were properly behind the aggregating party.  However,
as the Internet has gotten more meshy, those topological considerations
don't apply anywhere near as much.

As this torches and pitch-forks campaign against as-set continues, operators
will have to figure out whether they're really happy with the two impacts:
- No proxy aggregation, ever?
- Lie about the AS_PATH when you do it.

Today you can at least infer that proxy aggregation is happening.

The second point has entertaining impact vs. RPKI, so that's the likely
forcing function.

> at least having a "no-as-sets-under-any-circumstances" policy knob
> would be helpful...

It's a fine policy knob, and I'm more supportive of that in general.

-- Jeff

___
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] Limiting AS path length?

[Jakob Heitz (jheitz)]

I agree with Jeff.
Not that Cisco has these bugs :)
Just kidding Jeff, I take your point.
Cisco once had a bug at 255. It's long been fixed.

I'll add that Netflow can use the AS-PATH. When that option is used,
the AS-PATH is downloaded to FIB, which is more constrained of memory than BGP 
is.
I don't know what kinds of bugs could result from long AS-PATHs in Netflow 
collectors.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Jeffrey Haas
Sent: Monday, September 16, 2019 9:43 AM
To: David Farmer 
Cc: Iljitsch van Beijnum ; grow@ietf.org
Subject: Re: [GROW] Limiting AS path length?

Speaking as a vendor:


> On Sep 16, 2019, at 11:18 AM, David Farmer  wrote:
> On Mon, Sep 16, 2019 at 8:25 AM Job Snijders  wrote:
>> Can we articulate what problem is solved by limiting the AS_PATH length?
> 
> I'm aware of a Netflow tool that crashes when it receives BGP paths that are 
> excessively long.  Furthermore, excessively long paths will use more memory 
> which could cause stability issues in some situations.

There are a number of bugs in implementations over the life of BGP related to 
path length.  In particular, overflows either in the number of ASes in the 
segment (max 255), where a second segment needs to be created; overflows in the 
length of the path attribute and needing to switch the size of the length field 
(the extended bit).

This is the primary reason we've tended to see strong pushes for filter length 
- attempts to avoid exercising such bugs.  Ideally, implementations should have 
been upgraded to avoid them by this point.

I am not optimistic. :-)

With regard to memory use, it's not a real problem for implementations and is 
generally noise in the real world vs. the total number of paths in your router.

> 
> Having a sanity limit on path length isn't a bad idea. Personally, I think 20 
> a little on the short side, but 40 or 50 seems like a reasonable limit. 
> Anything beyond that is most definitely excessive, and I'm not sure you would 
> even want to use such a path if it were real.

Quoting a coworker: constants are almost always wrong. :-)

-- Jeff

___
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] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

[Jakob Heitz (jheitz)]

Could you change "community set" to "set community" in action items please.
"community set" can also refer to a set of communities, the container kind of 
set.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of heasley
Sent: Monday, January 21, 2019 9:03 AM
To: Job Snijders 
Cc: grow@ietf.org
Subject: Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

Mon, Jan 21, 2019 at 01:51:50PM +0100, Job Snijders:
> > On the other side, the sentence "Vendors SHOULD share the behavior of
> > their implementations" perhaps can be made stronger by replacing the
> > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this
> > document".

s/share/clearly document/ is perhaps what is meant?

___
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] BMP loc-rib Peer-Type behavior

[Jakob Heitz (jheitz)]

Most of the routes will be deleted anyway.
Only the locally originated routes will remain.

I would suggest to keep the implicit withdraw behavior and not
to explicitly withdraw any loc-rib routes when they go away.
That means, the BGP speaker will send BMP loc-rib peer-down,
not withdraw any routes to BMP and resend the locally originated
routes again.

I don't believe GR activates in this case, because when the ASN or
BGP-ID changes, a NOTIFICATION will be sent. Can someone confirm?

Regards,
Jakob.

-Original Message-
From: Jeffrey Haas  
Sent: Thursday, December 13, 2018 11:26 AM
To: Jakob Heitz (jheitz) 
Cc: Paolo Lucente ; draft-ietf-grow-bmp-local-...@ietf.org; 
grow@ietf.org
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

Jakob,

On Thu, Dec 13, 2018 at 07:12:08PM +, Jakob Heitz (jheitz) wrote:
> Wait, a BMP server is not a BGP peer. It does not replicate a routing table.
> It is a logger/processor of information. It doesn't "delete" older 
> information,
> just because some newer information arrived.
> Its purpose it to tell you what happened at some time in the past,
> because you are trying to debug a problem or do some capacity planning
> or whatever. Just because a BGP router changed its BGP-ID does not mean
> that all the routes it had 2 days ago magically did not happen.


RFC 7854:
:A Peer Down message implicitly withdraws all routes that were
:associated with the peer in question.  A BMP implementation MAY omit
:sending explicit withdraws for such routes.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] BMP loc-rib Peer-Type behavior

[Jakob Heitz (jheitz)]

Wait, a BMP server is not a BGP peer. It does not replicate a routing table.
It is a logger/processor of information. It doesn't "delete" older information,
just because some newer information arrived.
Its purpose it to tell you what happened at some time in the past,
because you are trying to debug a problem or do some capacity planning
or whatever. Just because a BGP router changed its BGP-ID does not mean
that all the routes it had 2 days ago magically did not happen.

Regards,
Jakob.

-Original Message-
From: Paolo Lucente  
Sent: Thursday, December 13, 2018 10:58 AM
To: Jeffrey Haas ; Jakob Heitz (jheitz) 
Cc: draft-ietf-grow-bmp-local-...@ietf.org; grow@ietf.org
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior


Hi Jakob, Jeff,

+1 for the peer down / peer up sequence for the scenario described (and in 
general for changes to the peer, like peer address?).

But not re-sending RMs after the peer up seems very unclean to me. True we can 
invent an extra mechanism to say hold on your routes, like Jeff says, but i see 
the extra complexity with that (do we really need it?): it would work if the 
BMP server is building RIBs out of received RMs but what about more streaming 
data scenarios? Not to speak that if there was a route flap in BGP, due to the 
OPEN, you are effectively hiding it. Not BGP Monitoring Protocol anymore.

Paolo  

> On 13 Dec 2018, at 19:49, Jeffrey Haas  wrote:
> 
> Jakob,
> 
> On Thu, Dec 13, 2018 at 06:14:17PM +, Jakob Heitz (jheitz) wrote:
>> From: Jeffrey Haas  
>>> On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote:
>>>> Sending a peer-down followed by a peer-up seems reasonable to me.
>>>> Changing these requires a new OPEN message to neighbors, so everything
>>>> is going to bounce anyway.
>>> 
>>> I think so as well.
>>> 
>>> But what of the route monitoring messages?
>> 
>> I would leave those alone. Sending them again adds no new information.
>> The BMP server can switch the ASN and BGP-ID on its own if it wants.
> 
> That's my impression too.  However, if the implementation treats the
> peer-down as an implicit flush it won't work cleanly.
> 
> This means that something in the header needs to indicate "I'm
> updating some state, hold on to your RMs".
> 
> -- Jeff
> 
> ___
> 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] BMP loc-rib Peer-Type behavior

[Jakob Heitz (jheitz)]

I would leave those alone. Sending them again adds no new information.
The BMP server can switch the ASN and BGP-ID on its own if it wants.

Regards,
Jakob.

-Original Message-
From: Jeffrey Haas  
Sent: Thursday, December 13, 2018 3:51 AM
To: Jakob Heitz (jheitz) 
Cc: grow@ietf.org; draft-ietf-grow-bmp-local-...@ietf.org
Subject: Re: [GROW] BMP loc-rib Peer-Type behavior

On Thu, Dec 13, 2018 at 02:29:13AM +, Jakob Heitz (jheitz) wrote:
> Sending a peer-down followed by a peer-up seems reasonable to me.
> Changing these requires a new OPEN message to neighbors, so everything
> is going to bounce anyway.

I think so as well.

But what of the route monitoring messages?

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Request for early allocation of code points for draft-ietf-grow-bmp-(local-rib|adj-rib-out)

[Jakob Heitz (jheitz)]

I support these allocations.

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Wednesday, December 12, 2018 10:48 AM
To: Jeffrey Haas 
Cc: grow-...@ietf.org; grow@ietf.org
Subject: Re: [GROW] Request for early allocation of code points for 
draft-ietf-grow-bmp-(local-rib|adj-rib-out)

Dear Jeff, Working Group,

On Thu, Oct 04, 2018 at 04:02:47PM -0400, Jeffrey Haas wrote:
> [Please note that this message covers prior discussion among the BMP
> loc-rib/adj-rib-out authors and the grow chairs and ADs.  This is mostly to
> make sure we are open in our process.]
> 
> There are currently multiple implementations of the BMP adj-rib-out and
> loc-rib Internet-Drafts in progress.
> 
> As noted in draft-scudder-grow-bmp-registries-change, the registries for BMP
> parameters at IANA are a bit restrictive.  That draft is working to address
> the long-term issues. 
> 
> This e-mail is to note a formal request for RFC 7120 early allocation of the
> code points for these documents so that interoperable implementations can be
> shipped.

This is being tracked under:

[IANA #1132477] draft-ietf-grow-bmp-adj-rib-out-02

[IANA #1132479] draft-ietf-grow-bmp-local-rib-02

Kind regards,

Job

___
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] BMP loc-rib Peer-Type behavior

[Jakob Heitz (jheitz)]

Sending a peer-down followed by a peer-up seems reasonable to me.
Changing these requires a new OPEN message to neighbors, so everything
is going to bounce anyway.

Yours?

Regards,
Jakob.

-Original Message-
From: GROW  On Behalf Of Jeffrey Haas
Sent: Tuesday, December 11, 2018 1:05 PM
To: grow@ietf.org; draft-ietf-grow-bmp-local-...@ietf.org
Subject: [GROW] BMP loc-rib Peer-Type behavior

Authors,

In section 4.1, we define a new peer type to cover the loc-rib.  This is
mostly a pointer to section 4.2 of RFC 7854.


  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer Type   |  Peer Flags   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Distinguisher (present based on peer type)   |
 |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer Address (16 bytes)   |
 ~   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Peer AS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer BGP ID   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Timestamp (seconds)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Timestamp (microseconds) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

My question is with regards to Peer AS and Peer BGP ID:

If either of those fields are altered on the router, what is the expected
behavior in BMP?

I have opinions, but would like to see yours. :-)

-- Jeff

___
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] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

[Jakob Heitz (jheitz)]

I support.

Thanks,
Jakob

-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Monday, June 11, 2018 2:00 PM
To: grow@ietf.org
Subject: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 
2018.06.11-2018.06.26

Dear working group,

The authors of draft-ymbk-grow-wkc-behavior [1] requested the chairs to
consider issuing a call for working group adoption. Here is the
abstract:

"Well-Known BGP Communities are manipulated inconsistently by
current implementations. This results in difficulties for
operators. It is recommended that removal policies be applied
consistently to Well-Known Communities."

[1]: https://tools.ietf.org/html/draft-ymbk-grow-wkc-behavior-01

Please take a moment to read and evaluate the document and let the
working group know whether you'd like to continue work on this document
as working group or not.

We'll close the call on 2018-06-26

Kind regards,

Job

GROW Personnel

___
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] working group last call draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

I support.

Thanks,
Jakob.

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Ben Maddison
Sent: Tuesday, July 25, 2017 8:29 AM
Cc: grow@ietf.org
Subject: Re: [GROW] working group last call draft-ietf-grow-bgp-gshut

Hi all,

I strongly support publication. We have had this implemented in our network for 
several years!

Cheers,

Ben

--
Sent from Hiri


On 2017-07-25 14:56:15+02:00 brad dreisbach wrote:

On Mon, Jul 24, 2017 at 03:13:04PM +, Peter Schoenmaker wrote:

Hi Grow,



As discussed in the working group meeting in Prague, 
draft-ietf-grow-bgp-gshut is ready for last call.  The last call will be 3 
weeks ending August 11th 2017.  Please review the document and provide feedback.



The document is at 
https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/





i also support publication.



___

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] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

Then the same is true for RIB-in.
Since every RIB-out matches a RIB-in somewhere else,
the input must equal the output in the aggregate.
Unless BGP leaks... :)

Thanks,
Jakob.


> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Thursday, July 13, 2017 7:16 PM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: Gert Doering <g...@space.net>; grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> On Thu, Jul 13, 2017 at 08:43:27PM +, Jakob Heitz (jheitz) wrote:
> > That will certainly be the case most of the time.
> > However, the time when you really want to know will
> > invariably be the time when a peer did not get exactly what the rest
> > of the peer group got.
> 
> Two observations:
> - This argument eventually degenerates into "you need to monitor the rib-out
>   of every single peer".
> - Due to state compression of the BMP feed vs. the BGP feed, you're going to
>   lose stuff anyway.
> 
> I believe anyone expecting *any* implementation of BMP for rib-out to be a
> perfectly stateful match for their announced BGP has unrealistic
> expectations.
> 
> -- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

That will certainly be the case most of the time.
However, the time when you really want to know will
invariably be the time when a peer did not get exactly what the rest
of the peer group got.
That's when the hurt starts and the standard vendor answer will be:
peer-groups are purely a configuration convenience.
"that's probably what was sent" doesn't cut it in troubleshooting.

Thanks,
Jakob.


> -Original Message-
> From: Gert Doering [mailto:g...@space.net]
> Sent: Thursday, July 13, 2017 10:06 AM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: Gert Doering <g...@space.net>; Tim Evens (tievens) <tiev...@cisco.com>; 
> grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> On Thu, Jul 13, 2017 at 04:57:46PM +, Jakob Heitz (jheitz) wrote:
> > The problem with peer-groups is that today's high end routers
> > don't generate updates to peer-groups.
> > Peer-groups are only a convenience for configuration.
> > High end routers group peers automatically into update groups
> > and generate updates to the update group.
> > Even update groups have sub divisions to which the generated updates
> > may or may not be copied to.
> > This is done for efficient update generation with thousands of peers.
> 
> Which is an implementation detail, really.
> 
> If I configure 100 neighbours and one BMP exporter to be in "the same
> peer-group" (with the same export policy), I expect them to see the same
> prefixes, in general - except for those that are down, slow, and what
> other per-peer things might happen that shoves one of them into a different
> update groups.
> 
> If they have different export policies, I might want one "BMP exporter" per
> export policy - or inheritance group, or neighbour-group, or whatever.
> 
> ("100" is not an arbitrarily high number, it might actually be low, when
> talking about peers at major IXPs, that - with a few exceptions - all
> have the same export policy today, namely "our customer cone, except if
> the no-export-to-IXP community is set, prepend if prepend-to-IXP community
> is set")
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

The problem with peer-groups is that today's high end routers
don't generate updates to peer-groups.
Peer-groups are only a convenience for configuration.
High end routers group peers automatically into update groups
and generate updates to the update group.
Even update groups have sub divisions to which the generated updates
may or may not be copied to.
This is done for efficient update generation with thousands of peers.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Gert Doering
> Sent: Thursday, July 13, 2017 1:02 AM
> To: Tim Evens (tievens) 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> > Noisy and likely duplicate/wasteful, yes??? if one configures every peer to 
> > send Adj-RIB-Out
> > for peers that convey the same data, to which is likely not what folks will 
> > do or what I would
> > recommend doing.
> 
> The use case I have is "I want to see how routes from customer  end
> up being sent to DECIX" - which technically is a peer-group with 100+
> peers in.
> 
> Monitoring a given peer is not really useful here (that peer could be
> down) - monitoring *all* peers will give way more data than I want (I can
> collapse it again afterwards, but why eat up CPU etc. for no benefit).
> 
> So "peer group" is exactly matching my use case.
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
> 
> ___
> 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] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

What is this "approximate state"?
Why does a sample peer not give you approximate state?
Why does loc-rib not give you approximate state?

Thanks,
Jakob.


> On Jul 13, 2017, at 3:51 AM, Jeffrey Haas <jh...@pfrc.org> wrote:
> 
> Jakob,
> 
>> On Wed, Jul 12, 2017 at 10:48:28PM +, Jakob Heitz (jheitz) wrote:
>> Here are some more factors that cause different updates to peers in the same 
>> peer-group:
>> - RT Constraint: This filters different updates from different peers.
>> - Refresh requests: Only the peer that sent the request receives the updates.
>> - Nexthop SAFI (future).
> 
> You missed simple BGP loop detection such as RRs with cluster list or
> originator ID suppression for iBGP or AS_PATH for eBGP.
> 
>> IMO, the point of BMP is to take the guess work out of figuring out what was 
>> sent.
>> Peer-groups will add more guess work.
> 
> Much of my point is that even without complicated features, if you care
> about per-peer state, you have to monitor *ALL* of the peers.  Otherwise,
> you're going to miss things.  There's no "monitor one or two sample peers".  
> 
> You either care about the approximate state of the peers in the group or you
> care about the exact state.  The use cases are different.
> 
> -- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

Here are some more factors that cause different updates to peers in the same 
peer-group:
 - RT Constraint: This filters different updates from different peers.
 - Refresh requests: Only the peer that sent the request receives the updates.
 - Nexthop SAFI (future).

IMO, the point of BMP is to take the guess work out of figuring out what was 
sent.
Peer-groups will add more guess work.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, July 12, 2017 8:14 AM
> To: Tim Evens (tievens) 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Tim,
> 
> On Wed, Jul 12, 2017 at 12:28:55AM +, Tim Evens (tievens) wrote:
> > The use-case to monitor Adj-RIB-Out for a peer-group is definitely 
> > something this draft
> > addresses but appears to need more clarification.
> >
> > Noisy and likely duplicate/wasteful, yes… if one configures every peer to 
> > send Adj-RIB-Out
> > for peers that convey the same data, to which is likely not what folks will 
> > do or what I would
> > recommend doing.  I believe this can be addressed by adding "Other 
> > Considerations" section to
> > explain how one should go about using adj-rib-out.  For example, in the 
> > use-case of monitoring
> > peer-group egress policy advertisements, which is what I believe you are 
> > addressing with your
> > comment, the operator should configure at least two reliable peers in a 
> > group
> > to be monitored. This provides redundancy should one peer fail.
> 
> I had considered this as one of the possibilities.  However, if the actual
> use case is to simply see what's sent to the group, why not simply get rid
> of the per-peer need in the first place?  This avoids the somewhat hack of
> "picking reliable peers".
> 
> > This would easily provide peer-group
> > level conveyance of the egress policy. What's missing is the peer-group 
> > name so that on
> > the receiving side we can correlate (group) the peers that represent the 
> > same peer-group.
> > Providing we have the group name for the peer, the receiver can group the 
> > peers that have the same
> > group name.  If the use-case is only to monitor the peer-group policy, not 
> > specific overrides per peer,
> > then the receiver can easily de-dup the X (redundant) peers for a single 
> > representation of the peer-group.
> 
> This potentially gets to one of the case Jakob had mentioned wherein
> something might be part of a peer group, but may have radically different
> "per peer" behavior in some implementations.  By comparison, Junos does only
> minor alterations per-peer outside of the high level export policy.
> 
> If we consider two group cases: Pure group, some per-peer, then we have two
> possible ways of handling this as part of wire encoding:
> 1. Emit only per-group RM messages
> 2. If there's per-peer variance of sufficient interest, emit peer specific
>RM messages.
> 
> > This is use-case specific as there are use-cases where we need to still 
> > monitor each peer even if they are
> > part of the same peer/update group.
> >
> > In either case, this is really a receiver knob to correlate based
> > on intended operator configuration/deployment.  Although we do need the 
> > peer-group advertised as part
> > of the PEER INFO TLV, which we talked about at the BoF.  This was meant to 
> > be added, but I forgot to
> > add that.
> 
> Thanks. Since I wans't able to attend the full BoF, I don't recall if this
> had been part of the disucssion.
> 
> > Based on your proposal statements, it seems that this is only a method to 
> > correlate/map peers,
> > peers that still need PEER_UP/per-peer RM messages, into a group.
> 
> Largely correct.  Although I think you've made a good argument that a
> simpler way of providing the group mapping is to simply put it into the
> information message as part of the peer-up message.
> 
> >  IMO, this complicates
> > both the implementation (router/sender) and the receiver unnecessarily 
> > considering we can accommodate
> > this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
> > for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By 
> > adding
> > a PEER_UP info TLV to convey peer/update group name enables the receiver to 
> > easily correlate
> > peers that belong to the same group.
> 
> I'd find that a reasonable mapping mechanism.
> 
> >  How we treat and understand those peers is very much specific to the
> > operator configuration/deployment/implementation on the receiver side.   
> > The operator can
> > decide if they just need one peer per peer-group or if they want fault 
> > tolerance by including more peers.
> 
> I disagree with this case for the reasoning above.  I think if the per-peer
> case was kept as the per-group monitoring mechanism, it'd eventually
> degenerate down to the "fake peer" 

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

I said run-length-encoding.
That's data compression, not state compression.
The peers in a peer-group do not always get exactly the same updates.

Thanks,
Jakob.


> -Original Message-
> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 6:34 PM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>; Jeffrey Haas <jh...@pfrc.org>
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> 
> 
> On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)" <jhe...@cisco.com> wrote:
> 
> How about some compression, like run-length-encoding instead of peer 
> groups to reduce the firehose?
> A bunch of peers being sent nearly the same updates should compress very 
> nicely
> and you wouldn't get all the confusion that comes with peer-groups.
> 
> [TE] This is reasonable and per RFC78564 Route-monitoring is state 
> compressed.  Adj-RIB-Out follows that
> and supports both route-mirroring and route-monitoring.  The 
> interval/throttle used for the state-compression
> should be platform specific, but it should be documented so that we know the 
> granularity to expect.
> State-compression should help reduce the number of updates but monitoring 100 
> peers that belong to the
> same update/peer group will likely be wasteful as there will be a lot of 
> duplication.  In this case,
> I go back to needing some engineering love.
> 
> IMO, it does not make sense to monitor all of those peers if they in fact are 
> conveying the identical advertisements.
> In either case, we need that peer group name in the PEER UP so that we can 
> correlate the peers to groups for proper
> de-duplication. Unless we are monitoring for software bugs, the engineering 
> team/operators know which peers should
> be monitored in order to get a proper group representation based on 
> egress/export policies. Although, this does put
> a bit of a burden on engineering deployment.
> 
> To address the engineering deployment use-case of monitoring only the 
> peer-group (export policy), it would be nice
> to ease the monitoring configuration with the ability on the router to 
> dynamic select the peer to be monitored.  For
> instance, under the peer-group configuration for BMP monitoring, enable 
> "adj-rib-out best 2".  The router then would
> select the best 2 peers that represent the peer-group advertisements. This 
> can change over time as peers are added,
> removed, or experience stability issues.  In terms of BMP, normal 
> PEER_UP/PEER_DOWN with INFO TLV's would be used so
> that the receiving system can easily correlate and de-dup as needed by 
> peer-group.  If the doing peer-group
> monitoring, the peer itself wouldn't matter as much.
> 
> Peer group (including template) monitoring is not limited to Adj-RIB-Out.  
> The same use-case for monitoring the
> peer-group for export policy can be said for Adj-RIB-In as well.   The same 
> engineering/deployment configuration of
> which peer is to be monitored for the peer-group name can be used for 
> Adj-RIB-In as well. Easing this configuration
> for groups is beneficial.
> 
> BTW… we absolutely need the OPEN message to convey the capabilities.  This is 
> required to correctly parse the NRLI's
> and attributes.
> 
> 
> 
> 
> Thanks,
> Jakob.
> 
> 
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

How about some compression, like run-length-encoding instead of peer groups to 
reduce the firehose?
A bunch of peers being sent nearly the same updates should compress very nicely
and you wouldn't get all the confusion that comes with peer-groups.

Thanks,
Jakob.


> -Original Message-
> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 5:58 PM
> To: Jeffrey Haas <jh...@pfrc.org>; Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Jeff,
> 
> On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas" <grow-boun...@ietf.org 
> on behalf of jh...@pfrc.org> wrote:
> 
> 
> In such cases - use the per peer rib-out.  I do believe it has good use
> cases.  However, discussions with our customers have suggested that in 
> most
> cases it's excessively chatty and threatens to swamp the rib-in portion of
> the control channel they're actually interested in.  For them, a general
> indication of rib-out content is sufficient, even when there's some minor
> variations with specifications they may be comfortable with.
> 
> [TE] IMO, limitations around transmission of X number of peers with *-rib-* 
> monitoring should be BMP
>  sender implementation specific.  I do not believe anyone in their right mind 
> would configure a platform/sender
> for *-rib-* on all peers, but you never know. This is why limits should 
> exist, a line in the sand,
> for the platform.   Limits that apply to one platform are not necessarily 
> required to be applied to another.
> We want to enable the ability to monitor the five collection points of BGP 
> (Adj-RIB-In/pre, Adj-RIB-In/post,
> Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the 
> platform can't restrict combinations.
> 
> I'm also open to alternative encodings that permit better clustering of 
> the
> messages to avoid redundant noise.
> 
> [TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment 
> will do.  I can't imagine any sizable
> network
> that has been configured without design/engineering.  I do not believe or 
> suggest that is different with
> BGP monitoring.  BGP is big data, like IPFIX in that sense, and therefore 
> should get some engineering love,
> not willy-nilly turn it on everywhere and hope for the best.
> 
> 
> --Tim

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

[Jakob Heitz (jheitz)]

The message sent to a peer group is not always the same as what's
sent to the peer.
Some fields are rewritten at the io-write stage. Nexthop is common.
When it's written to the peer-group, it is not yet written to the peer.
If there is a slow peer in the group, anything could happen before the
message actually gets to the peer: It could go down; it could leave the
peer-group, ...

Some vendors (eg. IOS-XR) have several types of peer grouping.
There are a number of ways to group configurations.
In addition, the peers are automatically grouped into update groups such that
each member gets (mostly) the same update message.

peer-groups will add significant confusion and complexity, especially
when different vendors or even different versions from the same vendor
do different things.

Thanks,
Jakob.

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Gert Doering
> Sent: Tuesday, July 11, 2017 1:55 AM
> To: Jeffrey Haas 
> Cc: grow@ietf.org
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: 
> draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> On Mon, Jul 10, 2017 at 05:15:09PM -0400, Jeffrey Haas wrote:
> > We briefly discussed this during the bar BoF for BMP last IETF.  My
> > apologies for not presenting text before this point.
> >
> > While there are use cases where an end-user may want per-peer rib-out state,
> > some applications may not quite that level of granularity of information.
> > In many cases, it is sufficient to know what route will be sent to the peers
> > that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
> > for the remainder of this e-mail.)
> >
> > In such cases, the adj-rib-out in its current form can be quite noisy.  It
> > effectively can turn the BMP feed into trying to squeeze the entire firehose
> > of BGP traffic through the straw of a single session.
> 
> "per peer group" would actually match our use-case for rib-out much
> better than "per individual peer".  So, support for that idea.
> 
> On the actual implementation, I abstain, as I haven't read up on the
> technical details enough to make a qualified comment.
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
> 
> ___
> 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] draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

You're right Bruno. I misstated it.

Still, node A will ever have no path available.
Whether Gshut initiator sends gshut or withdraws, the result is the same:
RR sends the new path to Node A.

Thanks,
Jakob.


> -Original Message-
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Wednesday, June 28, 2017 1:56 PM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: grow@ietf.org
> Subject: RE: [GROW] draft-ietf-grow-bgp-gshut
> 
> Jakob,
> 
> 
>  > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
>  > Sent: Wednesday, June 28, 2017 10:13 PM
> >
>  > Bruno,
>  >
>  > >  > If they are available to the gshut initiating router, then they
>  > >  > are available to the other routers.
>  > >
>  > > Why?
>  >
>  > The advertising router advertised it.
>  > Your example is iBGP. When one speaker advertises, the whole AS receives 
> it.
> 
> If you assume an IBGP full mesh, I agree.
> If you have a Route Reflector topology, without add-path, I disagree.
> Only one path is advertised by the RR. We can always find a node A, in the 
> Initiator AS, which uses the g-shut
> initiator as best path/Next Hop (otherwise, nobody uses the path advertised 
> by the g-shut initiator, and there is no
> need for g-shut). That node A received a single path from its RR (the path 
> from the g-shut initiator), hence it does
> not know an alternate path. Even if another node B advertises an alternate 
> path thanks to best-external or by
> preferring its EBGP path over an IBGP path (both paths having the same 
> LOCAL_PREF, aspath length, origin, MED)
> 
> 
>  > Now suppose because of some weirdness, not every speaker in the AS 
> receives it.
>  > Then even a gshut community isn't going to make a difference.
>  > Even after the gshut, this iBGP route isn't going to get any further.
> 
> I'm not sure to follow your point.
> The route being gshut has a low local_pref hence the alternate route with 
> become best and propagated across the AS.
> 
> Thanks
> --Bruno
>  >
>  > Thanks,
>  > Jakob.
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent
> donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le
> signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles
> d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

Bruno,

>  > If they are available to the gshut initiating router, then they
>  > are available to the other routers.
> 
> Why?

The advertising router advertised it.
Your example is iBGP. When one speaker advertises, the whole AS receives it.
Now suppose because of some weirdness, not every speaker in the AS receives it.
Then even a gshut community isn't going to make a difference.
Even after the gshut, this iBGP route isn't going to get any further.

Thanks,
Jakob.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

Local pref should be reduced when the route is received.

Consider router that learns a route on 2 interfaces.
The best path is on the interface that will go down.
The right thing to do is to change the best path to the other one.
Lowering local pref at the incomming interface will do that.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> Sent: Monday, June 26, 2017 8:31 AM
> To: bruno.decra...@orange.com
> Cc: grow@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
> 
> On Mon, Jun 26, 2017 at 02:14:19PM +, bruno.decra...@orange.com wrote:
> > > From: Job Snijders [mailto:j...@ntt.net]
> >  > Sent: Thursday, June 22, 2017 10:47 PM
> >
> > [...]
> >
> > > the place where the low local preference is set
> >  > should move closer to the initiator of the gshut.  Instead of setting
> >  > the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be set
> >  > during application of the local policy on the relevant Adj-RIB-In.
> >
> > Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out
> > and not on the Loc_RIB.
> 
> Yes, that should change.
> 
> > This has a technical benefit as otherwise, the router may (locally)
> > select a backup route which it is not allowed to advertise, which
> > would trigger the sending of a withdraw of the original route. i.e.
> > not a g-shut.
> 
> Sure, but the reverse is true too. It may select a path that it is not
> allowed to advertise and with the gshut community select something else.
> This is not a strong argument.
> 
> > This may be considered as a corner case, but I don't see why we would 
> > choose not cover it.
> > I suppose that one can also see some operational drawbacks:
> > a) seems less intuitive.
> > b) traffic received from external interfaces on this specific g-shut
> > router (the egress in the AS) are forwarded on the "nominal"/g-shut
> > path, rather than on the backup path.
> 
> Yes, and avoiding the nominal path (using a backup path) has great
> benefit that the operator can monitor whether convergence is finished,
> which can be used in the decision making process when to proceed with
> the maintenance.
> 
> Operational expectation is that when one initiates a process to drain
> traffic from a node or a link, that traffic is actually, visibly drained
> away from a link.
> 
> > IMO:
> > - "a" is not a big concern as the related configuration is
> > pre-configured once for all on the router. We are not discussing the
> > configuration applied at maintenance time.
> > - "b" has no impact on the customer loss of connectivity as this
> > traffic may be locally rerouted in no time (up to zero packet loss) by
> > the router which needs to update its FIB "in place". i.e. the
> > destination IP prefix is never removed from the FIB. Only the outgoing
> > interface is changed, and during this change, both outgoing interfaces
> > are valid (both the old and the new).
> 
> This assumes that all parties involved can actually locally reroute
> without packetloss. One cannot know this. Also, what of the case where a
> single ASN is composed of a single router (or a network is operated
> without the concept of IBGP as defined by IETF).
> 
> > So although some may see a tradeoff, I'd rather favor the generality
> > of the mechanism. Specifically as not covering the corner cases may
> > surprise the operator.
> 
> Also, as it currently stands operators, are implementing it on Loc-RIB.
> 
> Another argument in favor of adjustment on Loc-RIB rather then "On
> Adj-RIB-Out but only for IBGP sessions", is that it is much easier to
> explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is
> expected to lower LOCAL_PREF as low as possible" (and simply forgo
> explaining the particular conditionals of the current draft).
> 
> Kind regards,
> 
> Job
> 
> ___
> 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] draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

It works for iBGP links too. An iBGP link is not to another AS.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
> Sent: Monday, June 26, 2017 10:07 AM
> To: bruno.decra...@orange.com
> Cc: grow@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
> 
> Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com:
> >  > Suggestions:
> >  >
> >  > OLD Abstract:
> >  >This draft describes operational procedures aimed at reducing the
> >  >amount of traffic lost during planned maintenances of routers or
> >  >links, involving the shutdown of BGP peering sessions.
> >  > NEW Abstract:
> >  >This draft describes operational procedures aimed at reducing the
> >  >amount of traffic lost during planned maintenances of routers or
> >  >links, involving the shutdown of BGP peering sessions. Additionally
> >  >this document describes the use of a well-known Border Gateway
> >  >Protocol (BGP) community to signal that a graceful shutdown has been
> >  >initiated for the tagged prefix.
> >
> > [Bruno] OK. Slightly reworded as "It defines a well-known BGP community, 
> > called gshut, to signal the graceful
> shutdown of paths to other Autonomous Systems."
> 
> s/paths to other Autonomous Systems./a path in the presence of other paths./
> 
> ie: it does nothing when there is no other path and it may not move to
> anoter AS, just to another path.  it is per-session, not per-AS.
> 
> ___
> 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] draft-ietf-grow-bgp-gshut

[Jakob Heitz (jheitz)]

I agree with Job's proposals.

In particular, the removal of the g-shut community should be carefully
considered. On the one hand, the g-shut community may not be originated
by the neighbor and is valid wherever the route may be advertised.
On the other hand, in the IPv4 and IPv6 address families, if an alternate
route is not available, the g-shut community can be spread throughout
all routers in the world, causing excessive churn.
I understand that this issue has been discussed in the working group,
but the concerns should be written into the RFC.

I think section 6 for link up should stay.
The cases desctibed are real, whether corner or not.
It does not even need route reflectors to happen.
All that is required is for a withdraw message to be processed by a router
before the new announcement.

Consider:
R2 is announcing the best-path.
R1 was under maintenance and is coming up.
R1 advertises the new path to R2.
R2 withdraws its path.
R1 advertises the new path to R3.
R3 receives or processes the withdrawal from R2 before the advertisement from 
R1.

"4.2.3 Router g-shut" should make it clear that the behavior is in addition
to the behavior of the links being shut down. Shutting down a router means all 
its
links are going down too. In addition, the gshut community should be tagged
onto the originated routes.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Will Hargrave
> Sent: Saturday, June 24, 2017 3:46 AM
> To: Job Snijders 
> Cc: grow@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
> 
> On 22 Jun 2017, at 21:47, Job Snijders wrote:
> 
> Hi all, a few comments below:
> 
> > NEW (in Pre-configuration):
> >On each ASBR supporting the g-shut procedure, an inbound BGP route
> >policy is applied on all BGP sessions of the ASBR, that:
> >o  matches the g-shut community
> >o  sets the LOCAL_PREF attribute of the paths tagged with the
> > g-shut
> >   community to a low value (a value of zero is recommended).
> 
> Since we define some terminology in 2., we should use it:
> 
> On each g-shut neighbor ASBR, an inbound BGP route policy is applied on
> all BGP sessions of the ASBR, that:
> 
> 
> I don’t think the ‘neighbor’ / ‘initiator’ terminology is very
> clear, but I struggle to find more appropriate terms right now.
> ‘g-shut receiver’?
> 
> > NEW (in Operations at maintenance time):
> >On the g-shut initiator, upon maintenance time, it is required to:
> >o  apply an outbound BGP route policy on the maintained EBGP
> > session
> >   to tag the paths propagated over the session with the g-shut
> >   community. This will trigger the BGP implementation to re-
> >   advertise all active routes previously advertised, and tag them
> >   with the g-shut community.
> >o  apply an inbound BGP route policy on the maintained EBGP session
> >   to tag the paths received over the session with the g-shut
> >   community and set a low LOCAL_PREF value.
> 
> ‘Maintained’ (in ‘maintained EBGP session’) is not a useful word
> to use here, since ultimately the session is not to be maintained at
> all! Perhaps “eBGP session” is clear enough, or use ‘impacted’
> or ‘relevant’.
> 
> 
> I have a further comment on section 6. Link Up cases. I rather feel this
> is a separate body of work, and belongs in some sort of ‘gshut-bis’
> where we can extend on this technique. Certainly there is nothing in the
> rest of the draft which prevents the use of gshut technique to improve
> link-up behaviour, so I would remove sections 6/6.1/6.2 for clarity.
> 
> Behaviour in relation to next-hop reachability across a multi-access
> network is of particular interest to me as an IXP operator, and is
> probably a whole topic of its own.
> 
> 
> --
> Will Hargrave
> Technical Director
> LONAP Ltd
> +44 114 303 
> 
> ___
> 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] [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Jakob Heitz (jheitz)]

My program to create filters does not care about customer/peer/transit.
It does not care about tier-1 or tier-2.
It looks at your BGP table and finds your largest neighbors,
sized by the number of routes it sends you.
Then for each of those neighbors, it examines as-paths in all other routes
to find all other ASNs between you and adjacent to that neigbor.
Then it builds an as-path filter that allows only those ASNs as upstreams
from that neighbor.

For example, AS-2914 and AS-209 are both tier-1 ISPs.
AS-2914 receives some routes from AS-17676 that passed through AS-209. 
(routeviews)
The simple rule "no peer routes from customers" would drop those routes.

All the filters are collected together into a single route-policy or route-map.
Then you apply the policy to all your ebgp sessions.

Here is an example of how to apply the policy:
route-policy your_neighbor_in
  if apply allow_as then
pass
  else
set community (65000:666)
set local-preference 0
  endif
end-policy

You may list all the routes that were disallowed like this:
show bgp community 65000:666


Thanks,
Jakob.


> -Original Message-
> From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
> Sent: Saturday, May 06, 2017 1:17 PM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: Robert Raszuk <rob...@raszuk.net>; grow@ietf.org
> Subject: Re: [GROW] [Idr] IETF LC for IDR-ish document 
>  (Default EBGP Route
> Propagation Behavior Without Policies) to Proposed Standard
> 
> On Fri, May 05, 2017 at 10:51:41PM +, Jakob Heitz (jheitz) wrote:
> > Thanks Robert.
> >
> > I did it without using ios-regex or other time consuming string conversion 
> > stuff.
> > Still, this method cannot scale to cover every one of several thousand AS 
> > neighbors that some ISPs have.
> > IOS cannot handle that many as-path access-lists.
> > I can see that the simple rule of "do not allow peer routes from a customer"
> > doesn't cut it, because some tier-1's have a lot of customers with over 
> > 1 routes each.
> > My filters will certainly cover all the major peers as well as major 
> > customers of ISPs.
> > I included a limit on the number of policies to write:
> > so that it will just get the major ones.
> > Also, if a routing table includes leaks, then the resulting policies will
> > continue to allow the leaks.
> > Also, some of the filters may need to add some upstreams that are not in 
> > the table of the day.
> > Basically, it is a start that may require a bit of tweaking.
> > I have a better idea of what to commit to the IOS.
> > It will be far more efficient, but I want to gauge interest first.
> 
> I built something very similar using Juniper commit scripts many years
> ago, and used it at GTT, a very large Tier 1 network.
> 
> It was fairly straight forward, all you had to do was feed it an ASN
> list of your "tier 1" peers (ASNs which should never be heard behind
> anyone other than ^asn.*), and "tier 2" peers (ASNs which can be heard
> as ^asn.* as well as ^(tier1|list|here) asn.*). It would then
> automatically create custom as-path filters for each BGP peer, based on
> the individual session and where it found the neighbor asn on the list.
> For customer sessions, it was also easy to incorporate simple as-path
> filters for the most common leaks, e.g. you should never here anything
> on the tier 1 list from any of your customers under any circumstances.
> I'd be happy to release the code if anyone is interested.
> 
> For a well-connected well-peered network, this was absurdly effective at
> preventing huge numbers of the most common routing leaks. In my
> experience, the VAST majority of leaks are caused by simple human typos,
> and/or mistakes caused by things like the (IMHO incredibly poor) default
> behavior to announce everything on a new BGP session with no configured
> policy.
> 
> That said, I have great difficulty imagining how you would successfully
> create any kind of 100% automated as-path filter system based on
> observed behavior in the routing table, based on my many years of
> experience running some of the largest Tier 1 networks on the planet.
> It's simply not practical in the real world. I WOULD highly encourage
> you to pursue building better as-path filtering tools similar to the
> scenario I described above though. It would be great if you could easily
> feed your router some as-path-lists, and configure your policy to build
> the filters described above without needing a script to create a per-as
> as-path filter expression. I wouldn't recommend trying to turn it on
> automatically, but you'd probably help a large number of ISPs by giving
> them the ability to build these filters without req

Re: [GROW] [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Jakob Heitz (jheitz)]

Thanks Robert.

I did it without using ios-regex or other time consuming string conversion 
stuff.
Still, this method cannot scale to cover every one of several thousand AS 
neighbors that some ISPs have.
IOS cannot handle that many as-path access-lists.
I can see that the simple rule of "do not allow peer routes from a customer"
doesn't cut it, because some tier-1's have a lot of customers with over 1 
routes each.
My filters will certainly cover all the major peers as well as major customers 
of ISPs.
I included a limit on the number of policies to write:
so that it will just get the major ones.
Also, if a routing table includes leaks, then the resulting policies will
continue to allow the leaks.
Also, some of the filters may need to add some upstreams that are not in the 
table of the day.
Basically, it is a start that may require a bit of tweaking.
I have a better idea of what to commit to the IOS.
It will be far more efficient, but I want to gauge interest first.

Jakob.

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, May 05, 2017 3:27 PM
To: Jakob Heitz (jheitz) <jhe...@cisco.com>
Cc: grow@ietf.org
Subject: Re: [GROW] [Idr] IETF LC for IDR-ish document 
 (Default EBGP Route Propagation Behavior 
Without Policies) to Proposed Standard

Hi Jakob,

This is really great and exactly what I had in mind when proposed auto-policy 
based on AS_PATH check. Can you commit it to IOS so it is build-in with a knob 
to use ?

Cheers,
R.

On Sat, May 6, 2017 at 12:09 AM, Jakob Heitz (jheitz) 
<jhe...@cisco.com<mailto:jhe...@cisco.com>> wrote:
Even if violating router-os's are updated, leaks will continue for a long time.
I hope I can help on the filtering side. No RFC or vendor code change required.

I wrote an app in C that takes the output of "show bgp" and creates
a set of route-policies that will prevent the leaks.
It looks at the as-paths, finds your neighbors and then all their upstreams.
Then it writes as-path policies to allow only those upstreams for your 
neighbors.
You then use the policy in your neighbor inbound policies to either drop
or set a low localpref. There is a way to show the routes that are disallowed.
Sorry, it only works with Cisco.
The source is free for anyone to do whatever they want.
Other vendors can adapt it at will.

Compile it at a Linux command line; "cc showbgp2policy.c".
Sorry about the C, but python is not my mother tongue.
Start with num_policies of 30 and see how it looks.


Thanks,
Jakob.


___
GROW mailing list
GROW@ietf.org<mailto: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] [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Jakob Heitz (jheitz)]

Even if violating router-os's are updated, leaks will continue for a long time.
I hope I can help on the filtering side. No RFC or vendor code change required.

I wrote an app in C that takes the output of "show bgp" and creates
a set of route-policies that will prevent the leaks.
It looks at the as-paths, finds your neighbors and then all their upstreams.
Then it writes as-path policies to allow only those upstreams for your 
neighbors.
You then use the policy in your neighbor inbound policies to either drop
or set a low localpref. There is a way to show the routes that are disallowed.
Sorry, it only works with Cisco.
The source is free for anyone to do whatever they want.
Other vendors can adapt it at will.

Compile it at a Linux command line; "cc showbgp2policy.c".
Sorry about the C, but python is not my mother tongue.
Start with num_policies of 30 and see how it looks.


Thanks,
Jakob.

// Write AS-PATH policies, given the output of "show bgp"
// Jakob Heitz (jhe...@cisco.com)
// This code is free. Do whatever you want. Comments and bug reports welcome.
// Compile it on a Linux command line with "cc showbgp2policy.c".
// The result is the executable, called a.out. Run it. It will print help.

#include 
#include 
#include 
#include 
#include 
#include 

#define MAX_AS_PATH 25
#define MAX_IOS_PL 500  // maximum number of policy-lists

typedef enum {
OS_NONE = 0,
OS_XR,
OS_IOS
} router_os_t;

typedef struct {
uint32_t count; // number of routes using this as path
uint32_t asn[MAX_AS_PATH];
} aspath_t;

// as adjacency
// asn[0] is an asn. asn[1] is its upstream.
// if asn[1] == 0, then asn[0] is a neighbor.
typedef struct {
uint32_t asn[2];
uint32_t count; // number of routes from this nbr (only if asn[1]==0)
} asa_t;


void *aspath_tree = NULL;
void *asa_tree = NULL;
void *nbr_tree = NULL; // nbrs in count order
router_os_t router_os = OS_NONE;

FILE *f;
char buf[1000];
int max_path_len = 0;
uint32_t current_asn, last_asn;
int num_policies, first_part;

int
cmp_aspath (const void *a, const void *b)
{
int i;
aspath_t *pa = (aspath_t*)a;
aspath_t *pb = (aspath_t*)b;

for (i=0; iasn[i] < pb->asn[i]) return -1;
if (pa->asn[i] > pb->asn[i]) return 1;
if (pa->asn[i] == 0 && pb->asn[i] == 0) return 0;
}
return 0;
}

int
cmp_asa (const void *a, const void *b)
{
int i;
asa_t *pa = (asa_t*)a;
asa_t *pb = (asa_t*)b;

for (i=0; i<2; i++) {
if (pa->asn[i] < pb->asn[i]) return -1;
if (pa->asn[i] > pb->asn[i]) return 1;
}
return 0;
}

int
cmp_nbr (const void *a, const void *b)
{
int i;
asa_t *pa = (asa_t*)a;
asa_t *pb = (asa_t*)b;

if (pa->count > pb->count) return -1;
if (pa->count < pb->count) return 1;
if (pa->asn[0] < pb->asn[0]) return -1;
if (pa->asn[0] > pb->asn[0]) return 1;
return 0;
}

void
print_asa_tree (const void *nodep, const VISIT which, const int depth)
{
asa_t *asa;

switch(which) {
case preorder:
case endorder:
break;
case postorder:
case leaf:
asa = *(asa_t**)nodep;
if (asa->asn[0] != current_asn) return;
if (asa->asn[1] == 0) {
printf("\n%6u= %6u:", asa->count, asa->asn[0]);
} else {
printf(" %u", asa->asn[1]);
}
break;
}
}

void
print_route_policy (const void *nodep, const VISIT which, const int depth)
{
asa_t *asa;

switch(which) {
case preorder:
case endorder:
break;
case postorder:
case leaf:
asa = *(asa_t**)nodep;
if (asa->asn[0] != current_asn) return;
if (asa->asn[1] == 0) {
if (num_policies <= 0) return;
num_policies--;
// now, asn[0] is the asn to write the policy for
if (last_asn != 0) {
// end the previous policy. Don't print it the first time
switch (router_os) {
case OS_XR:
printf("  or\n"
   " not as-path passes-through \'%u\'  then\n"
   "pass\n"
   "  endif\n"
   "end-policy\n"
   "!\n",
   last_asn);
break;
case OS_IOS:
printf("ip as-path access-list %d deny ^%u_\n",
   MAX_IOS_PL-1-num_policies, last_asn);
printf("ip as-path access-list %d permit _%u_\n",
   MAX_IOS_PL-1-num_policies, last_asn);
}
}
switch (router_os) {
case OS_XR:
printf("route-policy PL_%u\n"
   "  if as-path neighbor-is \'%u\'",
   asa->asn[0], asa->asn[0]);
break;
case OS_IOS:
break;
}
last_asn 

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Jakob Heitz (jheitz)]

With credentials.
Surely if you own the prefix, then you have power over those with credentials 
and the ability to remove all ROAs for it that point to as 42.

Thanks,
Jakob.


> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Friday, January 13, 2017 7:08 PM
> To: Jakob Heitz (jheitz) <jhe...@cisco.com>
> Cc: Christopher Morrow <christopher.mor...@gmail.com>; Marco Marzetti 
> <ma...@lamehost.it>; sidr...@ietf.org; GMO
> Crops <grow@ietf.org>; Job Snijders <j...@ntt.net>
> Subject: Re: [Sidrops] [GROW] I-D Action: 
> draft-ietf-sidrops-route-server-rpki-light-00.txt
> 
> > If you need to protect a prefix that you don't advertise then put ASN
> > 0 into the ROA for it.  Then nobody can advertise it.
> 
> not exactly.  someone (with credentials) can issue a roa for the same
> prefix to as 42, and it will validate the origination.  there can be
> many roas which match a single announcement; all it takes is one to be
> valid.
> 
> randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Jakob Heitz (jheitz)]

That's path validation.

Anyway, the diameter of the Internet is only about 4 to 5 AS hops.
Tier 1's only care about the radius, which is mostly 1, 2 or 3 AS hops.

Given such short AS paths, RPKI can provide a good level of protection already.
If the attacker originates a route prepended by the legitimate AS, then his 
AS-PATH will
be longer than that of the legitimate route in the large majority of the 
Internet.
But only if each AS that registers a ROA advertises every prefix matched by the 
ROA.
If it does not, then another AS can easily steal the prefix like you said.

If you need to protect a prefix that you don't advertise then put ASN 0 into 
the ROA for it.
Then nobody can advertise it.

Thanks,
Jakob.

From: Sidrops [mailto:sidrops-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Friday, January 13, 2017 2:05 PM
To: Marco Marzetti 
Cc: Randy Bush ; sidr...@ietf.org; GMO Crops ; 
Job Snijders 
Subject: Re: [Sidrops] [GROW] I-D Action: 
draft-ietf-sidrops-route-server-rpki-light-00.txt



On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti 
> wrote:

Every time one suggests a change related to the IXPs world we spend
days arguing if it affects the neutrality and how.
Do we really need that?


Anyway, i can't see why IXPs can blackhole traffic (if the destination
requests it), but cannot do the same with prefixes.
After all if a prefix is invalid the owner requested it to be verified
by the other parties.

I think part of job's point (and randy's in a way) is that you actually don't 
know if:
  192.168.0.0/23 AS1 AS3 AS8

is valid, even if you see a ROA:
192.168.0.0/16 AS8 max-len /23

... because there's nothing that keeps AS-ME from sending AS-JOB a route with 
AS8 prepended on the as-path.

I suggest to default to drop and, if possible, to switch to announce
with community if the peer requests it (for instance someone may want
to collect invalid routes for analysis).

i think you are describing implementations that the IXP may choose... I don't 
know that this draft needs to specify that at all.

-chris


On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush 
> wrote:
>> Adding grow@ietf.org for reality check.
>
> no comment :)
>
> when you choose to use a route server [0], you have out-sourced much of
> your policy and operational responsibilities.  seems to me that whether
> this includes security decisions is a contract between the user and the
> route server.
>
> so i might tell the server to drop invalids.  if i do not take that
> (configurable, i presume) option, having the server mark them seems
> helpful.
>
> randy
>
> --
>
> 0 - i suspect none of job, carlos, or i do.  so this is the experts
> telling other people what they should do. :)
>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



--
Marco

___
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] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jakob Heitz (jheitz)]

Not necessary. You can already send whatever you want. In iOS-XR, it just 
hexdumps it all. The only thing that will change is that it will print it in 
UTF8 as well. It will still hexdump. If you want no hexdump, then we need a new 
subcode.

Thanks,
Jakob.

On Nov 18, 2016, at 12:52 AM, 
"bruno.decra...@orange.com" 
> wrote:

Thanks.
--Bruno

From: Job Snijders [mailto:j...@instituut.net]
Sent: Friday, November 18, 2016 9:46 AM
To: DECRAENE Bruno IMT/OLN
Cc: Jeffrey Haas; Job Snijders; grow@ietf.org; 
i...@ietf.org
Subject: Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the 
peer's syslog at shutdown

Hi Bruno,

John Scudder was kind enough to provide extensive argumentation offlist on why 
something along these lines should be done. We'll work on a proposal. The 
length indicator is a neat idea, thanks for sharing.

Job

On Fri, 18 Nov 2016 at 17:32, 
> wrote:


> From: Job Snijders [mailto:j...@instituut.net]  > 
> Sent: Friday, November 18, 2016 1:46 AM
>
 > On Thu, Nov 17, 2016 at 04:28:50PM +, 
 > bruno.decra...@orange.com wrote:
 > > I support the draft.
 > > I also support Jeff's idea to re-use existing sub-code(s).
 >
 > Thanks for your support. Based on the feedback received so far the next
 > version of this draft will recycle Cease subcode 2.
 >
 > > 1 possible comment: the length of the "Shutdown Communication" field
 > > seems implied from the length of the data field, rather than being
 > > explicitly indicated.
 >
 > The text is explicit about the length:
 >
 > "followed by a freeform UTF-8 encoded string with a REQUIRED maximum
 > length of 128 octets. "
 >
 > and further:
 >
 > "This document tries to minimize the effects of visual spoofing by
 > allowing UNICODE only where local script is expected and needed, and
 > by limiting the length of the Shutdown Communication."
 >
 > > If so, it seems that we are closing the possibility to advertise
 > > additional data/usage, in some future. What about adding a TLV format?
 >
 > I object to using a TLV. Don't forget this is already at a TLV level:
 > Cease NOTIFICATION. If one would want to define a TLV inside this TLV, a
 > new Cease subcode can be requested from IANA.

What if someone needs to advertise additional info to an existing cease 
subcode? cf Jeff's email regarding the pain of changing subcodes.
So let's forget about the TLV. What about just adding the length of the string? 
This would still allow adding fields after the string, while having a 
negligible/null cost?

Kind regards,
-- Bruno

 > Kind regards,
 >
 > Job

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Jakob Heitz (jheitz)]

I support 

Thanks,
Jakob.

> On Nov 16, 2016, at 12:03 PM, Christopher Morrow 
>  wrote:
> 
> Howdy gentle folk,
> Let's take a few minutes to discuss and digest whether or not the subject 
> draft with abstract:
>   Examples and inspiration for operators on how to use Large BGP
>Communities.
> 
> should be adopted as a WG draft in GROW. This call ends 12/6/2016 or December 
> 6, 2016.
> 
> thanks!
> -chris
> co-chair
> ___
> 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] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

[Jakob Heitz (jheitz)]

I'm happy to keep the current subcode.

In today's IOS-XR implementation, we simply hexdump and trailing
octets after the subcode in "show bgp neighbor".
The new code could be to additionally print it in UTF8, after
validating it (no terminal escape sequences or other rubbish)
and truncating it at 128 octets. And syslog it if a valid string exists.

Thanks,
Jakob.


> -Original Message-
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, November 16, 2016 5:47 PM
> To: Job Snijders 
> Cc: i...@ietf.org; grow@ietf.org
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the 
> peer's syslog at shutdown
> 
> On Thu, Nov 17, 2016 at 10:42:15AM +0900, Job Snijders wrote:
> > On Wed, Nov 16, 2016 at 08:36:40PM -0500, Jeffrey Haas wrote:
> > > On Wed, Nov 16, 2016 at 03:15:56PM +0900, Job Snijders wrote:
> > > > Some might wonder, why "Cease"?
> > > >
> > > > The beauty of using a new Cease subcode, is that the NOTIFICATION
> > > > message type already allows extra data to be attached, so for most
> > > > implementations it will be very simple to bolt what is specified in
> > > > draft-snijders-idr-shutdown-00 on top of their existing code. In some
> > > > cases we are looking at just a handful of lines.
> > >
> > > As I commented elsewhere, changing subcodes ends up being painful from a
> > > conformance standpoint.  I would honestly not recommend a new subcode.
> >
> > I don't follow, it seems you recommend to not change the behaviour of an
> > existing subcode (conformance), but you also recommend against getting a
> > new subcode?  Can you clarify?
> 
> No new subcodes.
> Add the text to the NOTIFICATION Data section of existing subcodes, when it
> makes sense and that Data section isn't otherwise specified.
> 
> -- Jeff
> 
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-sriram-route-leak-protection-00

[Jakob Heitz (jheitz)]

ok. How about:
Each AS signs it as having passed it along, just like the BGPSEC.
Then after one AS removes it, a subsequent AS cannot add it back.

--Jakob


 -Original Message-
 From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
 Sent: Tuesday, July 29, 2014 10:10 AM
 To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org
 Subject: RE: draft-sriram-route-leak-protection-00
 
 Jacob,
 
 Please see comment inline below.
 
 Sriram
 
 Add a new attribute that means this route may be advertised up.
 This attribute must be signed by the originator of the route.
 
 Add a second attribute that means The first attribute was added.
 This attribute must be included in the BGPSEC signature.
 
 If an AS asserts that the route can no longer be advertised up,  It
 simply removes the first attribute along with its signature.
 
 Since the first attribute must be signed by the originator, no one
 else can add it back.
 
 The assertion no one else can add it back is not true.
 In your proposal, as I understand it,
 only the origin AS is signing the first attribute to its neighbor
 (i.e. second AS).
 Therefore, after an AS along the path removes the first attribute
 along with the origin's signature, a subsequent adversary AS can
 always cut and paste that thing back.
 Please let me know if I misunderstood something.
 (Note: We carefully avoided this kind of cut and paste problem in
 Path Signing in BGPSEC by requiring each AS to sign to the next AS
 in the AS path.)
 
 Sriram
 
 Now, an AS that considers itself a provider of the advertised route
 to the peer from which it received the advertisement can filter on
 the presence of the second attribute and the lack of the first to
 prevent the leak.
 
 The advantage of this solution is that it will not expose the
 customer-provider relationship to any customers.
 
 --Jakob

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-sriram-route-leak-protection-00

[Jakob Heitz (jheitz)]

There is no need to send this attribute to a collector.
If a provider respects his customer's wishes to
privacy, he will strip the attribute before sending it
to a collector.

The worst thing is sending only one prefix per update and
having to sign it differently for each AS you send it to.
Compared with that, another signature chain is a drop in the bucket.

Maybe we can combine ideas.
Take your RLP attribute and sign it in another signature chain.
Each AS adds its bits and signs it again.
First AS to remove it means propagate to customers only
You still need the The RLP was added bit in the BGPSEC signature.
Something like that?

--Jakob


 -Original Message-
 From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
 Sent: Tuesday, July 29, 2014 4:05 PM
 To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org
 Subject: RE: draft-sriram-route-leak-protection-00
 
 Jakob,
 
 OK, understood.
 But I still have these additional concerns/questions about your
 proposed method:
 1. People think having one signature chain in updates is bad enough.
 You are proposing two signature chains.
 2. How do you address the issue when an AS that is not the
 originator
 Wants to signal to a peer that the update should not be
 propagated
 Laterally to another peer or to an upstream provider
 (I.e., update can only be forwarded to customers).
 What tagging or attribute can you use to enable this if you were
 to extend your method?
 Please see what Method 2 does ('10' tag), slide 8 in my
 presentation:
  http://www.ietf.org/proceedings/90/slides/slides-90-grow-2.pdf
 3. The reason for your proposed method is that you wanted
 ASes not to have to disclose peering relationships.
 My method (the draft we are discussing) does not require that
 explicitly.
 Sure, you can infer something from the tagging.
 But even in your approach, if there were Routeviews/RIPE-RIS
 like collectors,
 That collected the signed updates, then it is easy to tell who
 stripped the
 First attribute and towards which neighbor.
 So there is an implicit discernable peering disclosure there too.
 
 Sriram
 
 -Original Message-
 From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz
 (jheitz)
 Sent: Tuesday, July 29, 2014 5:07 PM
 To: Sriram, Kotikalapudi; IETF SIDR; i...@ietf.org; grow@ietf.org
 Subject: Re: [sidr] draft-sriram-route-leak-protection-00
 
 No it wouldn't.
 For AS4 to put the goop back in, it needs to add the signatures of
 AS2 and 3 to the goop chain. The chain of ASNs in the new signature
 chain needs to be the same AS chain as in the BGPSEC.
 
 --Jakob
 
 
  -Original Message-
  From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
  Sent: Tuesday, July 29, 2014 1:52 PM
  To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org
  Subject: RE: draft-sriram-route-leak-protection-00
 
  I'm not proposing to include it in the BGPSEC signature, It would
  be a separate signature.
  Once AS2 removes it, it removes the attribute and its signature
  chain.
  The BGPSEC attribute and its signature chain is a different
  signature chain and not removed.
  
  The second attribute I proposed will be covered by the BGPSEC
  signature chain and not removed.
  
 
  Jakob,
 
  OK, you are proposing a separate signature chain besides the
 BGPSEC
  sig chain.
  But any signature chain must continue end-to-end across the whole
 AS
  path.
  Because, if a signature chain is allowed to be removed at any
 point in
  the path, then it becomes vulnerable to cut and paste attack.
  Again, consider an update received at AS5 as P [AS4 AS3 AS2 AS1],
  where AS1 is origin.
  Let us say, AS2 removed your proposed first attribute and the
  associated signature, and forwarded the update to its customer AS3.
  Now AS3 forwards the update to its customer AS4.
  AS4 can somehow learn that AS1 sent the first attribute to AS2 and
  signed it, and it can somehow get that whole 'goop' (i.e. the
  attribute and the sig of AS1).
  Then AS4 can add  back the 'goop', and forward the update to its
  *upstream provider* AS5, and AS5 would be fooled and oblivious of
 the
  leak.
 
  (Note: Again think of the reason why partial path signatures are
  disallowed in BGPSEC.
  The same principles should apply here too with any other proposed
 sig
  chain.)
 
  Sriram
 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] draft-sriram-route-leak-protection-00

[Jakob Heitz (jheitz)]

In GROW, at the mike, I proposed another solution:

Add a new attribute that means this route may be advertised up.
This attribute must be signed by the originator of the route.

Add a second attribute that means The first attribute was added
This attribute must be included in the BGPSEC signature.

If an AS asserts that the route can no longer be advertised up,
it simply removes the first attribute along with its signature.

Since the first attribute must be signed by the originator, no one else can add 
it back.

Now, an AS that considers itself a provider of the advertised route to the peer 
from which it received the advertisement can filter on the presence of the 
second attribute and the lack of the first to prevent the leak.

The advantage of this solution is that it will not expose the customer-provider 
relationship to any customers.

--Jakob

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow