Subject: [Idr] Warren Kumari's No Objection on draft-ietf-idr-bgp-prefix-sid-25: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Jun 2018 17:30:27 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting NoObjection, but I'm sad that nothing came of my previous request:

"Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
  "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
  (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
  order to prevent distribution of the BGP Prefix-SID attribute beyond
  its intended scope of applicability, attribute filtering SHOULD be
  deployed."
Thank you for including this -- however, as I'm sure you know, the state of BGP
filtering in the wild is, er, poor. Can you please provide some additional
guidance? For example, could you include an appendix with examples? Or simply a
bit more text on determining the scope of applicability? Apologies if I missed
this, but should this by default be filtered on eBGP sessions? The included
text is a great start, but some more (so people don't miss it and shoot
themselves in the foot would be much appreciated. "

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 19 Jun 2018 14:33:10 +0000

Hi Warren, 

> On Jun 18, 2018, at 8:30 PM, Warren Kumari <[email-masked]> wrote:
> 
> guidance? For example, could you include an appendix with examples?

No. As I told you before this is a can of worms that I’m not going to open in this draft (and particularly not during IESG review). As I also told you before the state of BGP filtering is something that you should propose as a work item for your OPS homies in the GROW WG. 

> Or simply a
> themselves in the foot would be much appreciated. “

I will add “, e.g., at SR domain boundaries,’  to the statement. 

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jun 2018 17:01:01 +0200

Hi Acee,

Just making the attribute non transitive to prevent accidental leaking
worldwide would easliy address this valid concern for the cost of upgrading
RRs (if applicable) in any given domain which is to use it.

Leaking it with IPv6 routes globally - either by accident or not so perfect
operational practices of the sourcing AS  seems like an a little
architecture bug since such info would be of no use externally to original
administrative domain.

Best,
R.

On Tue, Jun 19, 2018 at 4:33 PM, Acee Lindem (acee) <
acee=[email-masked]> wrote:

> No. As I told you before this is a can of worms that I’m not going to open
> in this draft (and particularly not during IESG review). As I also told you
> before the state of BGP filtering is something that you should propose as a
> work item for your OPS homies in the GROW WG.
>
>
> > Or simply a
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Jun 2018 15:07:49 -0400

> RRs (if applicable) in any given domain which is to use it.

​That sounds like a fine idea -- was this discussed and rejected? Is there
any reason that this cannot be non-transitive?

W

>
> Leaking it with IPv6 routes globally - either by accident or not so
> perfect operational practices of the sourcing AS  seems like an a little
> architecture bug since such info would be of no use externally to
> original administrative domain.
>
> Best,
> R.
>
>
>> > Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> No. As I told you before this is a can of worms that I’m not going to
>> open in this draft (and particularly not during IESG review). As I also
>> told you before the state of BGP filtering is something that you should
>> propose as a work item for your OPS homies in the GROW WG.
>>
>>
>> > Or simply a

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Jun 2018 22:06:45 +0200

Hi Warren,

I don't think this was discussed. But what I proposed was applicable to the
situation where the new attribute would be advertised with SAFI 1
specifically IPv6 global unicast. Apparently when replying I was looking at
older version of the draft where this was still proposed.

The new version of the draft *only* permits to advertise this attribute
with SAFI 4 (IPv4/IPv6 labeled unicast) so there is no more concern that
this will leak beyond the intended scope as this SAFI is of quite limited
scope by design.

So I guess there is no longer a concern with the -25 version of the draft.

Thx,
R.

On Wed, Jun 20, 2018 at 9:07 PM, Warren Kumari <[email-masked]> wrote:

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jun 2018 13:21:43 -0700

>> Just making the attribute non transitive to prevent accidental
>> leaking worldwide would easliy address this valid concern for the
>> cost of upgrading RRs (if applicable) in any given domain which is to
>> use it.
> 
> ​That sounds like a fine idea -- was this discussed and rejected? Is
> there any reason that this cannot be non-transitive?

+1  how can a miss a chance to agree with robert?  :)

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 20 Jun 2018 19:34:59 -0500

> work item for your OPS homies in the GROW WG.

BTW - these “OPS homies” would love to see more RFC 8212 implementations!
:-)

Kind regards,

Job

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 21 Jun 2018 02:27:37 +0000

BTW - these “OPS homies” would love to see more RFC 8212 implementations! :-)

Indeed, somehow I didn’t even have to look this RFC up ;^) I still think that a vendor-neutral draft on filtering use cases would be a worthwhile GROW endeavor.

Thanks,
Acee

Kind regards,

Job