Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Jared Mauch]

Similar, I have read this and it seems straightforward.

My only question  is around the BMP versioning, do we expect
that to extend past 255 at some point?

- Jared

On Mon, Dec 06, 2021 at 06:53:40AM +, matthias.arn...@swisscom.com wrote:
> Hallo GROW WG
> 
> I've read the draft. 
> TLV on BMP monitoring- and peerdown-messages complete BMP and make it uniform.
> I am looking very forward to collect ADD-PATH on our collectors as a standard 
> to bring more visability (a.e. backup-path) to our BGP monitoring.
> I think the draft is ready to forward to IESG.
> 
> Have a good week
> Matthias
> 
> 
> -Original Message-
> From: GROW  On Behalf Of Job Snijders
> Sent: Dienstag, 16. November 2021 17:16
> To: Paolo Lucente 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)
> 
> Dear all,
> 
> This starts the formal WGLC period which will run from November 16th until 
> December 1st 2021.
> 
> Please review 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1FAQOy3X%2FtjxztaFoNEwcOT4bZGliXRcnTHZbFPc%2FRQ%3Dreserved=0
> and provide comments or feedback on the grow@ietf.org mailing list!
> 
> Kind regards,
> 
> Job
> 
> On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> > Dear Colleagues, Dear Chairs,
> > 
> > A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv 
> > last week at the WG meeting. We authors believe there are no more 
> > items to work on for this draft, received inputs were processed and 
> > any questions / concerns were addressed. I'd hence like to ask to LC this 
> > work.
> > 
> > You may read motivation for this work in the draft itself, let me 
> > supplement it saying that this is a key piece of work that would make 
> > extensible every BMP message defined so far; this, in turn, would 
> > bring BMP on par with other modern monitoring (/ telemetry) protocols (/ 
> > stacks / solutions).
> > 
> > Paolo
> > 
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CMatthias.Arnol
> > d%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d
> > 9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8
> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > 000sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3Dr
> > eserved=0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3Dreserved=0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

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

[Jared Mauch]

A primary use-case of the BMP data is to provide information to a route 
collector/optimizer to determine what feasible paths may be sent to a router by 
these offline computational systems.  This requires a reliable transport where 
messages are delivered in order.

I understand others may be fine with missed or out of order messages, but this 
isn’t something that there is a lot of room to discuss.

I’m not a fan of QUIC but if it provides the ability to resume the session and 
preserve the order when there’s a [brief] network disruption that may be 
helpful for other use cases.

- Jared

> On Mar 10, 2021, at 1:47 AM, Jakob Heitz (jheitz) 
>  wrote:
> 
> 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  On Behalf Of Robert Raszuk
> Sent: Tuesday, March 9, 2021 10:38 PM
> To: John Kristoff 
> Cc: grow@ietf.org 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  wrote:
> On Tue, 9 Mar 2021 20:44:18 +
> "Jakob Heitz \(jheitz\)"  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
> 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] BGP deaggregation

[Jared Mauch]

> On Nov 3, 2019, at 5:42 PM, Christopher Morrow  
> wrote:
> 
> Where does it no longer make sense to deaggregate? Isn't that a bunch related 
> to what problem the initial announcement is trying to solve?

I’m looking to get rid of some of our more specifics in 2020 which should help 
reduce the table size, but I’m sure someone else will take up the slots almost 
immediately.

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

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

[Jared Mauch]

> On Oct 2, 2019, at 7:45 PM, Rob Foehl  wrote:
> 
> On Thu, 26 Sep 2019, Jeffrey Haas wrote:
>>> On Sep 26, 2019, at 6:43 PM, Warren Kumari  wrote:
>>> 
>>> This is nice, but what would make it more useful would be if it also
>>> reported if there are *useful* AS_SETS / if the AS_SET means anything.
>>> 
>>> For example, from Jared's email below:
>>> AS path:  14061 3356 6762 23487 27738 27738 27738 27738 27738 27738
>>> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path.
>> 
>> This one is on the buggy end of things, but still reasonably valid.  It 
>> smells like something that passed through remove-private of some flavor.
> 
> I'd wager this explains nearly all of the "set of one" instances seen in the 
> wild -- there are currently a half dozen or so with a set containing a 
> private AS at the end of the path.
> 
>> 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, at least having a 
> "no-as-sets-under-any-circumstances" policy knob would be helpful…

I think back in the days when ANS was still a major player and if you were 
routed depended upon did you follow the rules that Curtis required, they were 
still valid.  I think in most modern cases they’re likely not intended or some 
weird hybrid AS_SET+CONFED setup, likely with remove-private as Jeff speculates.

I’ve not yet composed e-mail to the people originating these, but it shouldn’t 
be hard to contact them.  They may not know about the issue.  (Generally 
operators lack awareness of what they route).

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

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

[Jared Mauch]

