Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

From: John Scudder <[email-masked]>
Date: Fri, 6 Nov 2015 09:23:17 +0900

[re-send from correct address]

Hi Bruno,

We believe -05 has addressed these issues, see below.

> On Jun 11, 2014, at 12:40 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> Hi,
>  
> Thanks for the cross WG review. Please find below some proposed comments.
>  
> 1)      For people not following SIDR, could you please elaborate on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 <http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04> has not been used? (via the registration of a new Point of Insertion specific to origin validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

We didn't register a new POI, but did remove the decision process change. It would be possible to register a new POI as part of follow-up work if demand for that exists, but we didn't think it necessary to move forward.
 
> 2)      Could the document specify the action to be taken when multiple “Origin validation state extended” community are present with different validation state? And how are handled validation state value > 2. (from current text, it would not be considered an error, just lower priority. But I would prefer an explicit statement to avoid surprising error handling behavior)

Done. (Drop the community.)
 
> 3)      Rfc 6811 is referenced twice in important sections. What about moving it to “normative reference”?

Done.
 
> 4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 <http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00> I understood that the IDR conclusion was that a non-transitive community may be attached on the outbound policy of an eBGP session; hence may received over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability for a neighboring AS to influence/force the origin validation state is considered acceptable, which would probably need to be discussed in SIDR)

Leaking the community across EBGP is now specified as off by default.

Thanks,

--John

>  
> Thanks,
> Regards,
> Bruno
>  
>  
> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Susan Hares
> Sent: Tuesday, June 10, 2014 4:32 PM
> To: idr wg
> Cc: Murphy, Sandra; 'John G. Scudder'
> Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes
>  
> IDR:
>  
> The SIDR WG has asked for cross review of the draft-ietf-sidr-origin-validation-signaling-04.  This draft changes the RFC 4271 decision process in the following manner:
>  
>  
> If a BGP router supports prefix origin validation and is configured 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>].  The validation step is stated as follows:
>  
>       When comparing a pair of routes for a BGP destination, the route
>       with the lowest "validation state" value is preferred.
>  
> In all other respects, the decision process remains unchanged.
>  
> The draft is at:
>  
> http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04 <http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04>
>  
> John and I would like to hear your comments regarding the RFC 4271 revision.  Please send comments that include “support”  or “no support”.
>  
> Sue and John
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr

---

From: John Scudder <[email-masked]>
Date: Fri, 6 Nov 2015 09:29:59 +0900

Bruno,

> On Jun 11, 2014, at 12:49 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> 5) The text in « deployment consideration » seems a bit weak.
> I would say that: “In deployment scenarios where not all the speakers in an autonomous
>    system are upgraded to support the extensions defined in this  document, in order to avoid routing loops, it is REQUIRED to define policies” …

New text still says "necessary" instead of "REQUIRED". I think this is OK, personally -- in fact the issues are somewhat involved (though neither more nor less than for other routing policy) so the SHOUTING TEXT is maybe a little bit overkill.
 
> 6) For the same purpose, IMO:
> OLD: The default SHOULD be for the validation step to be disabled.
> NEW: The default MUST be for the validation step to be disabled.

Since the decision process change was backed out, I think this is OK now.

--John

>  
> Thanks,
> Regards,
> Bruno
>  
>  
> From: DECRAENE Bruno IMT/OLN 
> Sent: Tuesday, June 10, 2014 5:40 PM
> To: 'Susan Hares'; idr wg
> Subject: RE: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes
>  
> Hi,
>

---

From: John Scudder <[email-masked]>
Date: Fri, 6 Nov 2015 09:29:59 +0900

Bruno,

 

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Nov 2015 09:38:16 +0900

Hi Robert,

I didn't see any specific change requests in your followups to this thread and indeed the changes in -05 are (I believe) consistent with the positions you took, but in any case you might like to take a look at the update.

Thanks,

--John

