Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

[Robert Raszuk <[e-mail]>]

Brian,

Regarding BGP OV I meant to use it as a database of valid ASNs - where it
is present.. Nothing to do with actual prefixes in MP_REACH here.

> So, I think the "unless policy is in place" is a red herring; whether
policy is there or not,
> and regardless of what policy there is, it is ALWAYS "allow any value".

Well if my policy says drop junk it can not ALWAYS act as "allow any
value".

Thx,
R.



On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson <
[e-mail]> wrote:

>
>
> On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk <[e-mail]> wrote:
>
>> so summarising:
>>>
>>> - operators: you MUST use an ASN
>>> - implementers: you MUST allow any value
>>>
>>
>> ​IMHO this is too coarse simplification.
>>
>> For operators if we are getting into this here vs in companion GROW doc
>> draft/rfc must define what sending vs receiving operator is expected to do.
>>
>> ​For implementation allowing any value unless policy is in place. And as
>> such policy must be able to validate against BGP Origin Validation database
>> if present and enabled on the router.
>>
>
> You've lost me here. If I am sending prefix X, and I am ASN A, and the
> community is B:C:V, the BGP OV will show A is allowed to originate X. There
> are no other restrictions applicable from OV.
> Also, the meaning of B:C:V is exclusively defined by ASN B, who may or may
> not be a directly connected peer.
>
> Nobody except B is expected to "do" anything.
> What B does, is a combination of:
> - What B tells the world
> - What B tells some subset of the world (e.g. via a customer portal which
> has restricted access)
> - What B uses to decide for whom each set of actions is permitted
> - Any internal policies and procedures known only to B
>
> E.g. B may allow B:C:V from customers of B (including customers of
> customers, etc.)
> E.g. B may allow B:D:V from anyone for some set of values V and some
> specific values of "D"
> E.g. B may allow arbitrary automated functionality associated with
> B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and
> VN is a trigger for some particular behavior (filter, prepend, change MED)
>
> Every ASN "B" can choose whatever it wants as the methods, mechanisms,
> values, etc., and those do not need to have any bearing on any other ASN's
> choices.
>
> Some ASNs will choose not to use their own ASN:X:Y, but rather use
> PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct
> choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no
> global meaning.)
>
> So, I think the "unless policy is in place" is a red herring; whether
> policy is there or not, and regardless of what policy there is, it is
> ALWAYS "allow any value".
>
>
>>
>> Again .. I assume we are all talking about first 4 octets only right ? Or
>> also second 4 octets too ?
>>
>>
> First 4 octets only.
>
> Brian
>