> On Sep 25, 2019, at 11:32 PM, Sriram, Kotikalapudi (Fed) 
>  wrote:
> 
> Jared,
> 
>> (Obviously my search in e-mail today went afoul, I see it’s adopted.. 
> 
> Yes, the draft was adopted. You can see the discussion here:
> https://mailarchive.ietf.org/arch/browse/idr/?gbt=1=WG%20adoption%20for%20draft-kumari-deprecate-as-set-confed-set
>   
> 
> One key point of the discussion was about the specification for action at 
> a receiver when an update with AS_SET or AS_CONFED_SET is received.
> The consensus seemed to be: treat as Withdraw.
> We'll soon update the draft to add that.
> 
> You had observed in that thread:
>> We should also (in parallel) reach out to some of the networks 
>> still using as_sets that are visible in the global BGP table.   
> 
> How do we do this? On NANOG, RIPE, etc. lists? Please advise.
> 
>> I did notice after this a few more BGP announcements with AS_SET 
>> occurring on a very regular basis.  I suspect someone is doing some 
>> research on it, perhaps someone reading this e-mail :-)
> 
> The percentage of updates with AS_SET is observed to be about 0.05%.
> This has been in that ballpark for a long time.
> Are you computing the percentages in what you observe? 
> Is it much different from 0.05%?
> 
> Some recent measurements we have at NIST about this are as follow:
> (thanks to Lilia Hannachi - my colleague)

Looking at RIPE RIS Live data, it seems to be very often.  I rewrote my parser 
to something lazy and the way the RIS Live message shows up in the JSON is 
array of array which breaks my laziness.  The majority seem to be AS# 27738

