Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 12:40:19 -0400

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy.
You can find the draft at: 

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

In your comments on adopting this draft, please indicate: 

1)      "Support" or "no Support" 

2)      Do you feel this is a way to prevent route leaks? 

3)      Are there any deployment issues that might prevent deployment of
this enhancement to BGP Open? 

4)      Does this interact with
draft-ietf-idr-route-leak-detection-mitigation? 

Sue Hares and John Scudder

---

From: "Osborne, Eric" <[email-masked]>
Date: Mon, 6 Jun 2016 17:00:43 +0000

1)      I support solving the problem this draft set out, and this draft seems to be a good start at wrestling with the problem.

2)      This works better on a white board than in real life.  In particular, terms like Peer and Customer and Transit have commercial connotations as well as technical ones.  It may be that some operators have a Providers (fiscal relationship) but with which they exchange routes as if it were a Peer.  Or Customer/Peer, or Customer/Provider.  I am a little concerned about translating the strict rules in this doc into a more nuanced BGP policy which reflects business policy.  I encourage anyone who implements this to not just make it a "Role must match or I'm going to tear the neighbor down" sort of thing.

3)      See #2

4)      I just briefly skimmed detection-mitigation, and that seems like a much more heavyweight way to implmement the same sort of end behavior.

eric

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, June 06, 2016 12:40 PM
To: [email-masked]
Cc: [email-masked]; 'John G. Scudder' <[email-masked]>
Subject: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy. You can find the draft at:
https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.

3)      Are there any deployment issues that might prevent deployment of this enhancement to BGP Open?

4)      Does this interact with draft-ietf-idr-route-leak-detection-mitigation?

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2016 12:02:16 -0700

this wg seems to have the strange convention of co-authors speaking for
draft adoption, advancement, ...  so i support this draft for adoption,
though it is a bit embarrassing to do so.

randy

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 15:09:01 -0400

Randy,   Eugene,   Alexander:

Would you please indicate whether you know of IPR on
draft-ymbk-idr-bgp-open-policy?  I forgot to add this to the WG adoption
call. 

Sue Hares 

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Monday, June 06, 2016 3:02 PM
To: Susan Hares
Cc: [email-masked]; [email-masked];
'John G. Scudder'
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to
6/20/2016)

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2016 12:16:17 -0700

> draft-ymbk-idr-bgp-open-policy?

i am not aware of ipr on this draft

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 7 Jun 2016 22:08:43 +0000

I do not support WG adoption of the draft in its current form.

I have read the draft.

This draft has two parts: (1) modification of BGP Open to include BGP role,

and (2) a proposal for route leak detection/mitigation/prevention.

I would encourage the first part to be written as a separate draft in itself.

This effort may have broader utility besides assisting with

route leaks solution. Route leak detection-mitigation draft can (should)

refer to the BGP open policy draft, and should

say how the BGP role info can be utilized in the solution.

The above mentioned second part seems to be a compromised subset of

the proposal in the existing WG draft [ietf-idr-route-leak-detection-mitigation].

The bgp-open-policy draft proposes a single OTC flag per update

(as opposed to one flag per AS-hop).

This lacks efficacy as explained with examples in Section 5.5 of

[ietf-idr-route-leak-detection-mitigation] and also in ref [1] noted below.

In contrast, [ietf-idr-route-leak-detection-mitigation] proposes

an RLP flag per AS-hop, which is shown to work well

(i.e. more robust in the presence of errors and partial deployment)

for route leak detection (see Section 5.5 for details).

The IDR and SIDR WGs have discussed the solution mechanisms

over the past three or more years. The exiting WG draft factors in

those discussions and feedback, and also documents the discussions

in detail in Section 5 (design rationale). The bgp-open-policy draft

seems to overlook one key design principle as noted above.

Also, the bgp-open-policy draft mixes up detection and mitigation

into one combined algorithm.

(Mitigation belongs largely in the operator policy space.)

In contrast, [ietf-idr-route-leak-detection-mitigation] describes

the RLP encoding and detection separately.

It leaves the mitigation method entirely to the operator,

while providing only an example of a mitigation policy.

The operator uses the detection algorithm as a tool to

