Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

From: Alexander Azimov <[email-masked]>
Date: Thu, 1 Jun 2017 19:07:23 +0300

Hi Bruno!

Thank you for your feedback! My comments are bellow.

> Possible comments:
>
> - possibly, there could be additional usage/value if the iOTC attribute
> were carrying the role within the AS, rather than being only a flag. For
> example it could be used in routing policies (as a read-only-memory) e.g.
> to set the preference of routes. Indeed, my understanding is that this info
> is double checked hence more reliable than a BGP community that the
> receiver could set with no additional checks. So a priori a better source
> of info for a routing policy
>
I do agree that roles can have other usages, and, for example, default
LOCAL_PREF value may be set according to set role. Still, I do not see use
case, when iOTC itself can provide additional support for routing policies.
IMO - we should keep iOTC as simple as possible.

> - a priori, as per current text, the iOTC attribute seems advertised over
> EBGP session and not removed on the reception side. I'm not sure whether
> this is a design goal or a bug.
>
iOTC is not intended to be sent via Peer/Provider/Customer connections. We
will clarify it in text. Thanks!

> - Possibly, the "Strict mode" could be the only one/the mandated behavior.
> To allow for backward compatibility, the non-compliant peer could tag
> routes with "well-known" BGP communities, to be defined by this document,
> and indicating the role (on a per route basis).
>
> 'Strict mode' by default seems to me too radical. It will result in
problems at state of partial deployment, when after software update BGP
session will not get up back. Also, please keep in mind, that roles are
negotiated via OPEN messages, before any communities can be exchanged.

---

From: "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." <[email-masked]>
Date: Fri, 02 Jun 2017 20:06:17 +0200

> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy
  > (5/20 to 6/3/2017) 
I strongly support adoption,
and consider it a worthy candidate for the being progressed quickly.

we are putting it in our list of requests for vendors product developement
roadmaps

Ruediger Volk

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 2 Jun 2017 20:41:05 +0000

I see a BGP role of transit provider, but not one for transit customer. Those tend to be different than edge or enterprise customers. Their usually connected to a border aka peering router(s) not an edge, although both can and do happen. The complex role may work for that as it allows for nearly any type of role.
But many of us have borders (peering only maybe with transit customers), and edges (enterprise maybe some transit customers).

Those that restrict transit customers to just one of those types or routers would be able to have a simpler set of edge or border wide policies for enterprise, or peering only routers.
We may also have the case where a transit customer pays for what transits our network but doesn't pay for what lands on our network.

I have probably just made the case for your complex role.

Next and this is just a NIT.
I think this:
BGP Internal Only To Customer attribute
The Internal Only To Customer (iOTC) attribute is a new optional,
 non-transitive BGP Path attribute with the Type Code <TBD3>.

Should be this:
BGP Internal Only to Customer attribute
The Internal Only to Customer (IOtC) attribute is a new optional,
 non-transitive BGP Path attribute with the Type Code <TBD3>.

But could argue IOC (dropping the to altogether from it making it a TLA).
I could also argue for IOTC. But the small i... seems wrong.

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]

From: Idr [[email-masked]] on behalf of Ruediger Volk, Deutsche Telekom Technik - FMED-41.. [[email-masked]]
Sent: Friday, June 02, 2017 12:06 PM
To: Susan Hares
Cc: 'idr wg'; [email-masked]
Subject: Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

Ruediger Volk

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Job Snijders <[email-masked]>
Date: Sun, 04 Jun 2017 11:59:47 +0000

On Fri, 2 Jun 2017 at 20:06, Ruediger Volk, Deutsche Telekom Technik -

> and consider it a worthy candidate for the being progressed quickly.

Unfortunately, as it's currently specified, I still cannot see my
affiliation deploying this technology in a meaningful way.

The word "peer" is extremely overloaded: it is a homonym which conflates
all kinds of concepts. The term appears in too many training courses to be
redefined to one specific meaning. On top of that, I all too often see that
provisioning- or customer engineers don't have clear insight as to who is
customer and who the supplier is. Even worse: a customer may assume the
supplier role as part of a larger deal. While in the hallways we easily
talk about simplified models on how the internet works, actually enforcing
that simplification in the context of EBGP to me is undesirable.

Any technology that is supposed to mitigate route leaks, should be
deployable both by the "big" carriers as well as stub network at the edge
and anything in between. If we end up with carriers flagging all relations
as "complex" or not even enabling the capability to enjoy backwards
compatible behavior, that would be no good.

Perhaps if the draft would focus on merely two classifications: "stub" and
"transit" networks, where the former would be an affirmation that neither
party expects the "stub" network to transit prefixes for any other ASN, and
transit networks would enjoy the same behavior as any ASN today, that would
give a different twist to this idea. Downside is that one needs to bounce
the session to become a transit provider.