Unparsable AS_PATH: /[196753, 3356, 2914, 12252, 23487, 27738, [27738]]/196753 
3356 2914 12252 23487 27738 [27738]/ {'type': 'ris_message', 'data': 
{'timestamp': 1569509923.51, 'peer': '217.29.67.51', 'peer_asn': '196753', 
'id': '217.29.67.51-1569509923.51-9791488', 'host': 'rrc10', 'type': 'UPDATE', 
'path': [196753, 3356, 2914, 12252, 23487, 27738, [27738]], 'community': 
[[2914, 410], [2914, 1009], [2914, 2000], [2914, 3000], [3356, 2], [3356, 22], 
[3356, 86], [3356, 505], [3356, 666], [3356, 2074], [17152, 1]], 'origin': 
'igp', 'aggregator': '23487:200.124.247.2', 'announcements': [{'next_hop': 
'217.29.67.51', 'prefixes': ['201.183.255.0/24']}]}}
Unparsable AS_PATH: /[57381, 42708, 2914, 12252, 23487, 27738, [27738]]/57381 
42708 2914 12252 23487 27738 [27738]/ {'type': 'ris_message', 'data': 
{'timestamp': 1569509924.6, 'peer': '193.150.22.240', 'peer_asn': '57381', 
'id': '193.150.22.240-1569509924.6-9205783', 'host': 'rrc00', 'type': 'UPDATE', 
'path': [57381, 42708, 2914, 12252, 23487, 27738, [27738]], 'community': 
[[2914, 410], [2914, 1009], [2914, 2000], [2914, 3000], [42708, 200], [42708, 
208]], 'origin': 'incomplete', 'aggregator': '23487:200.124.247.2', 
'announcements': [{'next_hop': '193.150.22.240', 'prefixes': 
['201.183.255.0/24']}]}}
Unparsable AS_PATH: /[14061, 3356, 6762, 23487, 27738, 27738, 27738, 27738, 
27738, 27738, [27738]]/14061 3356 6762 23487 27738 27738 27738 27738 27738 
27738 [27738]/ {'type': 'ris_message', 'data': {'timestamp': 1569509923.5, 
'peer': '198.32.176.147', 'peer_asn': '14061', 'id': 
'198.32.176.147-1569509923.5-38413780', 'host': 'rrc14', 'type': 'UPDATE', 
'path': [14061, 3356, 6762, 23487, 27738, 27738, 27738, 27738, 27738, 27738, 
[27738]], 'community': [[3356, 3], [3356, 22], [3356, 86], [3356, 575], [3356, 
666], [3356, 2011], [6762, 1], [6762, 92], [6762, 10110], [14061, 402], [14061, 
2000], [14061, 2005], [14061, 4000], [14061, 4004]], 'origin': 'igp', 
'aggregator': '23487:200.124.224.2', 'announcements': [{'next_hop': 
'198.32.176.147', 'prefixes': ['200.124.229.0/24', '201.183.252.0/24', 
'200.124.225.0/24', '200.124.231.0/24', '200.124.227.0/24', '201.183.248.0/24', 
'200.124.228.0/24', '200.124.230.0/24', '201.183.243.0/24']}]}}
Unparsable AS_PATH: /[49605, 9002, 6762, 23487, 27738, 27738, 27738, 27738, 
27738, 27738, [27738]]/49605 9002 6762 23487 27738 27738 27738 27738 27738 
27738 [27738]/ {'type': 'ris_message', 'data': {'timestamp': 1569509924.54, 
'peer': '91.206.52.102', 'peer_asn': '49605', 'id': 
'91.206.52.102-1569509924.54-9415897', 'host': 'rrc20', 'type': 'UPDATE', 
'path': [49605, 9002, 6762, 23487, 27738, 27738, 27738, 27738, 27738, 27738, 
[27738]], 'community': [[9002, 9002], [9002, 64615], [49605, 9002]], 'origin': 
'igp', 'aggregator': '23487:200.124.224.2', 'announcements': [{'next_hop': 
'91.206.52.102', 'prefixes': ['200.124.230.0/24', '201.183.248.0/24', 
'200.124.227.0/24', '200.124.231.0/24', '200.124.226.0/24', '200.124.229.0/24', 
'201.183.252.0/24', '201.183.243.0/24', '200.124.225.0/24', '200.124.224.0/24', 
'200.124.228.0/24']}]}}
Unparsable AS_PATH: /[60501, 196753, 6762, 23487, 27738, 27738, 27738, 27738, 
27738, 27738, [27738]]/60501 196753 6762 23487 27738 27738 27738 27738 27738 
27738 [27738]/ {'type': 'ris_message', 'data': {'timestamp': 1569509924.52, 
'peer': '217.29.66.138', 'peer_asn': '60501', 'id': 

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

[Jared Mauch]

(Obviously my search in e-mail today went afoul, I see it’s adopted.. but like 
I said.. there’s a lot more AS_SETs that appeared in BGP announcements since 
this was posted).

- Jared

> On Sep 25, 2019, at 8:13 PM, Jared Mauch  wrote:
> 
> (I didn’t see any follow-up) but I suspect the intent was adoption.
> 
> I did notice after this a few more BGP announcements with AS_SET occurring on 
> a very regular basis.  I suspect someone is doing some research on it, 
> perhaps someone reading this e-mail :-)
> 
> - Jared
> 
>> On Aug 7, 2019, at 12:23 PM, Susan Hares  wrote:
>> 
>> Sriram: 
>> 
>> Are you asking for WG Adoption of this draft at this time or just feedback?
>> 
>> 
>> Sue 
>> 
>> -Original Message-
>> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi
>> (Fed)
>> Sent: Wednesday, August 7, 2019 11:43 AM
>> To: IDR; GROW WG
>> Cc: idr-cha...@ietf.org; sidr...@ietf.org
>> Subject: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback
>> requested
>> 
>> There was significant interest expressed during a SIDROPS presentation in
>> Montreal and in the discussion that followed at the mike about advancing the
>> following individual draft:
>> https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14  
>> (standards track)   
>> 
>> The authors have revised and uploaded a new version (-14).
>> Your inputs/comments are welcome. In particular, please share any specific
>> operational considerations/concerns you may have regarding this topic.
>> 
>> (Note: A BCP was published on this topics in 2011 --
>> https://tools.ietf.org/html/rfc6472 )   
>> 
>> Thank you.
>> 
>> Sriram
>> ___
>> 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] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Jared Mauch]

(I didn’t see any follow-up) but I suspect the intent was adoption.

I did notice after this a few more BGP announcements with AS_SET occurring on a 
very regular basis.  I suspect someone is doing some research on it, perhaps 
someone reading this e-mail :-)

- Jared

> On Aug 7, 2019, at 12:23 PM, Susan Hares  wrote:
> 
> Sriram: 
> 
> Are you asking for WG Adoption of this draft at this time or just feedback?
> 
> 
> Sue 
> 
> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi
> (Fed)
> Sent: Wednesday, August 7, 2019 11:43 AM
> To: IDR; GROW WG
> Cc: idr-cha...@ietf.org; sidr...@ietf.org
> Subject: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback
> requested
> 
> There was significant interest expressed during a SIDROPS presentation in
> Montreal and in the discussion that followed at the mike about advancing the
> following individual draft:
> https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14  
> (standards track)   
> 
> The authors have revised and uploaded a new version (-14).
> Your inputs/comments are welcome. In particular, please share any specific
> operational considerations/concerns you may have regarding this topic.
> 
> (Note: A BCP was published on this topics in 2011 --
> https://tools.ietf.org/html/rfc6472 )   
> 
> Thank you.
> 
> Sriram
> ___
> 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] Limiting AS path length?

[Jared Mauch]

Operator here.

We have limitations around 128 to avoid some vendor bugs. I suspect we could 
remove them but people with mental histories of pain always worry about that 
change. 

Sent from my iStarship