inform their own policy when it comes to mitigation.

Further, the existing WG draft offers a description of a common practice

(followed by major ISPs) for an intra-AS route tagging (see Section 3.2).

This mechanism conveys from ingress to egress routers the peering info

necessary to prevent route leaks that are under control of the AS locally.

Sriram

[1] see slides 5-9 of https://www.ietf.org/proceedings/95/slides/slides-95-idr-13.pdf

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 7 Jun 2016 23:14:06 +0000

Eric,

>4) I just briefly skimmed detection-mitigation, and that seems like a

>much more heavyweight way to implement the same sort of end behavior.

On what basis?

The OTC flag (one for the whole update) in the bgp-open-policy draft

has in essence the same semantics as the RLP flag (one per AS-hop).

In both cases, by setting the flag the sender is indicating that

the route is being sent to a customer or a lateral peer, and hence

SHOULD NOT be sent by the receiving AS or another AS down the path

to its provider or lateral peer.

So hard to say that one proposal is more heavy weight

than the other in principle.

Also, please see the point made in my other post about the inefficacy

of a single OTC flag for the whole update (as proposed in bgp-open-policy):

http://www.ietf.org/mail-archive/web/idr/current/msg15745.html

You may also see a detailed discussion in Section 5.5 of

https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03

Sriram

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 8 Jun 2016 16:02:03 +0000

On the basis that detection-mitigation adds an attribute to every route (potentially per AS hop), whereas bgp-open keeps it to the neighbor relationship.  One attribute per route * 600k routes * N hops seems like a lot if I can do the same thing with an open message.  I'm also concerned about how much I should trust the RLP bit from an AS a few hops away.  Getting it from my directly connected neighbor is one thing, but if I can trust the source to do the right thing with the RLP bit, why can't I just assume they won't leak YouTube-ish things to begin with?  It feels a little like "...you SHOULD not rob this bank, but if you're going to rob the bank you MUST NOT wear a mask".  At least with my directly connected neighbor I have some understanding of what the policy should be, and a phone number I can call if things are super-hosed.

I didn't see a discussion of scale anywhere in detection-mitigation.  This seems like such an obvious scale difference to me that I worry that "hard to say that one proposal is more heavy weight than the other in principle" means I'm missing something.  Feel free to enlighten me as needed.

eric

From: Sriram, Kotikalapudi (Fed) [mailto:[email-masked]]
Sent: Tuesday, June 07, 2016 7:14 PM
To: Osborne, Eric <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: [email-masked]; 'John G. Scudder' <[email-masked]>
Subject: RE: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Eric,

On what basis?

Sriram

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 9 Jun 2016 16:55:28 +0300

Copy of my yesterday's email, just in case, if it was not delivered:

Dear Sriram,

Thank you for your input, but I think most of your concerns come out of
confusion. Let me clarify them one by one. My comments are included in text
below

2016-06-08 1:08 GMT+03:00 Sriram, Kotikalapudi (Fed) <
[email-masked]>:
 The above mentioned second part seems to be a compromised subset of

> the proposal in the existing WG draft
> [ietf-idr-route-leak-detection-mitigation].
>
RLP, as its proposed could not be used on “per update basis”. But OTC, with
use of proposed roles, does not share these limitations. This is an excerpt
from [ietf-idr-route-leak-detection-mitigation] draft section 5.5:

        +-----+         +-----+  peer to peer (p2p) relation +-----+
     p--| AS1 |-------->| AS2 |----------------------------->| AS3 |
        +-----+         +-----+            Update -->        +-----+

                                Method B: {p [AS2 AS1] RLP=1}

In our proposal, AS2 would set OTC flag only if AS3 is not supporting
roles, and this can easily be retrieved from OPEN message. So the problem
is not with per-update basis approach, but with RLP attribute itself. I'd
like to mention, that well designed per-update attribute has one more
obvious advantage: fixed size.

> inform their own policy when it comes to mitigation.
When dealing with route leaks it’s important to solve the problem. Not just
detect it. What do you think is easier - to prevent leaking or to track
down route leak and stop it propagation? I think there is no real choice -
create or not to create route leak, likewise it is now with community
usage. That is why our draft, with help of roles, proposes full automation
for both leak prevention inside AS and leak detection for leaks that are
made by third parties. I believe it could provide complex approach to solve
the problem.

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 9 Jun 2016 17:00:32 +0300