> On Jun 12, 2014, at 5:06 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Bruno,
> 
> Glad we are in sync ;-)
> 
>> It's a priori not possible to define whether origin-validation shoud have
>> a low or high value compared to another possible existing usage.
> 
> Well I do not think it can be left as such.
> 
> The entire point of adding the new extended community for propagation
> of origin validation result (valid, nf, invalid) is to accomplish
> consistency in IBGP.
> 
> If you leave it open (ie not specified a priori) there is risk of
> different selections of best path in your domain for a given net
> (possibly with different exit points) .
> 
> Frankly since this ext community is non transitive one could also
> depref the routes via local pref .. yes yes I can hear already voices
> .. don't touch it - my local pref is for customers ! Except what this
> draft defines will easily ignore all those customer local preferences
> anyway ... IMO it is all about wisely choosing local pref values.
> 
> Cheers,
> R.
> 
> 
>> On Thu, Jun 12, 2014 at 9:45 AM,  <[email-masked]> wrote:
>> 
>> Hi Robert, all
>> 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert  Raszuk > Sent: Wednesday, June 11, 2014 10:26 PM
>>> 
>>> Hi Bruno & all,
>>> 
>>> Just focusing on Q1:
>>> 
>>>> 1)  For people not following SIDR, could you please elaborate on why
>>>> http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04
>>>> has not been used? (via the registration of a new Point of Insertion
>>>> specific to origin validation) (as I though draft-ietf-idr-
>>>> custom-decision was intended to be the last time BGP decision process
>>>> would be modified)
>>> 
>>> Few observations:
>>> 
>>> A. draft-ietf-sidr-origin-validation-signaling does not really modify a BGP best
>>> path selection .. it adds a check before BGP best path selection algorithm
>>> kicks in.
>> 
>> 
>> "3. Changes to the BGP Decision Process"
>> [...]
>> "When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred."
>> 
>> My reading is that it does change the BGP decision process and the relative priority of the routes.
>> 
>>> B. Adding new POI is not needed as we already have a POI = 128 which is to
>>> be executed before any step in BGP best path selection hence at exactly the
>>> same point as this draft recommends.
>> 
>> Using POI=128 is indeed an option. However in theory there could already be existing usage of POI=128, hence possible conflict. In such case, the sub-field "Community-ID" define the priority. It's a priori not possible to define whether origin-validation shoud have a low or high value compared to another possible existing usage.
>> 
>> 
>>> therefor one obvious question comes in:
>>> 
>>> C. Based on A & B there is clear conflict not addresses in the draft.
>>> Assume both custom decision with POI = 128 "ABSOLUTE_VALUE" as well as
>>> origin validation are enabled. Moreover assume they result in opposite
>>> decisions. So the question of the day is: "Which of those two is the one to
>>> win the pre best path check ?" Effectively - which of those two is more
>>> important ?
>> 
>> You are reading my mind :-).
>> I assumed that the first document becoming RFC freely define its behavior and then the second will need to adapt (i.e. position itself with regard to the first one). However, given that both documents are worked in different WG, there is a risk that this is missed.
>> 
>>> The answer to this question should be included in the draft. And I do suspect
>>> authors of both drafts will answer: mine !
>> 
>> :-)
>> Indeed it's up to the authors/WG, but to me "Absolute" seems above any other criteria.
>> 
>> Thanks,
>> Bruno
>> 
>>> Thx,
>>> R.
>> 
>> [email-masked]
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 14:18:16 +0000

Hi John,

Thanks for taking the time to take my comments into accounts.
-06 address all my comments.

Following the changes, I have some further comments. Please feel free to silently discard/update as you wish.
*) §2  :s/TBD/0x00

*) Following the removal of the change to the BGP Decision Process, the 2 first sentences of the abstract & Introduction could probably be removed or rewritten. (Currently is “As part of the origination AS validation process, it can be desirable
   to automatically consider the validation state of routes in the BGP
   decision process.  The purpose of this document is to provide a
   specification for doing so. »

*) §2 “An implementation SHOULD NOT send more than one instance of the
   origin validation state extended community.  However, if more than
   one instance is received, an implementation MUST disregard all
   instances other than the one with the numerically-greatest value.”