Or perhaps we should look for other options: I'm interested in technology
that both myself and my customers can deploy. Preferably relationship
agnostic, and with per prefix granularity. Any proposal that avoids
explicit coordination between the two entities has a strong preference
compared to requiring agreement to which number we dial up a knob.

 I'm somewhat torn between adopting this document as a working group
document, to use it as a springboard to other ideas and hopefully end up
with something more deployable before WGLC; and opposing it and simply
encourage further research on what can be done (or should not be done) in
"OPEN" protocol space.

Secondly: the use of a path attribute vs well-known communities is still an
ongoing dilemma for me. Previously I've elaborated on some pros and cons
from my perspective. I'm not convinced the approach as chosen by this
specification is beneficial as it doesn't easily accommodate incremental
deployment within an autonomous system.

Kind regards,

Job

---

From: David Monosov <[email-masked]>
Date: Sun, 4 Jun 2017 18:28:17 +0200

On 6/4/17 1:59 PM, Job Snijders wrote:
> 
> On Fri, 2 Jun 2017 at 20:06, Ruediger Volk, Deutsche Telekom Technik - FMED-41..
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Unfortunately, as it's currently specified, I still cannot see my affiliation
> deploying this technology in a meaningful way. 

Concur. Despite a laudable goal, in its current form this technology would
significantly constrain the flexibility afforded by community based policies,
which are widely deployed.

Attempting to "codify" the nature of relationships between autonomous systems
into 4 broad categories is an oversimplification that has limited overlap with
operational reality (as demonstrated by increasingly broad and expressive
selection of policy communities implemented by sophisticated networks).

Having to firmly constrain the nature of each relationship in advance, on a
session level rather than prefix level, requires the operators to make a choice
between two less than ideal alternatives:

- Correctly select a conservative definition of their current relationship,
reducing the operational agility if the nature changes in the future - as now
both operators must agree in advance and implement a change in the definition of
this relationship, flapping the session, prior to modifying policy.

- Err on the side of caution and tag all sessions as "complex" to maintain that
agility, eliminating the benefit of this technology.

Regardless of the alternative initially chosen, it seems plausible that an
autonomous system with an evolving set of roles and interconnects will find
itself over time drifting toward ever more of them marked "complex" as its
policy sophistication requirements evolve.

Perhaps a better direction for this initiative, in lieu of BGP extension, would
be toward a BCP outlining a checklist for defining the nature of each
relationship as part of the on-boarding process for new interconnects - and
providing some policy implementation examples for various cases.

--
Sincerely yours,

David Monosov

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Mon, 5 Jun 2017 14:29:57 +0000

Support.

Regards,

Gaurav

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Saturday, May 20, 2017 at 2:33 AM
To: 'idr wg' <[email-masked]>
Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017)

The authors should indicate if they know of any IPR related to this document.  You can find the document at:

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

Sue Hares

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Jun 2017 21:28:52 +0530

Support WG adoption.

Thanks
-Pushpasis

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 9 Jun 2017 23:57:53 +0300

Dear colleagues,

Thank you for your feedback!

I agree with Job, that every new technology should be suitable for both
"big" carriers and smaller ISPs. And in field of route leaks it is even
more crucial. The work on this draft is in process, and IMO, the current
version of draft is not ready for WGLC. I hope, that if this draft is
adopted, it will result in more comments, more feedback and will speed up
the process.

At the same time I disagree with proposal of movement toward BCP. BGP
already have all one need to prevent network from leaking routes. Still the
problem is here and it becomes even worse. Here are few noteble examples of
route leaks that took place during May:

   1. Route leak by Rostelekom (AS12389), the biggest ISP in Russia, more
   then 1k prefixes leaked from HKIX to NTT;
   2. Rote leak by Incapsula (AS19551), DDoS mitigation provider, more then
   1.5k prefixes in multiple directions;
   3. Route leak by Onlanta Ltd (AS56631), small stub ISP which leaked more
   then 50k prefixes between its providers.

While first two anomalies were short lived and affected only network
latency, the last one lasted more then two hours and resulted in channel
exhaustion and partial DoS for a number of networks. Please, correctly
understand me, this is not wall of blame, this is wall of BGP problem
itself. And a significant change in protocol design is required to avoid
existence of such mistakes.

PS: There was a comprehensive comparison between communities and path
attributes usages by Brian Dickson. While iOTC MUST not be propagated
outside ISP border, eOTC/RLP MUST not be dropped by some AS in the path.
For me it seems that in both scenarios path attributes are more preferable.

2017-06-04 19:28 GMT+03:00 David Monosov <[email-masked]>:

> FMED-41..
> affiliation

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net