Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 5 May 2014 16:05:57 +0000

Randy,

because the goal of this draft can already be reached simply through use
of existing means, i do not support publication.  i am not strongly
opposed.  it's just one more bit of ietf work that is not obviously
needed.

Here are the three reasons that may refresh our mind on why after 4 years this draft is still important to move forward to the IESG:

1) Scope beyond BGP communities:  This document creates an IANA registry for the "BGP origin validation state". This makes the document the standard for the encoding of this state (valid/invalid/not found). We are already used it as reference for the IPFIX Information Element 294 (for which we went through all the process with the IPFIX policy to get it registered here:  http://www.iana.org/assignments/ipfix/ipfix.xhtml). There are other use cases that I can think of where this registry will be required (MRT exports as one top of my mind)

2) Documenting change on BGP decision process changes: Section 3. Basically the origin validation happens before any other policy applied. This goes beyond the iBGP community but even for stand-alone routers. In this sense, you can implement RPKI in a device without modifying any existing policy description.

3) Documentation of non-standard BGP communities: Over the years, we have seen a number of attempts to document and standardise providers communities with less than great results. One particularly use case (that I suffered) is when you have to merge two networks due to an acquisition, standardised communities are very helpful.

And lets not forget: Running Code: Last but not least…the draft has been delayed more than what it should and several implementations (including two from Cisco) has running code + documentation + training. As we are pushing to improve adoption of RPKI, I rather spend time adding the missing pieces that removing what is not broken…although the need may not be obvious for everyone.

Roque

randy

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 5 May 2014 16:10:03 +0000

Sandra,

I support this document moving forward to the IESG.

I read the document as part of the WGLC process and I believe the text is ready for publication.

My only question is a formality from Section 3 that says:

" If a BGP router supports prefix origin validation and is configure for the extensions defined in this document, the validation step SHOULD be performed prior to any of the steps defined in the decision process of [RFC4271<http://tools.ietf.org/html/rfc4271>]."

(Roque) Should this document specifically be labeled as an update to RFC4271?

Regards,
Roque

On Apr 26, 2014, at 1:53 AM, Sandra Murphy <[email-masked]<mailto:[email-masked]>> wrote:

The authors of BGP Prefix Origin Validation State Extended Community, draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC.

This message begins a two week WGLC, to end on 9 May 2014.

The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling.

Please do send comments to the list, indicating whether you do or do not believe that the draft is ready for publication.

--Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Mon, 05 May 2014 19:03:46 +0200

> This document creates an IANA registry for the "BGP origin validation
> state".

which is highly inappropriate, as the three and only three states are
cast in stone.  this should be removed if we're going to progress the
document.

> 2) Documenting change on BGP decision process changes: Section 3.
> Basically the origin validation happens before any other policy
> applied. This goes beyond the iBGP community but even for stand-alone
> routers. In this sense, you can implement RPKI in a device without
> modifying any existing policy description.

and this was codified in rfc 6811.  now you get to compare the two,
because any inconsistency would be bad.

> 3) Documentation of non-standard BGP communities: Over the years, we
> have seen a number of attempts to document and standardise providers
> communities with less than great results. One particularly use case
> (that I suffered) is when you have to merge two networks due to an
> acquisition, standardised communities are very helpful.

last para of rfc 7115 sec 5

   Validity state signaling SHOULD NOT be accepted from a neighbor AS.
   The validity state of a received announcement has only local scope
   due to issues such as scope of trust, RPKI synchrony, and management
   of local trust anchors [LTA-USE].

> And lets not forget: Running Code: Last but not least…the draft has
> been delayed more than what it should and several implementations
> (including two from Cisco) has running code + documentation +
> training. As we are pushing to improve adoption of RPKI, I rather
> spend time adding the missing pieces that removing what is not
> broken…although the need may not be obvious for everyone.

actually, code removal is not an evil, quite the opposite.

but, as i said

> i do not support publication.  i am not strongly opposed.  it's just
> one more bit of ietf work that is not obviously needed.

randy

---

From: heasley <[email-masked]>
Date: Mon, 5 May 2014 18:57:50 +0000

Mon, May 05, 2014 at 07:03:46PM +0200, Randy Bush:
> > And lets not forget: Running Code: Last but not least???the draft has
> > broken???although the need may not be obvious for everyone.
> 

esp. when 1 company has 2 (two, zwei, dos!) implementations.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 14:42:57 -0400

On Mon, May 5, 2014 at 12:10 PM, Roque Gagliano (rogaglia)
<[email-masked]> wrote:
> " If a BGP router supports prefix origin validation and is configure for the
> extensions defined in this document, the validation step SHOULD be performed
> prior to any of the steps defined in the decision process of [RFC4271]."
>

doesn't a prefix-list (or other route-filter) happen prior to the
decision process as well though?

>
> Regards,
> Roque
>
> On Apr 26, 2014, at 1:53 AM, Sandra Murphy <[email-masked]> wrote:
>
> The authors of BGP Prefix Origin Validation State Extended Community,
> draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC.
>
> The draft is available at
> http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling.
>
> Please do send comments to the list, indicating whether you do or do not
> believe that the draft is ready for publication.
>
> [email-masked]
> [email-masked]