It would be useful to include sidr on this discussion. I've added the wg to the cc list.
--Sandy On Jun 10, 2014, at 11:49 AM, <[email protected]> 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” … > > 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. > > Thanks, > Regards, > Bruno > > > From: DECRAENE Bruno IMT/OLN > Sent: Tuesday, June 10, 2014 5:40 PM > To: 'Susan Hares'; idr wg > Cc: Murphy, Sandra; 'John G. Scudder' > 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) > > 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”? > > 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, > Regards, > Bruno > > > From: Idr [mailto:[email protected]] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