> On Sep 16, 2019, at 12:42 PM, Jeffrey Haas  wrote:
> 
> 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] Value of timestamps in BMP header for local-rib monitoring

[Jared Mauch]

> On Jun 13, 2019, at 12:02 PM, Tim Evens (tievens)  wrote:
> 
> Thanks Mukul. I'll also update this one as noted. 


Tim,

Sorry, are you saying you’re updating it to proposal #1 or #2 ?

(I would want #2)

- Jared

>  
> On 6/13/19, 8:16 AM, "GROW on behalf of Mukul Srivastava" 
>  wrote:
>  
> Hi All
>  
> The current BMP Local-RIb draft doesn’t define what timestamp should be used 
> in Per-Peer header for BMP local RIB monitoring.
>  
> BMP RFC 7854 defines “Timestamp” in Per-Peer header as below:
>  
> Timestamp: The time when the encapsulated routes were received(one may also 
> think of this as the time when they were installed in the Adj-RIB-In), 
> expressed in seconds and microseconds since midnight (zero hour), January 1, 
> 1970 (UTC).  If zero, the time is unavailable.  Precision of the timestamp is 
> implementation-dependent.
>  
> The above timestamp use doesn’t make much sense for local RIB monitoring 
> case.  
>  
> Proposal:
> 1.  Since local RIB is not specific to a peer, the time stamp could be 
> the time when BMP RM message was created or sent to BMP collector.
> 2.  Another option would be that the timestamp value be the time when 
> this prefix was installed in local RIB.  
>  
> Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, 
> something like this:
>  
>o  Timestamp: The time when the encapsulated routes were installed in
>   The Loc-RIB, expressed in seconds and microseconds since
>   midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
>   unavailable.  Precision of the timestamp is implementation-
>   dependent.
> Thanks
> Mukul
> ___
> 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

[Jared Mauch]

> On Dec 13, 2018, at 2:12 PM, 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.


Actually there are consumers who treat it like this.  This is why on up we 
get a dump of what the router might have in adj-rib-in, then get deltas.

It is the expectation of a consumer they will get this data similar to being a 
BGP peer.

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

Re: [GROW] Making BMP registries FCFS

[Jared Mauch]

I would also support adoption on the part of the WG if the chairs were to ask 
for it. 

Jared Mauch

On Sep 20, 2018, at 4:26 AM, Randy Bush  wrote:

>> A while ago we talked about this. I finally wrote a draft for it,
>> https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt:
>> 
>> Abstract
>> 
>>   This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
>>   making a change to the registration procedures for several
>>   registries.  Specifically, any BMP registry with a range of
>>   32768-65530 designated "Specification Required" has that range re-
>>   designated as "First Come First Served".
>> 
>> It's super short, 3 pages including all the boilerplate. I'd like to
>> propose it as a WG item (and ideally, move it quickly to WGLC).
> 
> make it so
> 
> randy
> 
> ___
> 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-ss-grow-rpki-as-cones-00

[Jared Mauch]

> On May 23, 2018, at 1:24 PM, Brian Dickson  
> wrote:
> 
> Sorry for the top-reply:
> 
> I think the fundamental problem with AS-SETs in IRR is the unilateral aspect 
> of "control" of what amounts to assertion of a relationship.
> 
> Given the basic mechanisms already in play for RPKI (keys, signing, etc.), I 
> think this would be easy enough to fix:
>   • Any relationship asserted should require both parties to confirm by 
> signing
>   • Any relationship can be revoked by either party (thus fixing the main 
> IRR problem)
>   • Anyone else can confirm that relationship via signatures
>   • The nature of the relationship would need to be reflected, in order 
> to have maximum benefit. E.g. transit-provider, transit-customer, peer, 
> mutual-transit, other.

So, this poses some challenges as it won’t actually fit into a well defined set 
of use-cases.

Being able to specify who can announce my route (or routes) and giving them a 
good way to specify this cone seems helpful.  Requiring both parties to sign, 
countersign, etc.. is not desirable or is problematic operationally.  How many 
e-mails back and forth have you seen go by where getting this updated is a 
problem?  I’ve seen quite a bit.  Not everyone is well automated and trying to 
use this as a sledge to turn that screw is going to be met with a collective 
yawn and be ignored by many folks.

- Jared

>   • This plays well with preventing route-leaks, too.
> This would only require the ability to associate things like groups of ASNs 
> with single entities that speak for them. If that isn't already part of RPKI, 
> it would need to be added.
> 
> Brian
> 
> On Wed, May 23, 2018 at 10:07 AM, Job Snijders  wrote:
> On Wed, May 23, 2018 at 08:03:45AM -0700, Randy Bush wrote:
> > >>> me and Job Snijders have recently submitted
> > >>> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an
> > >>> attempt to bring as-sets into RPKI to facilitate route filtering.
> > >> 
> > >> in irr, an as-set may reference an as-set.  could you explain the
> > >> authority model you have for this when as-sets are signed?
> > 
> > > My initial thinking for RPKI AS Cones, is that a given Cone in an
> > > ASN's namespace can only be defined by the owner of the ASN in who's
> > > namespace the Cone is defined.
> > 
> > namespace?
> 
> In the IRR world we have the concept of hierarchical naming of AS-SETs:
> an example is "AS15562:AS-SNIJDERS" [1] - under the "AS15562" hierarchy
> only the owner (or delegated folks) can add/change/remove AS-SETS. I
> call this a namespace, should a different term be used?
> 
> > isn't this the irr authorisation model?
> 
> The IRR AS-SET feature is working pretty well (since it is better than
> nothing), but there are some downsides.
> 
> For instance "AS15562:AS-SNIJDERS" can exist in multiple IRR databases,
> and we don't know which of those was actually created by the owner of
> AS15562. I hope this can be addressed in AS Cones.
> 
> Another problem is that there no longer is a way (or perhaps there never
> was) to autodetect what AS-SET should be used by which organisation to
> generate a filter. RPSL is broken, fundamentally flawed. Perhaps this
> can be addressed - not by introducing a new language - but just having a
> handy naming convention. Think of it as "AS15562:AS-2914", so AS 2914
> knows it should use AS15562:AS-2914 if it exists, and if it doesn't
> exist use AS15562:AS-DEFAULT.
> 
> > and how did that work out for us?
> 
> I consider it a feature that anyone can add anything to an AS-SET they
> created, this puts the workload on transit providers and doesn't require
> stub networks to do anything. The "member-of:" feature is barely used
> and seems to pose too much work.
> 
> Clock is ticking... multiple RIRs are struggling with their IRRs (or
> lack thereof). If IETF does not pony up a solution that is good enough
> for operational purposes, we may end up with RIRs investing in legacy
> technology and a continuation of the duplication/discovery/ownership
> issue. There is an opportunity here and now, let's work on it?
> 
> Kind regards,
> 
> Job
> 
> [1]: 
> https://apps.db.ripe.net/db-web-ui/#/query?searchtext=AS15562:AS-SNIJDERS#resultsSection
> 
> ___
> 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] Route Server ASN stripping hiding considered harmful?