Dear Susan,

As far as I understand your question, there is IPR on this draft.

2016-06-06 22:09 GMT+03:00 Susan Hares <[email-masked]>:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Jun 2016 10:23:36 -0400

Alexander: 

Thank you for letting us know there is IPR on this draft. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Alexander Azimov
Sent: Thursday, June 09, 2016 10:01 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; John G. Scudder
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Dear Susan,

Sue Hares

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Monday, June 06, 2016 3:02 PM
To: Susan Hares
Cc: [email-masked]; [email-masked];
'John G. Scudder'

randy

 

-- 

| tel.: +7 499 241 81 92

| mob.: +7 915 360 08 86

| skype: mitradir

| mailto: [email-masked]

| visit: www.qrator.net <http://www.qrator.net/>

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 9 Jun 2016 17:29:46 +0300

Ow, wow, NO IPR. Sorry.

2016-06-09 17:23 GMT+03:00 Susan Hares <[email-masked]>:

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Alexander Azimov
> *Sent:* Thursday, June 09, 2016 10:01 AM
>
> *To:* Susan Hares
> *Cc:* [email-masked];
> [email-masked]; John G. Scudder
> *Subject:* Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy -
> (6/6 to 6/20/2016)
>
>
>
> Dear Susan,
>
>
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jun 2016 09:04:04 -0700

> Ow, wow, NO IPR. Sorry.

whew!

---

From: Job Snijders <[email-masked]>
Date: Thu, 9 Jun 2016 18:32:25 +0200

Dear Authors, IDR group, 

I'd like to start by thanking you for putting thought and time into the
route leak problem space. It is encouring to see fellow operators engage
with the IETF community to address actual, day to day issues.

> 1)      "Support" or "no Support" 

No support.

> 2)      Do you feel this is a way to prevent route leaks? 

It certainly is a way.

> of this enhancement to BGP Open? 

I do not think that the OPEN moment in the lifecycle of a BGP session is
the appropiate place for policy constructs like this. In practise it is
probably not an issue when you have to flap a BGP session to change the
relation between two ASNs, but it would be nice if this is not required
(like today on most platforms).

Secondly (and more importantly), the roles are not necessarily a BGP
session-specific characteristic, but rather a prefix-specific property.
The proposed OPEN method does not provide for this level granularity if
I am reading it correctly. The method would affect all prefixes exchange
over a BGP session, without exception.

> draft-ietf-idr-route-leak-detection-mitigation? 

Yes, in terms of the problem being addressed.

Kind regards,

Job

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 9 Jun 2016 20:15:43 +0300

Dear Job,

Thank you for joining discussion!

I can't imagine situation when there would be changes in roles between two
neighbors on regular basis. So, we should not suffer from lots of BGP flaps
caused by roles.

In second point you've highlighted most common concern about different
prefix-based route policies in same BGP session. There are at least two
workarounds:

   1. Add 'custom' role and give in such sessions access to manual OTC
   configuration (there would be new appropriate pair of roles custom-custom)
   2. Split such BGP sessions into two with different roles

For myself I do prefer second option - I would like to see route leak
mitigation as built in and fully automated mechanism, with no opportunity
for 'fat fingers' get inside. This could bring additional work for NOC
teams in short term, but in long term benefit from controlling neighbor
configuration (especially in case of new ISPs) will fully cover the spent
time. But what do you think according to your operational experience?

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 9 Jun 2016 17:27:52 +0000

I don’t like #2.  It doesn’t make sense to me – a single neighbor may have some customer aspects and some peer aspects, and splitting a single BGP session into two is conceptually weird and also a huge code uplift on both ends.

#1 makes sense and is along the lines of what I was hinting at in my ‘support’ – don’t just give me pass/fail, give me flexible knobs in an implementation.  I realize that doing this per-prefix is anothet way to do it, but see my other email to Sriram for why I don’t like path state much.

