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

: 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 l

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

If AS1 attests that AS3 is its provider, then there is no leak. That would be weird, but is it illegal? Regards, Jakob. -Original Message- From: Sriram, Kotikalapudi (Fed) Sent: Wednesday, March 23, 2022 12:01 PM To: Zhuangshunwan ; Jakob Heitz (jheitz) ; Jeffrey Haas Cc: sidr

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

: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) ---

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

at 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: si

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

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

Re: [GROW] [Sidrops] 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

Re: [GROW] BGP Looking Glass Capability

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,

Re: [GROW] BGP Looking Glass Capability

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,

Re: [GROW] BGP Looking Glass Capability

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

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

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?

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

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

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

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.

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

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

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

timism. 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

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

, 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

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

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

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

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

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 s

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

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

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

lly 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] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

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

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

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

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

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.

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

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

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

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

Re: [GROW] AS_Path prepend BCP

nt 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

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 ->

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

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]:

Re: [GROW] AS_Path prepend BCP

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

Re: [GROW] Question about BGP Large Communities

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: [GROW] Question about BGP Large Communities

, 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

Re: [GROW] Question about BGP Large Communities

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>>

Re: [GROW] Question about BGP Large Communities

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

Re: [GROW] BGP deaggregation

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,

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

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

Re: [GROW] Limiting AS path length?

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

Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

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:

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

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 replic

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

o: 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?).

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

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

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

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

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

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

Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

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

Re: [GROW] working group last call draft-ietf-grow-bgp-gshut

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

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

7 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

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

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> > C

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

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

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

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, 201

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

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

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

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 (

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

age- > 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

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

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

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

.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:

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

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

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

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.

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

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]

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

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,

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

rbil.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)

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

ea 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

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

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

7 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

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

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

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

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,

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

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

Re: [GROW] [Idr] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

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

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

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

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

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

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

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