[Jared Mauch]

> On Dec 18, 2017, at 12:38 PM, Nick Hilliard  wrote:
> 
> Job Snijders wrote:
>> You and Martijn appear to argue that the 'best path selection'
>> component should not be fiddled with, which leaves me wondering
>> whether we have any other methods to implement a track record ala
>> 'this path announcement passed through RS AS XYZ' other than
>> communities. Or are you of the opinion that the lack of visibility is
>> not a problem to begin with?
> 
> communities are low-hanging fruit and non-intrusive, and probably not a
> bad thing to do.
> 
> If you plan to spend time and energy dealing with the underlying
> problem, i.e. routing leaks, then I'd suggest continuing to work on
> getting IXPs to implement prefix filtering on their route servers.  It's
> laborious and thankless but will actually fix the problem in the longer
> term - and it needs to be done anyway.

I know that Job has been pushing for the above, perhaps not in your view
but in the view of others here.

I do think that having a RS emit a community saying “RS_ASN:xxx” would be
of value.  As mentioned in other emails, finding these edges can be quite
complex when doing operations.

If we continue to see the active threats, market forces will dictate the
resulting implementations.

I’d like to see improvements in routing security, but the path forward is murky.

Aside from AS_PATH & Communities, are there other ideas?

- Jared

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

Re: [GROW] [Idr] Review of draft-ietf-grow-bgp-reject-05

[Jared Mauch]

> On Apr 19, 2017, at 9:53 AM, Alvaro Retana (aretana)  
> wrote:
> 
> My bigger issue with 9.1.1 is that it is the first step of the decision 
> process – the intent, as I understand it, is for the routes not to even reach 
> that point.

I’m not in agreement here as it’s well within the power of an implementation to 
provide a knob to circumvent these safety knobs.  We can’t have people 
pretending it’s the early 90s anymore.  We must have safe implementations and 
defaults.

Are you saying that IOS-XR is non-compliant with 9.1.1 because it does not have 
“bgp unsafe-ebgp-policy” as the default?  At what point does the Cisco 
implementation make that decision?

We seem to be triangulating on where in the exact decision process people are 
considering a route feasible or ineligible, can you speak to your 
implementation?  That may provide guidance in documenting the IOS-XR practice.

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

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

[Jared Mauch]

On Sun, Mar 19, 2017 at 09:47:30PM -0400, Christopher Morrow wrote:
> Howdy folks!
> There were 3 people, 4 if you include me, that had something to say here...
> 
> it'd be nice if a few more folk had read through and agreed/disagreed :)
> 
> I'll delay decision making until Tues (3/21/2017)... read and respond pls :)

