Re: [GROW] Working Group Adoption Call: draft-cptb-grow-bmp-yang (Ends 15/Sep/2022)

[Ben Maddison]

Hi all,

On 08/25, Job Snijders wrote:
> Hi GROW,
> 
> At the IETF 114 GROW session Paolo asked whether this working group
> could consider adoption for draft-cptb-grow-bmp-yang.

I support adoption.

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] Any credence to AS_SET in the *middle* between AS_SEQUENCEs?

[Ben Maddison]

Hi Alexander,

I think that SHOULD is strong enough to justify the behaviour as part of aspa 
validation.

Certainly the side effect wrt AS_SETs should be called out in operational 
considerations.

Cheers,

Ben

From: GROW  on behalf of Alexander Azimov 

Sent: Tuesday, July 26, 2022 9:14:36 AM
To: Sriram, Kotikalapudi (Fed) 
Cc: sidr...@ietf.org ; 
draft-ietf-sidrops-aspa-verificat...@ietf.org 
; GROW WG 
Subject: Re: [GROW] [Sidrops] Any credence to AS_SET in the *middle* between 
AS_SEQUENCEs?

Hi all,

The current version of the draft follows the wording from 
draft-ietf-idr-deprecate-as-set-confed-set


   BGP speakers conforming to this document (i.e., conformant BGP
   speakers) MUST NOT locally generate BGP UPDATE messages containing
   AS_SET or AS_CONFED_SET.  Conformant BGP speakers SHOULD NOT send BGP
   UPDATE messages containing AS_SET or AS_CONFED_SET.  Upon receipt of
   such messages, conformant BGP speakers SHOULD use the "Treat-as-
   withdraw" error handling behavior as per 
[RFC7606].


As you can see, it uses 'SHOULD'. And this was the reason to have an additional 
'Unverifiable' state, because the 'Invalid' routes MUST be rejected.

If the WG agrees to change normalative language from 'SHOULD' to 'MUST', the 
ASPA document will follow.


вс, 24 июл. 2022 г. в 11:53, Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>:
I think we can conclude that the outcome of the discussions in this thread is 
to make the following change in ASPA-based AS path verification:

If an AS_PATH has one or more AS_SETs in any position, mark it as Invalid.

At least four (perhaps all five) of us who participated in the discussion 
support this change.

Thanks.

Sriram


--
Best regards,
Alexander Azimov
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [WG ADOPTION] draft-spaghetti-grow-nrtm-v4 - ENDS: 05/11/2022 (May 11, 2022)

[Ben Maddison]

Hi all,

On 04/27, Christopher Morrow wrote:
> Howdy WG Folks!
> Please take this note as the start of a WorkingGroup Adoption call for the
> subject draft, who's Abstract is contained here:
>   "This document specifies a one-way synchronization protocol for
>Internet Routing Registry (IRR) records.  The protocol allows
>instances of IRR database servers to mirror IRR records, specified in
>in the Routing Policy Specification Language (RPSL), between each
>other."
> 
> Please have a read over the document, determine if this is applicable to
> the GROW space and reply with your thoughts (votes of yay/nay/meh?).
> 
I support adoption.
A properly specified NRTM is wy overdue: thanks to Sasha for getting
this moving.

RPSL and its kin seem to be orphaned in the IETF at the moment.
If it's not too late in the process, perhaps it is worth considering an
addition to the new charter, along the lines of:

"Provide stewardship and maintenance for the Routing Policy
Specification Language (RPSL) and related protocols."

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] IXP Route Server question

[Ben Maddison]

Hi Sriram,

On 03/10, Nick Hilliard wrote:
> Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31:
[...]
> > The ASPA verification draft treats the relationship of RS to
> > RS-client as similar to that of Provider to Customer. Seems
> > reasonable? The AS of an RS client includes the RS's AS in its ASPA
> > as a "Provider".
> 
> yes, this is reasonable.
> 
Essential, I would think: how could a far end relying party know that an
AS in the middle of a received AS_PATH is a non-transparent IXP RS in
order to apply any other treatment?

