Hi Keyur, Many thanks for the answers. Comments inline #Bruno Adding sidr in copy
From: Keyur Patel (keyupate) [mailto:keyup...@cisco.com] Sent: Thursday, June 12, 2014 6:52 PM To: DECRAENE Bruno IMT/OLN; Susan Hares; idr wg Cc: 'John G. Scudder'; Murphy, Sandra Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes Hi Bruno, Thanks for the draft review. Comments inlined #Keyur From: <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Date: Tue, 10 Jun 2014 15:40:05 +0000 To: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>, idr wg <i...@ietf.org<mailto:i...@ietf.org>> Cc: "'John G. Scudder'" <j...@bgp.nu<mailto:j...@bgp.nu>>, "Murphy, Sandra" <sandra.mur...@parsons.com<mailto:sandra.mur...@parsons.com>> Subject: Re: [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes 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 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) #Keyur: The draft don't suggest modifications to the BGP best path algorithm. Infact the next rev of the draft should fix and remove section 3 as well. The extended community used in draft is use to signal BGP best path validation state within an IBGP network. #Bruno: current version (04) of the draft do change the BGP decision process. cf section 3. If you remove section 3 in the next revision, this is indeed a different story. 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) #Keyur: There SHOULD not be multiple such extended communities for a given BGP path. We can add the necessary text. #Bruno: I agree on the goal. The question is how do you handle the case/error when there is more than one. I guess that this is less important if you remove section 3 and this community is purely informative with no impact on BGP decision process. 3) Rfc 6811 is referenced twice in important sections. What about moving it to "normative reference"? #Keyur: Sure. 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) #Keyur: Ideally, the usage of this community should NOT be encouraged across inter-as boundaries. We can add necessary text to reflect that part. #Bruno: I agree on the goal. The question is how do you handle the case (error/attack) where your untrusted neighbor sends you this community over an eBGP session. Regards, Keyur Thanks, Regards, Bruno From: Idr [mailto:idr-boun...@ietf.org] 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 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 i...@ietf.org<mailto:i...@ietf.org> https://www.ietf.org/mailman/listinfo/idr _________________________________________________________________________________________________________________________ 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.
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