I suppose I could see non-transitive per-prefix as another way to do this; if it was that vs open message, there are good arguments either way.

eric

From: Idr [mailto:[email-masked]] On Behalf Of Alexander Azimov
Sent: Thursday, June 09, 2016 1:16 PM
To: Job Snijders <[email-masked]>
Cc: [email-masked]; [email-masked]; John G. Scudder <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

Dear Job,

I can't imagine situation when there would be changes in roles between two neighbors on regular basis. So, we should not suffer from lots of BGP flaps caused by roles.

In second point you've highlighted most common concern about different prefix-based route policies in same BGP session. There are at least two workarounds:

  1.  Add 'custom' role and give in such sessions access to manual OTC configuration (there would be new appropriate pair of roles custom-custom)
  2.  Split such BGP sessions into two with different roles
For myself I do prefer second option - I would like to see route leak mitigation as built in and fully automated mechanism, with no opportunity for 'fat fingers' get inside. This could bring additional work for NOC teams in short term, but in long term benefit from controlling neighbor configuration (especially in case of new ISPs) will fully cover the spent time. But what do you think according to your operational experience?

2016-06-09 19:32 GMT+03:00 Job Snijders <[email-masked]<mailto:[email-masked]>>:
Dear Authors, IDR group,

No support.

It certainly is a way.

Kind regards,

Job

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jun 2016 12:37:10 -0700

> session-specific characteristic, but rather a prefix-specific
> property.  The proposed OPEN method does not provide for this level
> granularity if I am reading it correctly. The method would affect all
> prefixes exchange over a BGP session, without exception.

i can not be sure, as you lack example.  but the example i commonly use
is when A gives B local peering and also sells B global transit.  today,
this is two separate sessions.  do you use another approach; not can
think of, but actualy use?

are there other real-world examples?  just trying to understand.

randy

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 9 Jun 2016 19:47:06 +0000

Hi Folks,

Comments inlined #Keyur

>> 2)      Do you feel this is a way to prevent route leaks?

#Keyur: I am not sure if the solution attempts to cover all cases: Open
policy assumes certain peering relationship can be established between BGP
speakers and based on the relationship, the OTC handling is done. This
information is restricted and doesn¹t flow along the path the route is
announced. You do want to carry this information so any AS down the path
can make an independent decision?

>the appropiate place for policy constructs like this.

#Keyur: +1. I completely agree. Furthermore, the draft isn¹t clear about
changing of session level roles (either using dynamic capabilities or upon
a session restart) and its impact on depref/dropped routes and existing
functionality like GR (route based).

> In practise it is

#Keyur: Ack and agree.

Regards,
Keyur

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Jun 2016 13:09:53 -0700

I am not 100% certain, and don't speak for them, but I believe Hurricane
Electric (HE) often has peers who use them for both IPv4 peering and IPv6
transit; I don't know, but would guess that at least some of those are over
a single MP-BGP session.

Brian

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 10 Jun 2016 10:12:53 +0200

Dear WG,

Susan Hares wrote on 06/06/16 18:40:
> This begins a 2 week WG Adoption call for
> draft-ymbk-idr-bgp-open-policy. You can find the draft at:
> 
> 1)      “Support” or “no Support”
>

No Support.

I think proposed enhancements to the BGP Open message in signalling the
relationship could be a useful property that should be explored further.
For instance, in cases where a single policy (e.g. peer-peer) can be
applied to the BGP session, this method can be used for automating
setting of the RLP field. I suggest that this amendment is documented in
a separate draft, which I'll support for the WG adoption.

> 2)      Do you feel this is a way to prevent route leaks?

In some cases.

> this enhancement to BGP Open?

Variation of routing policy on per prefix basis.

> draft-ietf-idr-route-leak-detection-mitigation?

The proposed OTC flag is similar to the RLP field, but the semantics is
different. I suggest that the considerations for the OTC flag
(especially a single flag vs per-hop) are discussed in the framework of
the the draft-ietf-idr-route-leak-detection-mitigation and a best way is
chosen by the WG, rather than having 2 parallel threads of incompatible
solutions.

Full disclosure - I am one of the co-authors of
draft-ietf-idr-route-leak-detection-mitigation