A special mark in the ASPA itself perhaps, but yuk ;-)

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] IXP Route Server question

[Ben Maddison]

On 03/08, Christopher Morrow wrote:
> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed)
>  wrote:
> 
> > This question has relevance to the ASPA method for route leak detection.
> >
> > Is it possible that an ISP AS A peers with a customer AS C via a
> > non-transparent IXP AS B?
> > IOW, the AS path in routes propagated by the ISP A for customer C's
> > prefixes looks like this:  A B C.
> > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in the
> > middle between an ISP and its customer?
> >
> >
> it seems unlikely to me that an ISP would pick up a 'customer' (someone
> that pays them to transport packets) at an IXP fabric.
> Might it happen? sure? is it messy? yes!
> 
I know of several transit providers that will allow customers to use an
IXP as a kind of virtual access circuit (which itself is a poor idea),
but I would be *very* surprised if any of them allow RS peerings to be
the control plane interconnection (intentionally, at least).

If the underlying question is "should the ASPA path validation algorithm
have a corner case that accommodates this?", that is a very, very firm
"no" from me!

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Ben Maddison]

Hi Paolo,

On 12/08, Paolo Lucente wrote:
> 
> Hi Ben,
> 
> Thank you for your review, very much appreciated. I will merge your PR on
> GitHub asap. With regards to the other two points:
> 
> 1) This came through a suggestion back then from Jeff Haas that i support as
> it made sense to me, see here his comment on this list:
> 
> ==
> While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
> code point.".
> 
> Many implementations that deal with TLV based protocols will canonicalize
> data structures based on the TLVs using sorted structures.  Having them
> sorted on the wire means the canonicalization step is cheaper.
> 
> Note that this is a general justification for the procedure and it's not
> critical for something like BMP.
> ==
> 
That makes sense, thanks.
Having never written a routine that does this, I am slightly surprised
that it is still cheaper, even if the implementation cannot *require* that
it will arrive sorted - but I am more than happy to take yours and Jeff's
word for it!

> 2) That is right & suggestion accapted. I will make it further explicit.
> 
Ack. Thanks.

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Ben Maddison]

Hi all,

On 12/02, Job Snijders wrote:
> Hi Folks,
> 
> Please take 15 minutes out of your day to review this *really short!*
> internet-draft. The authors were kind enough to make it only 3 pages of
> actual content :-)
> 
I have read the draft, and agree with others that it is a straight
forward solution to a genuine problem.

I have a couple of questions/comments:

1.  I don't understand the purpose of the SHOULD in:

TLVs SHOULD be sorted by their code point. Multiple TLVs of the
same type can be repeated as part of the same message, and it is
left to the specific use-cases whether all, any, the first or
the last TLV should be considered. 

A receiver clearly cannot optimise for receiving the TLVs sorted,
since it isn't a MUST. Beyond this, why is it useful?

2.  In the types defined in section 4.2, I read "value MUST be boolean"
as meaning "length MUST be 1 and value MUST be either 0x00 or 0x01".

Is that correct? If so, perhaps it is better to be explicit?

3.  I had a variety of grammatical/editorial suggestions. Rather than
gum-up the list with these, I have opened a pull-request at:
https://github.com/paololucente/draft-ietf-grow-bmp-tlv/pull/2

I hope that makes review more convenient for the authors.

Cheers,

Ben


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Ben Maddison]

Hi all,

On 07/29, Christopher Morrow wrote:
> Howdy WG Folks!
> There's been significant chatter on-list about:
>   draft-mcbride-grow-as-path-prepend-01
> 
> Abstract:
>   "AS_Path prepending provides a tool to manipulate the BGP AS_Path
>attribute through prepending multiple entries of an AS.  AS_Path
>prepend is used to deprioritize a route or alternate path.  By
>prepending the local ASN multiple times, ASes can make advertised AS
>paths appear artificially longer.  Excessive AS_Path prepending has
>caused routing issues in the internet.  This document provides
>guidance,to the internet community, with how best to utilize AS_Path
>prepend in order to avoid negatively affecting the internet."
> 
> This work seems directly in the GROW wheelhouse, and it appears folk
> on-list agree. Let's decide with a WG Adoption call for this document
> and see if we should continue this work officially/etc.
> 
Agreed. I support adoption.

