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 <rob...@raszuk.net> 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, <bruno.decra...@orange.com> wrote: >> >> Hi Robert, all >> >>> From: rras...@gmail.com [mailto:rras...@gmail.com] 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. >> >> _________________________________________________________________________________________________________________________ >> >> 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 > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