Andrei

---

From: Job Snijders <[email-masked]>
Date: Fri, 10 Jun 2016 11:43:24 +0200

Hi Randy,

On Thu, Jun 09, 2016 at 12:37:10PM -0700, Randy Bush wrote:
> is when A gives B local peering and also sells B global transit.
> today, this is two separate sessions. do you use another approach; not
> can think of, but actualy use?

Yes, using two separate sesssions to deliver the two separate products
is a common (and valid) approach. 

> are there other real-world examples?  just trying to understand.

I won't share the company names involved, but on multiple occasions, my
employer has engaged in providing transit between two peering partners.
This was either done unilaterally (when my employer has a desire to keep
the internet together), or part of a bilateral commerical agreement. In
other words I cannot assume the BGP peer will cooperate with its role
assignment.

In all those cases, under the "OPEN" approach, we'd flag all involved
parties as 'peer', and the peer would have assigned us the role 'peer'
too, except that they weren't in some specific contexts.

There are at least two use-cases:

    - some prefixes are 'peering', others are 'transit': this has
      happened for instance when redistributing root-server prefixes
      that were behind a peer to other peers.
    - all prefixes are peering, except they should be redistributed to
      peer X too (can be decided unilaterally or bilaterally).

Reflecting on the two examples, the common theme is that if you are a
stub network (e.g. one does NOT provide IP Transit using BGP to your
customers) the "OPEN"-approach may be a reasonable approach, but for a
transit network the approach feels too restrictive.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2016 13:56:59 +0200

Responding to #3 how authors envision deployment via IX where I peer single
session to RS while on the other side I may have various types of peers ?

I do not think BGP OPEN MSG is the right place for this.

Thx
R.
On Jun 6, 2016 12:40, "Susan Hares" <[email-masked]> wrote:

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jun 2016 05:30:33 -0700

> I won't share the company names involved, but on multiple occasions,
> my employer has engaged in providing transit between two peering
> partners.

actually, the first time your company did this, publicly documented on
nanog, was when asp and i patched the war between psi and abovenet.  i
like that record because it allows me to do as you are trying, to say
that there are more things in heaven and earth, Horatio.

but, bottom line, what you are saying is that, if you used this feature
at he same time you were intentionally violating the no transit between
peers policy, it would flag it as an error.  this is a feature, not a
bug; it is what it is *supposed* to do.

if you want to violate valley free or no transit between peers, you
probably do not want to enable this capability.

randy

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 10 Jun 2016 18:23:57 +0300

Dear Robert,

Thank you for comment.

In spite of your concerns RS is a perfect place to deploy roles: RS does
not provide IP-transit (if there are no leaks!) but it *provides* local
connectivity. So, RS is provider for all its neighbors.

2016-06-10 14:56 GMT+03:00 Robert Raszuk <[email-masked]>:

> Responding to #3 how authors envision deployment via IX where I peer
> single session to RS while on the other side I may have various types of
> peers ?
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Jun 2016 17:35:28 +0200

You mean other then FT's OpenTransit ?

http://vision.opentransit.net/docs/peering_policy/

Well in general you are correct that in IX transit peering is established
over direct EBGP sessions, however there is more and more exceptions and
while RS policies get richer over single session various types of customers
get connected.

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 10 Jun 2016 18:33:25 +0200

On 2016-06-06 18:40, Susan Hares wrote:

Dear members,

> 1)      "Support" or "no Support"

I do not support this draft

> 2)      Do you feel this is a way to prevent route leaks?

Only in a perfect world.

> 3)      Are there any deployment issues that might prevent deployment