Cheers,

Ben

> Please give it a read, and comment on adoption ideals here-in.
> 
> thanks!
> -chris
> co-chair-persona
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11

[Ben Maddison]

Hi all,

On 10 Oct 2017 5:50 pm, Jay Borkenhagen  wrote:
Job Snijders writes:
 > > The LOCAL_PREF choice here is a simple thing -- don't make it more
 > > complicated than it needs to be.
 > >
 > > Job's suggested text says all that's necessary:
 > >
 > > "The LOCAL_PREF value SHOULD be lower than any of the alternative
 > > paths.  Zero being the lowest value, it MAY be used whichever
 > > LOCAL_PREF values are used by the AS."
 >
 > The above comes from Bruno's hand, I actually proposed the following:
 >
 > "The LOCAL_PREF value SHOULD be lower than any of the
 > alternative paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF
 > value."
 >
 > Kind regards,
 >
 > Job


Sorry for my mis-citing / mis-quoting.  Let me try my hand:

 The LOCAL_PREF value SHOULD be lower than any of the alternative
 paths.  The RECOMMENDED value is 0.

That formulation gets my vote. If operators have a good reason to deviate from 
the recommendation, they will know that without it being pointed out in the 
document.



Thanks.

Jay B.

Cheers,

Ben



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

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

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

[Ben Maddison]

Hi all,

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

Cheers,

Ben

--
Sent from Hiri


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

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

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

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


i also support publication.

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

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

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

[Ben Maddison]

 CLI. More visibility is particularly
helpful in this case.

Cheers,

Ben

> > Draft can possibly discuss both options, at the cost of additional
> > reading complexity. But this possibly could be discussed in a
> > different section.
> > 
> > I'd welcome more opinion, before choosing the main text.
> 
> Bruno, perhaps my interpretation of the above sentence's phrasing is
> somewhat mangled because neither of us are a native speaker, but keep
> in
> mind this is a GROW working group document. :-)
> 
> Kind regards,
> 
> Job
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
-- 
Ben Maddison

Director
Workonline Communications (Pty) Ltd
 
Office: +27 (0) 21 200 9000
Mobile: +27 (0) 82 415 5545
Email:  b...@workonline.co.za
SIP:b...@workonline.co.za
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Ben Maddison]

Hi Robert,

If we all agree community approach is the best for signalling to peer that this 
prefix should be avoided why folks just do not do it today already ? Why do we 
need IETF draft for that :) ?

If this is about publishing a communities which include "warning" to peers "Hey 
I am bringing this prefix down soon .. "(maybe even with parameter how soon 
:))) what stopping Orange to declare we will attach YZ:MN community and 
re-advertise routes when we are to take down the session.

That way any peer of Orange may use it at their own discretion.

[BEN] Nothing is stopping them. The primary benefit is the use of a well-known 
community that can be matched in generically constructed policies without prior 
knowledge of whether the peer makes use of this procedure, and what community 
they use for the purpose if they do.

- - -

The idea behind putting single message in NOTIFICATION was just to automate it 
and make it deterministic. When you send community some peers may converge 
quicker some much slower. You never know when your peer is done.

Here only after his best path and rib insertion of new paths around you is 
complete he would tear the session. Some timeout would be defined as well. And 
it will apply to all AFI/SAFIs as well as current and future BGP messages send 
over given session.

[BEN] From a quick read of RFC4271:

“A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after it is sent.”

I can’t find any updates that contradict that.
If I understand your suggestion correctly, you mean:

1.the peer initiating the shutdown (A) sends its peer (B) a NOTIFICATION 
with a new error code that means “I’m going away shortly, please start 
re-converging and let me know when you’re done”.

2.B attempts to re-converge around the paths learnt from A (possibly 
needing to initiate a route-refresh in the process?), and once it no longer has 
any of those routes in its FIB sends A back a further NOTIFICATION saying “I’m 
finished” and then shuts the session down.