Sorry for nit picking, but since this may impact interoperability, I would prefer if you could explicitly specify what “numerically-greatest value” refers to. IMHO “validationstate” but some people could understand “extended community”

*) §2 For the same reason, explicitly specifying what to do with the Reserved field would ease my mind. (I assume Reserved: MUST be set to 0, and SHOULD be ignored upon receipt)

Thanks,
Bruno

From: John G. Scudder [mailto:[email-masked]]
Sent: Friday, November 06, 2015 1:22 AM
To: DECRAENE Bruno IMT/OLN
Cc: Susan Hares; idr wg; Murphy, Sandra
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi Bruno,

On Jun 11, 2014, at 12:40 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi,

1)      For people not following SIDR, could you please elaborate on why http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 has not been used? (via the registration of a new Point of Insertion specific to origin validation) (as I though draft-ietf-idr-custom-decision was intended to be the last time BGP decision process would be modified)

Done.

4)      Following discussion triggered by http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00 I understood that the IDR conclusion was that a non-transitive community may be attached on the outbound policy of an eBGP session; hence may received over an eBGP session. Given this, IMO the security consideration needs more text. (assuming that the ability for a neighboring AS to influence/force the origin validation state is considered acceptable, which would probably need to be discussed in SIDR)

Thanks,

--John

Thanks,
Regards,
Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, June 10, 2014 4:32 PM
To: idr wg
Cc: Murphy, Sandra; 'John G. Scudder'
Subject: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

IDR:

If a BGP router supports prefix origin validation and is configured 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>].  The validation step is stated as follows:

The draft is at:

http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04

Sue and John

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

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 12 Nov 2015 10:17:09 -0500

Hi Bruno,

Thanks for your additional comments. My responses in-line below.

> On Nov 12, 2015, at 9:18 AM, [email-masked] wrote:
> 
> Hi John,
>  

Thanks, will do.
 
>    specification for doing so. »

Good point. I suggest simply removing the text you've quoted, and slightly rewriting of the remaining, something like:

"This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process."

> Sorry for nit picking, but since this may impact interoperability, I would prefer if you could explicitly specify what “numerically-greatest value” refers to. IMHO “validationstate” but some people…

If we assume (or specify) that the reserved field must be zero, then it's equivalent whether you compare only the lowest two bits or the entire eight bytes, because the top 62 bits are completely determined by the specification. That said, I think you are right, since in the future some use might be made of the reserved field. Seems like we can just add more description to "value", as in "… MUST disregard all instances other than the one with the numerically-greatest validation state value".
 
> *) §2 For the same reason, explicitly specifying what to do with the Reserved field would ease my mind. (I assume Reserved: MUST be set to 0, and SHOULD be ignored upon receipt)

I agree, although I think it MUST be ignored upon receipt – after all, a future specification that assigns semantics to the reserved field can and will also revise the instruction to ignore it. So, I propose we add the paragraph "the Reserved field MUST be sent as zero and MUST be ignored upon receipt" as the final paragraph of section 2.

Regards,

--John

> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>  
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: <[email-masked]>
Date: Thu, 12 Nov 2015 15:48:36 +0000

Hi John,

Thanks, looks good to me.
More inline. [Bruno]