This approach is too strict and can't cope with the different peering 
relationships that exist in the real world.
(In other words: you can't bound your sales to these specs)

> of this enhancement to BGP Open?
> 

Partly.
They try to address the same problem in very different ways.

> Sue Hares and John Scudder

Regards

-- 
Marco

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 10 Jun 2016 20:10:57 +0000

>On the basis that detection-mitigation adds an attribute to 
>every route (potentially per AS hop), whereas bgp-open 
>keeps it to the neighbor relationship.  
>One attribute per route * 600k routes * N hops seems like a lot 
>if I can do the same thing with an open message.  

Perhaps you have realized by now (based on the discussion on the list) 
that the bgp-open draft also adds one OTC flag per route (or prefix).
(Yep, on the wire there is one flag per route in the bgp-open draft also.)

The SIDR, IDR, and GROW WGs have been working on it for 
the past four years or so. See this post from 2012:
https://www.ietf.org/mail-archive/web/sidr/current/msg04263.html  
which summarized some of the requirements/design principles that were 
discussed at the time in the WG meetings. Note that in particular it says:
"the relationship has to be per prefix not per link, as prefixes with
    different business models are often sent over the same link."

Several people in this thread also have tried to convey the above 
design principle (i.e. RLP flag per route). Also see the discussion 
in Section 5.3 of [route-leak-detection-mitigation].   

>I'm also concerned about how much I should trust the RLP bit 
>from an AS a few hops away.  Getting it from my directly connected 
>neighbor is one thing, but if I can trust the source to do the right thing 
>with the RLP bit, why can't I just assume they won't leak 
>YouTube-ish things to begin with?

It is not the source, but the AS that is two hops from you
-- it is important to know what they asserted in the update.
(Keyur also highlighted this earlier in this thread.)
Let us say AS X is a multi-homed customer of AS A and AS B:
AS A ---> AS X ---> AS B   (path of the update propagation)
(assume that RLP flag per AS-hop is in use)
AS X receives a route from its provider AS A, 
and accidentally leaks it to provider AS B.
AS X is not participating in RLP (does not set its own RLP flag),
but it passes on the RLP flag set by of AS A to AS B because
the RLP attribute is transitive. Then AS B is able to detect the leak...
because AS B knows that the AS two hops away (AS A) asserted that
it is sending the update to a customer (or a lateral peer) by
setting its (i.e. AS A's) own RLP = 1.

So there is need to know the RLP flag value set by the ASes 
before your immediate neighbor. Your immediate neighbor (AS X) is 
the leaker (the offender) -- in this instance. 
So you do not want to rely on their RLP flag as much 
(for detection of route leaks). 
Also, you have knowledge about your peering relationship with them.  

Down the road, the intention is to secure the RLP attribute so that
no AS can change the RLP flag set by another AS in the path.
In the above example, if AS X were maliciously trying to leak the
route by changing the RLP flag of AS A, then it (AS X) would be prevented
from doing so if there is cryptographic protection of the RLP attribute
(e.g. by using the BGPsec protocol path signatures; see Section 3.1.2). 

The end goal of this effort has been to provide 
*secure* route leak protection (progressing via IDR-->SIDR).
(I.e. provide a solution for both accidental and malicious route leaks.)
Then it becomes necessary that each AS must set its RLP attribute 
individually (RLP per AS-hop) and be secured.

>I didn't see a discussion of scale anywhere in detection-mitigation.  
>This seems like such an obvious scale difference to me that I worry that 
>"hard to say that one proposal is more heavy weight than 
>the other in principle" means I'm missing something.  
>Feel free to enlighten me as needed.

The BGP RLP attribute is sown in Section 3.1.1 of 
[route-leak-detection-mitigation]. It consists of {ASN, RLP flag} tuples. 
The parsing/processing load associated with the BGP RLP attribute 
is not much different from processing the AS_PATH attribute.
May be it is simpler than the AS_PATH processing where you have to 
take into account the prepends, AS_SETs, CONFED_SETs, loop detection etc.
If you want to consider another per-AS-hop thing to compare with ....
We have done and reported elsewhere about BGPsec validation processing 
which involves verifying one path signature per prefix and per AS-hop. 
That has been implemented and does not seem daunting.
Just some preliminary thoughts trying to address your concerns.

Sriram

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jun 2016 18:29:22 -0700

> transit; I don't know, but would guess that at least some of those are over

in actual fact, they are not.  confirmed by HE.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jun 2016 19:04:57 -0700

> You mean other then FT's OpenTransit ?

welcome to the kinky internet, where every thinkable and unthinkable act
is done; after all, it was invented in california. :)

if you are planning something kinky, do not bring a straight friend to
the party.  that is, as i said to job, if you intend to violate valley
free or peer-peer, do not run mechanisms designed to detect these as
errors.

perhaps we should design for the norm.  with things this complex, we can
always find corner cases.  though i guess one can make a career out of
finding them; it's a target rich environment.  true skill is in finding
the simple middle path.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Jun 2016 04:30:11 +0200

I must admit that you are right to say that true skill is in finding some
way to help address the problem for vast majority of deployments.

I also agree that while best protocol design skills are in addressing
corner cases here no loop will form and no harm to routing would be done if
say 5% disable that capability.

However my honest observation is that this approach would work well when
operators would only operate on binary BGP code with such functionality
enabled as mandatory capability and be always ON by default with no option
to disable it.   Said this we all have to admit that such times are long
gone and as soon as NOC have a business case and chance to disable it their
marketing folks will force them to do so.

So the real question comes to the point if IDR is in position to issue RFCs
to test ISP marketing guys in their level of power to enforce big vendors
to add knobs disabling such capabilities or speeding up shifting to open
source BGP ....

Tx,
r.

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jun 2016 21:56:23 -0700

> However my honest observation is that this approach would work well
> when operators would only operate on binary BGP code with such
> functionality enabled as mandatory capability and be always ON by
> default with no option to disable it.  Said this we all have to admit
> that such times are long gone and as soon as NOC have a business case
> and chance to disable it their marketing folks will force them to do
> so.
> 
> So the real question comes to the point if IDR is in position to issue
> RFCs to test ISP marketing guys in their level of power to enforce big
> vendors to add knobs disabling such capabilities or speeding up
> shifting to open source BGP ....

complex twisty path which starts and ends in unhelpful places.

i am not interested in a vendor nanny state, never have been.  see the
very careful and complete operator control in RFC 6811 BGP Prefix Origin
Validation.

if i know i have a 'normal' relationship with a bgp neighbor, give me to
tools to mark it as such and to detect and maybe even ameliorate damage
by [untentional (i am an optimist)] violation of that normality.

if i do not have a normal relationship, i won't use protective tools
which assume and enforce normality.

life can be simple.

randy

---

From: heasley <[email-masked]>
Date: Sat, 11 Jun 2016 05:37:23 +0000

> marketing folks will force them to do so.

I suspect that any given NOC/operator does not want to be featured on BBC
news for having broken Internet access to popular destinations.  So,
perhaps most would be less likely to skinny dip.

I'm not convinced of the idea, but I would suggest that the draft should
mandate that it be possible to disable the capability by configuration.

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jun 2016 22:42:21 -0700

> mandate that it be possible to disable the capability by configuration.

clearly.  my bad.  i thought it was implied by 'capability' as opposed
to a mandatory change to open.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Jun 2016 03:47:39 -0700

> to a mandatory change to open.

someone privately commented that maybe the negotiation could always be
on, but there should be a relationship "it's complex"' or whatever.

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 17 Jun 2016 17:06:44 +0000

Alexander,

Sorry for the delay in my response.

>In our proposal, AS2 would set OTC flag only if AS3 is not supporting roles,
>and this can easily be retrieved from OPEN message.
>So the problem is not with per-update basis approach,
-- snip --

In the SIDR/IDR/GROW WGs, the design choice of per-update vs. per-hop
was discussed at least since 2012. I tried to explain the rationale for
per-hop RLP attribute in my response to Eric with a simple example:
http://www.ietf.org/mail-archive/web/idr/current/msg15775.html

>When dealing with route leaks it’s important to solve the problem. Not just detect it.
-- snip --

[route-leak-detection-mitigation] does not ignore prevention/mitigation of route leaks.
Section 3.2 deals with intra-AS messaging for route leak prevention.
And the approach recommended there is based on the common practice approach
of major ISPs (please see the recent NANOG thread on this topic).
Also, Section 3.4 is about “Possible Actions at a Receiving Router for Mitigation.”
I was only making the well appreciated point that, the solution should put
more emphasis on prevention and detection, but the mitigation (following detection)
needs to allow *operator preferences* for how to handle externally (eBGP) learned routes
that are detected and marked as route leak.

Sriram