3.If A hasn’t heard back within a configurable timeout, then it yanks the 
session anyway.

If so, that sounds like a hell of a lot of new protocol spec and router code, 
to solve a fairly marginal issue. The determinism that you gain only goes one 
hop into the remote network (as B’s other peers may still be converging when 
the session goes down), and is therefore only guaranteed to be useful if that 
network tunnels between ASBRs.
It is also unclear what a BGP speaker that didn’t understand the new code would 
do when receiving a NOTIFICATION that wasn’t immediately followed by a session 
reset. I suspect that would vary widely by implementation and be the source of 
some fairly nasty bugs!
Compared to a line in an RFC suggesting reasonable timer values between gshut 
and shutdown, this seems to be a lot more work for very little benefit.

Cheers,
Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office: +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:  b...@workonline.co.za<mailto:b...@workonline.co.za>
SIP:  b...@workonline.co.za<sip:b...@workonline.co.za>

[Workonline Communications]<http://www.workonline.co.za/>

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, March 17, 2017 1:30 PM
To: Ben Maddison <b...@workonline.co.za>
Cc: bruno.decra...@orange.com; grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?

Hi Ben & Bruno,

If we all agree community approach is the best for signalling to peer that this 
prefix should be avoided why folks just do not do it today already ? Why do we 
need IETF draft for that :) ?

If this is about publishing a communities which include "warning" to peers "Hey 
I am bringing this prefix down soon .. "(maybe even with parameter how soon 
:))) what stopping Orange to declare we will attach YZ:MN community and 
re-advertise routes when we are to take down the session.

That way any peer of Orange may use it at their own discretion.

- - -

The idea behind putting single message in NOTIFICATION was just to automate it 
and make it deterministic. When you send community some peers may converge 
quicker some much slower. You never know when your peer is done.

Here only after his best path and rib insertion of new paths around you is 
complete he would tear the session. Some timeout would be defined as well. And 
it will apply to all AFI/SAFIs as well as current and future BGP messages send 
over given session.

Best,
R.


On Fri, Mar 17, 2017 at 12:14 PM, Ben Maddison 
<b...@workonline.co.za<mailto:b...@workonline.co.za>> wrote:
Hi Robert,

There is no requirement that peers implement anything at all. In the absence of 
any configured policy, the community gets ignored, and no action is taken prior 
to shutdown – which is exactly the status-quo without the dr

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

[Ben Maddison]

Hi Robert,

There is no requirement that peers implement anything at all. In the absence of 
any configured policy, the community gets ignored, and no action is taken prior 
to shutdown – which is exactly the status-quo without the draft, so no harm 
done. Each network is free to implement whatever ingress policy is sensible in 
their own view, which should be to take the same action as when receiving an 
IXP list mail saying “we’re gonna shut x,y,z down shortly…”. The difference is 
they can now handle that in BGP policy to avoid the manual NOC activity.

Also, there is no additional code required (assuming support for 1997) in order 
to implement the bare bones of the functionality – e.g. match on 65535:0, set 
local-pref.
The automation features around it (such as neighbor shutdown graceful on XE) 
need new software, but are also trivial to recreate in an in house EMS if 
people are that pathological about touching their routers.

The only problem scenario that I can see is where someone is using 65535:0 for 
a different purpose in eBGP. But some people are beyond help!

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office: +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:  b...@workonline.co.za<mailto:b...@workonline.co.za>
SIP:  b...@workonline.co.za<sip:b...@workonline.co.za>

[Workonline Communications]<http://www.workonline.co.za/>

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, March 17, 2017 12:39 PM
To: bruno.decra...@orange.com
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?

Hi Bruno,

[Bruno] The goal was to be able to use gshut even if both EBGP peer are not 
enhanced to support it. The benefit of flagging routes with a community is that 
gshut may be implemented on vanilla routers using a BGP route map/policy.

​Sure thing. However peers need to be consistently configured with ​the same 
policy to understand the meaning of the community.