From: John G. Scudder [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 4:17 PM
To: DECRAENE Bruno IMT/OLN
Cc: idr wg; Murphy, Sandra; Susan Hares
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi Bruno,

On Nov 12, 2015, at 9:18 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi John,

Thanks, will do.

"This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process."
[Bruno] looks good to me.

If we assume (or specify) that the reserved field must be zero, then it's equivalent whether you compare only the lowest two bits or the entire eight bytes, because the top 62 bits are completely determined by the specification. That said, I think you are right, since in the future some use might be made of the reserved field.
[Bruno] You are reading my mind.
Seems like we can just add more description to "value", as in "… MUST disregard all instances other than the one with the numerically-greatest validation state value".
 [Bruno] Looks good to me. Thanks.

I agree, although I think it MUST be ignored upon receipt – after all, a future specification that assigns semantics to the reserved field can and will also revise the instruction to ignore it. So, I propose we add the paragraph "the Reserved field MUST be sent as zero and MUST be ignored upon receipt" as the final paragraph of section 2.
 [Bruno] I agree with you. For my defense, I quoted RFC 4760 (my first google hit).

Thanks
Regards,
--Bruno

Regards,

--John

Thanks,
Bruno

Hi Bruno,

Hi,

Done.

Thanks,

--John

Thanks,
Regards,
Bruno

IDR:

The draft is at:

Sue and John

Thank you.

Thank you.

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Thu, 12 Nov 2015 19:19:19 +0000

Hi Bruno,

Posted -07 version that addresses all your recent comments.

https://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-validation-signaling-07.txt

Best Regards,
Keyur

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 12, 2015 at 7:48 AM
To: "John G. Scudder" <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, "Murphy, Sandra" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi John,

Hi Bruno,

Hi John,

Thanks, will do.

"This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence theirdecision process."
[Bruno] looks good to me.

Thanks
Regards,
--Bruno

Regards,

--John

Thanks,
Bruno

Hi Bruno,

Hi,

Done.

Thanks,

--John

Thanks,
Regards,
Bruno

IDR:

The draft is at:

Sue and John

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 13 Nov 2015 07:44:17 +0000

Hi Keyur,

Thanks. All good.

Best regards,
-- Bruno

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 8:19 PM
To: DECRAENE Bruno IMT/OLN; John G. Scudder
Cc: idr wg; Susan Hares; Murphy, Sandra
Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

Hi Bruno,

Best Regards,
Keyur

Hi John,

Hi Bruno,

Hi John,

Thanks, will do.

*) Following the removal of the change to the BGP Decision Process, the 2 first sentences of the abstract & Introduction could probably be removed or rewritten. (Currently is "As part of the origination AS validation process, it can be desirable
   to automatically consider the validation state of routes in the BGP
   decision process.  The purpose of this document is to provide a
   specification for doing so. »

*) §2 "An implementation SHOULD NOT send more than one instance of the
   origin validation state extended community.  However, if more than
   one instance is received, an implementation MUST disregard all
   instances other than the one with the numerically-greatest value."

Sorry for nit picking, but since this may impact interoperability, I would prefer if you could explicitly specify what "numerically-greatest value" refers to. IMHO "validationstate" but some people could understand "extended community"

If we assume (or specify) that the reserved field must be zero, then it's equivalent whether you compare only the lowest two bits or the entire eight bytes, because the top 62 bits are completely determined by the specification. That said, I think you are right, since in the future some use might be made of the reserved field.
[Bruno] You are reading my mind.
Seems like we can just add more description to "value", as in "... MUST disregard all instances other than the one with the numerically-greatest validation state value".
 [Bruno] Looks good to me. Thanks.

I agree, although I think it MUST be ignored upon receipt - after all, a future specification that assigns semantics to the reserved field can and will also revise the instruction to ignore it. So, I propose we add the paragraph "the Reserved field MUST be sent as zero and MUST be ignored upon receipt" as the final paragraph of section 2.
 [Bruno] I agree with you. For my defense, I quoted RFC 4760 (my first google hit).

Thanks
Regards,
--Bruno

Regards,

--John

Thanks,
Bruno

Hi Bruno,

Hi,

2)      Could the document specify the action to be taken when multiple "Origin validation state extended" community are present with different validation state? And how are handled validation state value > 2. (from current text, it would not be considered an error, just lower priority. But I would prefer an explicit statement to avoid surprising error handling behavior)

3)      Rfc 6811 is referenced twice in important sections. What about moving it to "normative reference"?

Done.

Thanks,

--John

Thanks,
Regards,
Bruno

IDR:

The draft is at:

John and I would like to hear your comments regarding the RFC 4271 revision.  Please send comments that include "support"  or "no support".

Sue and John

Thank you.

Thank you.

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Nov 2015 16:45:57 -0500

> https://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-validation-signaling-07.txt

Version -07 looks good to me.

-- Jeff