Forwarded to sidr to keep them in this discussion. --Sandy
On Jun 12, 2014, at 12:52 PM, "Keyur Patel (keyupate)" <keyup...@cisco.com> wrote: > Hi Bruno, > > Thanks for the draft review. Comments inlined #Keyur > > From: <bruno.decra...@orange.com> > Date: Tue, 10 Jun 2014 15:40:05 +0000 > To: Susan Hares <sha...@ndzh.com>, idr wg <i...@ietf.org> > Cc: "'John G. Scudder'" <j...@bgp.nu>, "Murphy, Sandra" > <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. > > 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. > > 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. > > > 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]. 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 https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
