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

["John G. Scudder" <[e-mail]>]

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 <[e-mail]> 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,  <[e-mail]> wrote:
>> 
>> Hi Robert, all
>> 
>>> From: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr