Subject: Re: [GROW] ietf 97 agenda

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Nov 2016 18:53:47 -0800

howdy grow folks, I uploaded a draft agenda, things will likely change...
here's the data so far:

1 - Admin data / Draft Status                        10 min
2 - Grow-Bgp-reject - job                             5 min
3 - Large-Communities - job                          15 min
4 - opsec-urpf-improvements - sriram                 15 min
5 - Why doesn't IDR know about Ops Requirements?     10 min

happy to accept changes/updates/etc. we have a 1hr slot... my math says
there's 5 min left, though we can re-adjust some as required.

-chris

On Thu, Sep 29, 2016 at 7:15 AM, Peter Schoenmaker <[email-masked]> wrote:

> Hello,
>
>
>
> IETF 97 is fast approaching.  At IETF 96 in Berlin we did not meet.  GROW
> is planning to meet in Seoul if we have agenda items.  People who would
> like time on the agenda please send a request so that a time slot and
> agenda can be prepared.
>
>
>
> thanks
>
>
>
> peter & chris
>
>
>
>
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Nov 2016 18:57:32 -0800

On Fri, Nov 11, 2016 at 6:55 PM, joel jaeggli <[email-masked]> wrote:

> On 11/12/16 11:53 AM, Christopher Morrow wrote:
> > howdy grow folks, I uploaded a draft agenda, things will likely
> > change... here's the data so far:
> >
> interested in this one. especially what we can take away that's
> actionable from the discussion.
>
>
yup, Im not sure, so I'm hoping for some discussion at the meeting :) and
hopefully on-list when we're done.

-chris

---

From: joel jaeggli <[email-masked]>
Date: Sat, 12 Nov 2016 11:55:49 +0900

> On Thu, Sep 29, 2016 at 7:15 AM, Peter Schoenmaker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hello,____
> 
>     __ __
> 
>     IETF 97 is fast approaching.  At IETF 96 in Berlin we did not meet. 
>     GROW is planning to meet in Seoul if we have agenda items.  People
>     who would like time on the agenda please send a request so that a
>     time slot and agenda can be prepared.____
> 
>     __ __
> 
>     thanks____
> 
>     __ __
> 
>     peter & chris____
> 
>     __ __
> 
>     __ __
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/grow>
> 
> 
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 12 Nov 2016 19:14:42 -0500

Chris and Joel: 