If you think this is easy - great.

Incremental deployment in a benefit, in particular between AS/organisations, 
and in particular on small/low end routers which are not replaced every 4 years.

​Well it is not router replacement .. it is software upgrade. But sure ​if you 
can convince peers to setup same error free policy that is perfect. No 
objections at all :).

​Best,
R.​

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

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

[Ben Maddison]

I would be very happy with that outcome.
We've been using this for ages, and would like to see it work more widely in 
our adjacent networks.

Although not truly a fix for the transitivity problem, when we match on gshut 
from a peer, in addition to setting a lower-than-usual LP, we also append 
no-export, which prevents gshut-ed prefixes from leaking at all.
I've never been hugely worried about the security consequences otherwise.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office: +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:  b...@workonline.co.za
SIP:  b...@workonline.co.za




-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Wednesday, March 15, 2017 4:54 PM
To: bruno.decra...@orange.com
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?

Hi Bruno,

On Wed, Mar 15, 2017 at 02:00:37PM +, bruno.decra...@orange.com wrote:
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders  
> > > Sent: Wednesday, March 15, 2017 2:11 PM
> >
> > I noticed that 
> > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
> > expired two years ago. Can anyone offer some insight why it lapsed?
> 
> In order to signal the graceful shutdown over the EBGP session, gshut 
> uses a "well-know" BGP community. Compared to using a protocol 
> extension, this allows a vanillia sender/receiver to handle the 
> information using a regular BGP policy.
> So far so good. This is specified, implemented both with BGP policy 
> and automated by some routers, tested (both options).
> 
> Now, for some deployments, the use of a non-transitive community offer 
> a better assurance that the community has indeed be originated by the 
> connected eBGP peer. The issue is that currently there is no 
> implementation of non-transitive well-known communities.
> draft-ietf-idr-reserved-extended-communities is a short draft to 
> define non-transitive well-known communities. It proposed to re-use an 
> "existing" non-transitive extended community, defined for four-octets
> AS: draft-ietf-idr-as4octet-extcomm-generic-subtype. But it turns out 
> that this latter draft did not progress and has recently been replaced 
> by BGP large community. The later do no support non-transitive 
> community.
> 
> So after waiting for some years for
> draft-ietf-idr-as4octet-extcomm-generic-subtype, this path has just 
> been closed. As of today, the possible options seems:
> 
> - forget about non-transitive community. In particular as during the 
> BGP large community discussions, the requirement for non-transitive 
> community has been discussed and explicitly called as not needed. So 
> let's listen to this and do the same.

I'd like to add a small nuance: For the use case of large communities, 
non-transitivity was considered an undesirable property. 

To be honest, if the 'gshut' community 'escapes' the adjacent ASN for which it 
was intended, what is the worst that can happen? That BGP speakers somewhere in 
the DFZ consider the path less desirable? This aligns with what is expected to 
happen in the near future anyway: the bgp session will be torn down and the 
path will cease to exist.

In the case where no shutdown event follows (the gshut community is used as a 
traffic engineering trick), it kind of goes in the same category as intermediat 
networks prepending ASNs to the AS_PATH to make it less desirable, or fiddling 
with origin. If I were to consider "permanent use" of the gshut community a 
violation of my agreement with the adjacent network, this would be easy enough 
to monitor for and subsequently resolve at layer-8.

> - have draft-ietf-idr-reserved-extended-communities use a different 
> extended community type. This is easy to write, but if this does not 
> get implemented, the value is limited/null.

I concur. A similar consideration could be made whether gshut deserves its own 
path attribute or not.  Usually the nice thing about well known rfc 1997 
communities is their rapid implementation and deployability.

> > What implementatations exist? A fellow operator told me that IOS, 
> > IOS XE has support for graceful shutdown, are there others?
>  
> Same information on my side.  With the restriction that those 
> implementations only implement the transitive community.

ack.

I'm somewhat inclined to proceed with the gshut concept as a well-known 
transitive rfc 1997 community. What do others think?

Kind regards,

Job

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

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