(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 the
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
: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) ---
P, 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
>> C
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
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
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
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, Ap
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 wit
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
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 opera
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.
An
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
t 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
ch 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.
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-
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
ue, 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 pro
n 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 fo
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.or
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
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
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-
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 Enter
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 E
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, A
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-Pr
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
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 att
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:
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 t
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>> wr
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
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, Novemb
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 deprecati
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 do
In response to Robert's point on the IDR list related to
draft-uttaro-idr-bgp-persistence:
If BGP session terminates unexpectedly - say when max prefix is reached - it is
quite unclear on the operational consequences of such duet of features enabled
together.
may I suggest that response to the
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:
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 +0000, Jakob Heitz (jheitz) wrote:
> Wait, a BMP server is not a BGP peer. It does not rep
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
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
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
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:
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-behavio
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
6 PM
> To: Jakob Heitz (jheitz)
> Cc: Gert Doering ; 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
ely 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)
> Cc: Gert
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
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 wrote:
>
> Jakob,
>
>> On Wed, Jul 12, 2017 at 10:48:28PM +
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
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 (
Message-
> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 5:58 PM
> To: Jeffrey Haas ; Jakob Heitz (jheitz)
> 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,
>
> O
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
mess
bruno.decra...@orange.com]
> Sent: Wednesday, June 28, 2017 1:56 PM
> To: Jakob Heitz (jheitz)
> Cc: grow@ietf.org
> Subject: RE: [GROW] draft-ietf-grow-bgp-gshut
>
> Jakob,
>
>
> > From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
> > Sent: W
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 speake
Bruno,
To my mind, the purpose of graceful shutdown is to tease out the
hidden paths before sending the withdraw. In your cases, the
alternative paths are not hidden. They are already available.
If they are available to the gshut initiating router, then they
are available to the other routers. The
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
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
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,
rbil.net]
> Sent: Saturday, May 06, 2017 1:17 PM
> To: Jakob Heitz (jheitz)
> Cc: Robert Raszuk ; 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 0
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)
Cc: grow@ietf.org
Subject: Re: [GROW] [Idr]
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 a
I implemented it in IOS-XR.
It is called graceful maintenance, because it works on bringup as well as
shutdown.
It can be configured to send LOCAL_PREF or AS_PATH prepends upon activation
to support neighbors that do not recognize the GSHUT community.
Thanks,
Jakob.
> -Original Message
Too complicated.
Send the OPEN at whatever length it is.
If it's rejected, then that's it. Nothing more to do.
At this point, manual intervention is required either to remove some
configuration or to upgrade the neighbor.
Thanks,
Jakob.
> -Original Message-
> From: GROW [mailto:grow-bo
8 PM
> To: Jakob Heitz (jheitz)
> Cc: Christopher Morrow ; Marco Marzetti
> ; sidr...@ietf.org; GMO
> Crops ; Job Snijders
> 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
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 le
sub code might be wise.
(I wonder where Jibber is and whether we should hold an IETF meeting there)
Thanks,
Jakob.
> -Original Message-
> From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Tuesday, November 22, 2016 12:58 PM
> To: i...@ie
Reasons to do this:
1. A bunch of people want it.
2. It's an easy feature to implement.
3. It impacts nothing else.
Remember, it's already a free form data field.
We can put anything into it we like.
If you want a TLV, no big deal.
The first "T" is a UTF8 string.
Feel free to write drafts for ot
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.d
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.
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
I thought about something like this with extended communities before I wrote my
draft.
There is no order to communities. They can come in any order
and routers can change the order. Routers will remove duplicate communities.
So, you can only use any noun or verb once and, because there
is no order
e 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
&
alapudi.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
posed will be covered by the BGPSEC signature chain
and not removed.
--Jakob
> -Original Message-
> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Tuesday, July 29, 2014 12:31 PM
> To: Jakob Heitz (jheitz); IETF SIDR; i...@ietf.org; grow@ietf.org
>
0 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 advertis
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 signat
77 matches
Mail list logo