I have read this and support it :-)

    - Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

Re: [GROW] [IPFIX] [OPSAWG] WG adoption poll fordraft-li-opsawg-ipfix-bgp-community-02

[Jared Mauch]

On Thu, Feb 16, 2017 at 07:53:23PM +0800, 李振强 wrote:
> Thank you P.J. Aitken.
> 
> The length of IPFIX message is sufficient for BGP standard communities, since 
> the length of standard community is 4 octets. But the sizes of extended 
> community, large community and wide community are bigger than the size of 
> standard community. If the working group agrees to cover the above all kinds 
> of communities in this draft, do you think we should open the discussion for 
> IPFIX
> 

I believe there should be coverage for 1997 as well as the upcoming 
large communities.

- Jared

___
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

[Jared Mauch]

On Fri, Nov 18, 2016 at 08:01:30PM +, Jakob Heitz (jheitz) wrote:
> 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.
> 

One other thing we will need from the vendors is
the information to be available in the show commands around the
BGP neighbor as well, eg:

Router#show bgp neighbor

BGP neighbor is fe80::1
 Remote AS 65000, local AS 65000, internal link

  Connections established 1; dropped 0
  Last reset 2d03h, due to BGP Notification sent: code/text here
  Time since last notification sent to neighbor: 2d03h
  Error Code: appropriate code goes here
  Notification data received (or sent):
UTF-8 string goes here






-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

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

[Jared Mauch]

I support adoption of this document.

> On Nov 15, 2016, at 10: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] I-D Action: draft-ietf-grow-bgp-reject-00.txt

[Jared Mauch]

> On Aug 13, 2016, at 1:53 PM, Gert Doering  wrote:
> 
> "Neither send nor receive prefixes" or "not bring up the session at all"
> are workable alternatives from an operational PoV.

I’m ok with implementors doing what XR does by default without 
"unsafe-ebgp-policy”
set.

There’s no reason in 2016 for any implementation to accept routes without a 
policy set.

I’d prefer it if implementors removed some of these crutches that permit the 
unsafe BGP
policies that permit things as seen in rfc7908 and otherwise.

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

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[Jared Mauch]

> On Jun 29, 2016, at 5:10 PM, Nick Hilliard  wrote:
> 
> Job Snijders wrote:
>> Do you have any more comments or concerns queued up?
> 
> I don't think the draft is well specified in terms of its intended
> semantics.  This is a problem with a standards track document,
> particularly one with big scary warnings in the security considerations
> section.  It needs to be tightened up substantially before publication
> could be considered.

Looking at section 5 of https://www.rfc-editor.org/rfc/rfc5635.txt

I think provides some guidance of helpful text to improve this section. While
some hardware may not support certain capabilities, limiting a specification
to an exact generation of operator hardware would be shortsighted.

I suspect one could re-use much of the rfc5635 text without much if any
additional commentary.

- Jared

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

Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

[Jared Mauch]

> On Nov 2, 2015, at 2:04 AM, Jeffrey Haas  wrote:
> 
> I suggest it be considered for BCP status.  Why BCP?  Because operators 
> already have to go do this for the safety of their network and are doing so 
> via configuration template.

How do we get the implementors to adhere to this BCP?

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

[GROW] draft-mauch-bgp-reject

[Jared Mauch]

I plan on covering this briefly in the GROW meeting today and uploaded the 
revised text that has been sitting in my output queue since August.

This is basically codifying the fact that you MUST NOT default to "bgp 
unsafe-ebgp-policy” for any BGP speaking device.

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

Re: [GROW] WGLC: draft-ietf-grow-bmp - ENDS: 8/7/2015 (aug 7 2015)

[Jared Mauch]

I also support publication of draft-ietf-grow-bmp.


-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

Re: [GROW] Route leaks

[Jared Mauch]

Communities are not sent by default (eg Cisco). Route leaks come for free on 
Cisco too. 

Jared Mauch

 On Jul 25, 2014, at 3:12 PM, Tony Tauber ttau...@1-4-5.net wrote:
 
 How is this different than tagging with communities today?
 In either case, the provider's correct action on the semantics is needed (and 
 can go awry through misconfiguration).
 
 Tony
 
 On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery dougm.w...@gmail.com 
 wrote:
 The last point that Sriram made is important to the higher level discussion 
 of the problem.
 
 Semantically what we are proposing is that a BGP speaker can ad a semantic 
 tag to a route that describes restrictions on the intent of the 
 authorization that is implicit in sending a peer a BGP route.
 
 Note that the one tag we suggested was not DOWN or CUSTOMER it was the 
 intent that the sender expects that you will not redistribute this update to 
 transit providers.
 
 I am sending you this route, but I do not wish it propagated to your 
 providers
 
 So discussing the semantics of the tag: what that tag applies to (e.g., 
 specific route, vs peering session), what the tags attempt to signal, what 
 the security properties of such a tag should be, and what policies might one 
 build using such tags ... is the important part.
 
 The specific encoding proposed was the result of one attempt to think 
 through these issues ... but not all the thoughts made it into the draft.
 
 
 
 dougm
 -- 
 DougM at Work
 
 ___
 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] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