Would it be possible to move the Large communities (#3) and Why IDR does not
know about OPS requirements (#5) together?  I will be leaving my other WG
meeting (TRILL) to attend this portion of GROW.  I am very interested to
listen to feedback on large communities and IDR process.  

Thank you 
Sue Hares 
(IDR Co-chair) 

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Friday, November 11, 2016 9:56 PM
To: Christopher Morrow; Peter Schoenmaker
Cc: [email-masked]
Subject: Re: [GROW] ietf 97 agenda

> 5 - Why doesn't IDR know about Ops Requirements?     10 min

interested in this one. especially what we can take away that's actionable
from the discussion.

> happy to accept changes/updates/etc. we have a 1hr slot... my math 
> says there's 5 min left, though we can re-adjust some as required.
> 
> -chris
> 
>

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 12 Nov 2016 17:04:22 -0800

> listen to feedback on large communities and IDR process.
sure, what if we move those to the end of the talk time?

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 12 Nov 2016 17:04:35 -0800

Also, draft agenda updated.

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 12 Nov 2016 21:23:47 -0500

Thanks!  

Sue 

From: Christopher Morrow [mailto:[email-masked]] 
Sent: Saturday, November 12, 2016 8:05 PM
To: Susan Hares
Cc: joel jaeggli; Peter Schoenmaker; [email-masked] [email-masked]
Subject: Re: [GROW] ietf 97 agenda

On Sat, Nov 12, 2016 at 5:04 PM, Christopher Morrow <[email-masked]> wrote:

Chris and Joel:

Thank you
Sue Hares
(IDR Co-chair)

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Nov 2016 21:03:33 -0800

Updated the agenda to slide Sriram's talk to the end, hopefully Susan will
be able to do her meeting start and jump to grow for the relevant parts of
conversation she's interested here :)

On Sat, Nov 12, 2016 at 6:23 PM, Susan Hares <[email-masked]> wrote:

> Thanks!
>
>
>
> Sue
>
>
>
> *From:* Christopher Morrow [mailto:[email-masked]]
> *Sent:* Saturday, November 12, 2016 8:05 PM
> *To:* Susan Hares
> *Cc:* joel jaeggli; Peter Schoenmaker; [email-masked] [email-masked]
>
> *Subject:* Re: [GROW] ietf 97 agenda
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Nov 2016 23:44:46 -0500

> conversation she's interested here :)

FWIW, I'm giving a talk on a topic that grow may find interesting in IDR on 
https://tools.ietf.org/html/draft-haas-idr-extended-experimental-00

At this point, I don't think there's a need to present in grow too but the
document absolutely has routing operations as its motivator.

-- Jeff

---

From: Exa <[email-masked]>
Date: Tue, 15 Nov 2016 07:52:59 +0000

Hello Jeff,

Thank you very much for this document which present ever eloquently one of the issues with the current development process.

It is however not how I would propose to move forward. As a individual developer, I do not have an IANA code and I am not sure I could get one.

Also it changes the way features are coded and would require re-coding once the format is stable and or the code is defined and not simply a code change which is for me unwise and an overkill.

I would rather see a much simpler solution: allocate some code point for development and make them iBGP transitive only, (and give operators an option to bypass this limit on selected eBGP links if they so wish...)

As a developer I do not see myself following the  proposed approach, even if it is a workable solution.

Sincerely,  

Thomas

Sent from my iPad

> On 15 Nov 2016, at 04:44, Jeffrey Haas <[email-masked]> wrote:
>

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 16:59:17 +0900

Hi Thomas,

On Tue, Nov 15, 2016 at 07:52:59AM +0000, Exa wrote:
> Thank you very much for this document which present ever eloquently
> one of the issues with the current development process.
> 
> It is however not how I would propose to move forward. As a individual
> developer, I do not have an IANA code and I am not sure I could get
> one.

It's very simple, just fill in this form: http://pen.iana.org/pen/PenApplication.page
and as "Organization Name: " you can fill in your personal name. I don't
recall whether the PEN number is issued immediately or whether it takes
a few hours.

I have one, on https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
search for 'Job Snijders'

Kind regards,

Job

---

From: John Heasley <[email-masked]>
Date: Tue, 15 Nov 2016 00:00:40 -0800

> It is however not how I would propose to move forward. As a individual developer, I do not have an IANA code and I am not sure I could get one.

Have you tried?

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Nov 2016 19:07:21 -0500

Thomas,

> It is however not how I would propose to move forward. As a individual developer, I do not have an IANA code and I am not sure I could get one.

As mentioned elsewhere in thread, PENs are easy to get hence suggesting that
managed code pode.  I tried to make sure that was clear in the [IANA-PEN]
link, but perhaps there's text I could add to make it more explicit?

> Also it changes the way features are coded and would require re-coding once the format is stable and or the code is defined and not simply a code change which is for me unwise and an overkill.

I have admittedly not taken a look at your implementation.  My expectation
for the bulk of BGP implementations based on my past experience is that the
code associated with parsing or encoding a given path attribute is mostly
separate on a per attribute basis.  There's obviously some shared
infrastructure to code the flags/code point/length of the standard path
attribute.

Since the inner container shouldn't need to move, it's mostly a matter of
abstracting out the contents (the feature data, in the draft) and permitting
them to be parsed or encoded in more than one code point.

Perhaps working through an example may be appropriate.

> I would rather see a much simpler solution: allocate some code point for development and make them iBGP transitive only, (and give operators an option to bypass this limit on selected eBGP links if…

And how would you propose to deal with code point allocation for this?  For
example, we already have 255 available.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Nov 2016 09:40:23 -0500

Thomas,

On Thu, Nov 17, 2016 at 09:40:00AM +0000, Thomas Mangin wrote:
> Thank you for your answer.
> I would be curious to hearing your view on the possible risks the new un-regulated, vendor controlled, space this draft creates as your document is silent about it.

This was commented somewhat further in IDR and also during my code points
presentation in IDR at IETF 97 (suggested reading).

There is somewhat of a need for fully private space.  We're starting to see
this very strongly in data center contexts wherein BGP is used as a
transport and there's significant danger of contamination of fully internal
features leaking into the public Internet.  But as I mentioned in the IDR
thread, this was not my initial motivation for the draft.  It does, however,
serve as a fine starting point for that discussion.

> I can not see why I would want to implement your draft as a step toward implementing another draft (the end goal) which does not require it at all, unless it is intended to be used like like MultiProtocol as a generic extension mechanism and not only a test feature.
> The implementation difficulty is not the barrier: I can perfectly see how I could change the class inheritance of ExaBGP while keeping the attribute interface to implement your draft.
> 
> We need to fix a human problem : laziness, lack of time or information leading to the squatting. 

As noted in my code point presentation, laziness is *not* the issue.  As you
note in your own response, developers need something they can use when TBD
is specified.

> In my view, asking over-worked developers / teams to add some complex code to test new features mean will not lead to a behavioural change.
> All that is required is to give the developer the playground they need to not bother network operation, as the dangers caused by transitive nature of attributes were already fixed with RFC7606. 
> 
> “Public” IANA resource such as IP and ASN have “private” ranges, among other reason, for experimentation.

Private is an excellent example.  If a particular path attribute code space
was marked private, this doesn't stop the issue of collisions.  If your
implementation uses 240 and another uses 240, you'll run into the same
treat-as-withdraw encoding problems we've seen with other forms of
squatting.

Essentially, private doesn't help you.  Neither does a playground.  

The fundamental issue, as noted in the code point presentation, is that BGP
path attributes have a large "blast radius".  It's very difficult to keep
them localized in their current form and thus there's a need to be very
strict about what is used globally.

> I my naive view, every draft could simply cherry pick a code. The numbers of “in-flight documents” is not high, I would expect simple self-policing on list to be enough with a large enough resource pool.
> Should a clash occur, a new draft can quickly fix the issue. Happy to hear if others have better ideas.

Such "cherry picking" is essentially just squatting.  It's also antisocial
in global BGP.  If someone has code deployed in a transit scenario wherein
they're squatting on something that was intended to be globally deployed,
the code point is outright toxic now: you can't safely use it for either
feature.  This is why there's 4 code points going through IANA deprecation
in IDR right now.

Don't make this 5+.

> But if an operator is willing / care enough to use experimental features in his production network and/or with another operator, I am pretty sure they will have the motivation to make sure to do their due diligence to make sure there is no clashes.

They don't have the tools.

> Perhaps the solution would be to required a “disabled until explicitly enabled on iBGP” default behaviour for these attribute codes.

iBGP doesn't make this safe.

> Optional explicit configuration of the feature eBGP session is something I would expect vendors to add due to customer/user demand :-)

I do comment on this even in the experimental context in my draft.  However,
this doesn't work safely in a squatting context.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Nov 2016 10:09:35 -0500

Thomas,

On Mon, Nov 21, 2016 at 02:57:18PM +0000, Thomas Mangin wrote:
> As I am not pushing for an alternate draft,

As mentioned on IDR, part of the reason to issue the draft was to strike up
discussion among implementors.

This is a serious operational problem.

> would you agree that there is no need to test feature on EBGP links and that this attribute should therefore be limited to iBGP to protect the innocents ?

iBGP is no protection.

To give an example, code point 30 was squatted on for a feature that wasn't
enabled on impacted routers.

Large communities, per IANA assignment, tried to utilize it.

Once routes carrying LCs hit those routers as transit nodes, the routes were
treated as withdraw due to being "malformed" per RFC 7606.

Some features only make sense in eBGP contexts and we need to similarly make
some accommodation for development work there as well.

-- Jeff

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 15 Nov 2016 09:42:32 +0000

> Have you tried?

Thank you John and Job. A long time ago I got one (not personal). 
19092 Exa Networks Ltd
I could not recall it was allowed for individuals. Thank you for correcting my misunderstanding.

Still my point stands:

The problem is that developers do not know what code they can use for experimentation when they see TBD in a draft. 
The proposed document does not prevent anyone to continue squatting and polluting the DFZ with unknown attributes when implementing new drafts.

It does ask developers to go through a convoluted way to re-encode attributes to experiment and them fully re-code the feature when it needs to go to production.
Thank you but no thank you: as a developer, I just want to know that I can use some attribute code safely.

AS operators will know what code is run on their kit, and can make sure that there is no conflict of experimental features.
(And it would be trivial for WG chairs to make sure drafts do use different codes).

Also this draft may introduce a new number of new challenges:
Once we have IANA defined sub-attributes, we may also see vendors “matching” some other vendors experimental feature - which IMHO would be unadvisable. What then ?
What need will vendors then have to standardise their own namespace ?

Just reserving a range such (let say 200-254) for experimentation and making them non eBGP transitive would match what is already done with Private ASN, preventing their propagation is MUCH simpler, and let people experiment as they want.

(see included patch which would implement such draft/RFC)

Thomas

—
diff --git a/lib/exabgp/bgp/message/update/attribute/attributes.py b/lib/exabgp/bgp/message/update/attribute/attributes.py
index cedd82b..0745117 100644
--- a/lib/exabgp/bgp/message/update/attribute/attributes.py
+++ b/lib/exabgp/bgp/message/update/attribute/attributes.py
@@ -227,6 +227,8 @@ class Attributes (dict):
               alls = set(keys + default.keys() if with_default else [])

               for code in sorted(alls):
+                       if code in range(200,255) and local_asn != peer_asn:
+                               continue
                       if code in (
                               Attribute.CODE.INTERNAL_SPLIT,
                               Attribute.CODE.INTERNAL_WATCHDOG,

---

From: Thomas Mangin <[email-masked]>
Date: Thu, 17 Nov 2016 09:40:00 +0000

Hello Jeff,

> link, but perhaps there's text I could add to make it more explicit?

It can not harm. I was clearly ill-informed.

> I have admittedly not taken a look at your implementation […]

“Public” IANA resource such as IP and ASN have “private” ranges, among other reason, for experimentation.
I can not se any harm to extend this principle more widely to help, not the operators this time, but the developers.

> example, we already have 255 available.

A simple code is not enough, but a range would allow multiple features developed in parallel (in one code base), while also allowing possible cross vendor interoperability testing.
TBD is a terrible word to read in a draft when you are trying to implement it. TDB is not a valid integer value, and 255 as a single available value is not enough, so it is not used.
The wording in draft need to contain the information developers needs to implement the draft as they understand it.

Sincerely,

Thomas

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 21 Nov 2016 14:57:18 +0000

Jeff,

As I am not pushing for an alternate draft, would you agree that there is no need to test feature on EBGP links and that this attribute should therefore be limited to iBGP to protect the innocents ?
EBGP testing should be done using the right final encoding using the proper attribute code.

Sincerely,

Thomas

> On 21 Nov 2016, at 14:40, Jeffrey Haas <[email-masked]> wrote:
> 
> Thomas,
>