[Jared Mauch]

On May 19, 2014, at 9:02 PM, Danny McPherson da...@tcb.net wrote:

 Good point Sandy, this was definitely meant to serve as more of a motivation, 
 illustrating a real problem that smart people should focus on because it 
 happens all the time and some real heavy solutions being consider wholly 
 ignore it.  Quibbling about “definitions” that satisfy those in the know 
 (some of which are heavily invested in solutions that don’t consider this an 
 issue) at this stage is likely futile, and I’d at least be happy just 
 publishing this as a “motivational” and if it only collects dust, so be it..

Is there a need for this to be explicitly documented within the IETF?  I 
certainly agree there is a problem, but this feels like operational guidance or 
perhaps a BCP or similar document?  (eg: Filter your peer ASNs from your other 
peers).

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

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

[Jared Mauch]

On Jan 3, 2013, at 9:33 PM, Jeff Wheeler wrote:

 Non-sequitur.  Cyclic resets are orthogonal to treat-as-withdraw.  As 
 enumerated above, ignore-bad-message is harder to implement and is more 
 dangerous.
 
 No, ignore-bad-message is not harder to implement.  To say so is simply a lie.

Jeff,

The challenge I see here is that the NLRI is always at the END of the message.  
The parsing problem is going to happen before the NLRI.  I certainly don't want 
my BGP implementation doing 'fuzzy' things with the message and producing 
further poor results.  It's no way to run a network, and can be difficult to 
code.

Once again I must assert that this is a problem best left to be fixed in the 
individual implementations.  We can certainly expect a high level of standard 
for software, but expecting no defects is unrealistic.

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

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

[Jared Mauch]

On Jan 3, 2013, at 6:34 PM, Brian Dickson brian.peter.dick...@gmail.com wrote:

 
 
 On Thu, Jan 3, 2013 at 5:54 PM, Smith, Donald donald.sm...@centurylink.com 
 wrote:
 -Original Message-
 From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of
 Tony Li
 Sent: Thursday, January 03, 2013 3:31 PM
 To: Jeff Wheeler
 Cc: i...@ietf.org; grow@ietf.org
 Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-
 error-handling-06.txt
 
 
 I support the general concept of improved error handling and softer
 failures when possible.
 
 It exasperated it by causing peers to drop and having to rebuild ribs/fibs 
 etc... continuously.
 
 Other than getting it noticed I doubt a reset will ever make a misbehaving 
 router stop misbehaving.
 
 The continuously points to the problem. If a session drops because of 
 syntactic issues, it should stay down.
 Does that make sense? It is analogous to treat-as-withdraw, just using a 
 much larger hammer. :-)
 

I think that Mike Long had it right earlier today in saying that the vendor 
implementation should shut the session just like max-prefix. (perhaps with a 
default restart-timer measured in tens of minutes)?  This doesn't seem to need 
a protocol change though.  I am also a bit wary of as Tony put it .. nerd 
knobs.  I've seen how some of these legacy knobs break in some new/future 
release as they migrate through our templates/platforms over the years.  Nobody 
even knows what it does anymore, and the original purpose is gone but the 
parser still takes it ...

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

Re: [GROW] MRT

[Jared Mauch]

On Nov 27, 2012, at 12:58 PM, Christopher Morrow wrote:

 On Tue, Nov 27, 2012 at 11:43 AM, Mattia Rossi
 mattia.rossi.mailingli...@gmail.com wrote:
 (http://jon.oberheide.org/projects/pybgpdump/) which is very nice for a
 quick analysis of MRT dumps.
 
 sadly jon's tool is ... not very well updated :( or gives me lots and
 LOTS of error messages on reading current routeviews/ris update
 streams :(
 
 (noting i know this from attempting to parse those update files around
 the time of the moratel leak of google ip space ~2 wks ago).'

The MRT file parser I sent you should work.

- Jared

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

Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

[Jared Mauch]

On Oct 3, 2012, at 10:21 AM, Russ White ru...@riw.us wrote:

 
 The problem as I see it is many of those that operate in the BGP/DFZ don't 
 know what they are doing.
 
 ???
 
 Then they shouldn't be using this technique. Or perhaps even running
 BGP. Protocols provide rope. It's choice whether you make good things or
 bad things with the rope provided.
 
 :-)

Sure.

But expecting them to do anything 'smart' has been a huge undertaking.  Some 
providers (e.g.: Bellsouth/ATT) have been trying for 2+ years to fix their 
unnecessary aggregate leaks with no success. 

I'm not sure how to convince smaller folks to do the right thing if the big 
people can't sort it out. (even with the right hooks).

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

Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

[Jared Mauch]

On Oct 2, 2012, at 5:23 PM, Russ White ru...@riw.us wrote:

 
 - Path information is lost.  While this doesn't impact loop prevention, this
  information is operationally useful.
 
 +1.  Reachability data optimisation is highly desirable and may one day be
 necessary, but this is one of the wrong places to do it.
 
 Again, I'm a bit baffled. Can you explain how this draft actually
 removes reachability optimization in the DFZ? It's carefully crafted NOT
 to remove any reachability information that produces a shorter path.
 
 I know the chairs have already (short sightedly, IMHO), decided not to
 accept this draft as a WG item, but I'd really like to understand what
 specific situation you can draw up where the proposed mechanism
 increases the stretch in any path.

Russ,

The problem as I see it is many of those that operate in the BGP/DFZ don't know 
what they are doing.

This makes solving these problems infinitely more complex compared to how they 
should be if everyone was sane.


58.64.162.0/24   2497 701 6453 45474 174 17444 

is a great example for me and easily observed (even if just as a transitory 
announcement).

I see this in my router, but the above leaked out...

*i58.64.160.0/19 x.x.x.x120  0 17444 17444 17444 17444 
17444 17444 17444 i

Not only did the above route look disgusting for the as_path, but there should 
have been some better covering prefixes appear perhaps?

Anyways, you can't make people route sanely and the ISPs have a hard time 
rejecting the money people want to pay for the extra flexibility.

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

Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling

[Jared Mauch]

On Apr 16, 2012, at 7:50 AM, Jakob Heitz wrote:

 This should not overwhelm a router.
 However, a more serious consequence is a lot of flapping routes.
 Serious enough to consider. We could dust off some dampening code for it.
 
 Note the previous discussion was about repeated treat as withdraw
 errors. I support the use of an operational message for these errors,
 but nothing for repetitions of them. Repeated operational messages
 may get annoying, but they are not going to disrupt service.


The problem we have today is two fold:

1) Vendors have done a bad job of reporting the routes related to a BGP session 
reset
  a - multiple vendor environments can have somewhat catastrophic failure modes

2) Stability of the internet (as defined by keeping the BGP session up for the 
non-broken routes) is important; overall reachability is as well.  (to Tony 
Li's comment about how an update has both feasible and infeasible nlri in it).

A broken implementation is just that, broken.  About half the problems in the 
past 24 months are due to improper parsing of a well formed update.  With the 
balance the improper propagation of a invalid update.  (I'm willing to be 
corrected on the exact ratio, but I believe these are the two cases seen unless 
my memory fails me).

I'm hard pressed to imagine a case where the code doesn't quickly get 
unwieldily from this situation.

Part of the requirements of solving this problem will be:

a) Sending an UPDATE message with only new/updated NLRI and zero items in the 
withdrawl.
b) Sending a KEEPALIVE (or other well known message that will be parsed 
properly).
c) Sending an UPDATE message with no new NLRI and only those to be withdrawn.

Perhaps this mode is only triggered after a previous session drop within 3600 
seconds.   This means you need to track that state, track a timer, and utilize 
this new (capability?) mode.

We also have a more systematic issue here.  Those participating in the global 
BGP ecosystem need to play an active role in the maintenance of these devices.  
Failure to do so can and will harm the rest of the ecosystem.  I'm not sure the 
best way to enforce this operationally but disabling sessions must be an 
operational response.  The reason for the reset is to *cause pain* for the 
poorly behaving devices in question and draw attention to them.  The same 
reason a developer would call abort().

The case of dropping the session is the developer equivalent of abort(), meant 
to alert the users to the problem.  Since not everyone running BGP is a 
protocol expert these days, I almost feel we need strict guidance and 
requirements around the logging we need to report these problems to the vendors.

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

Re: [GROW] WG Adoption Call for: draft-kirkham-private-ip-sp-cores

[Jared Mauch]

Support

- Jared

On Nov 17, 2011, at 2:33 AM, Arturo Servin wrote:

 
   Support.
 
 .as
 
 On 17 Nov 2011, at 15:30, Christopher Morrow wrote:
 
 Folks,
 As mentioned in the WG meeting today, please take the time to
 read/review/think-about the subject draft:
 http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-07
 
 Anthony et-al have done some good work documenting some practices for
 operators, if the work seems to be relevant for this group, let's hear
 that and we'll adopt the document. If, on the other hand, we believe
 this belongs elsewhere, let's provide a pointer set to the authors.
 
 Call for this ends: 12/01/2011 (dec 01 for you not-us-folks)
 
 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

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