Re: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-08.txt

[Przemyslaw Krol <[e-mail]>]

Hi Robert,

Why ? IMO when both present is a valid case as RT can be used locally for
import as well. RT ext-community and NO_ADV community are pretty orthogonal
and serve different purposes.

That's a good point, although in SRTE, NO_ADVERTISE community has a special
meaning on top of the "normal" propagation limitation.  Draft says 'either
OR' so, in my opinion, this implies 'AND' is not acceptable. If that's the
case, then NLRI should be dropped. If, on the other hand, both are
acceptable, then it should probably state 'either RT or NO_ADVERTISE ot
both'.

Say when you are on RR suppressing IBGP would be a spec bug :).

Fair enough. I was reading the previous version as 'by default don't
propagate but you may' and was only curious why IBGP vs EBGP distinction
was made in this version. Security aspect does sound like a good
justification for it.

thanks,


On Wed, Nov 20, 2019 at 10:18 PM Robert Raszuk <[e-mail]> wrote:

> Przemek,
>
> and clearly states the behavior when both are missing (policy not
>> accepted).. Do you see a value in stating the behavior when both are
>> present? Based on the above wording this would deem policy not acceptable
>> and in consequence neither accepted locally not propagated down (must not
>> accepted, not necessarily usable, in order to propagate as stated in the
>> following section). Should it be clearly stated as erroneous condition?
>>
>
> Why ? IMO when both present is a valid case as RT can be used locally for
> import as well. RT ext-community and NO_ADV community are pretty orthogonal
> and serve different purposes.
>
> 4.2.4. Propagation of an SR Policy
>>
>> It seems that the original wording was referring to just BGP when
>> addressing the default propagation. In the current version, there is a
>> distinction between EBGP (do not propagate) and IBGP (propagate). What is
>> the reason for such distinction?
>>
>
> Say when you are on RR suppressing IBGP would be a spec bug :).
>
> Thx,
> R.
>
>
>>

-- 
Przemyslaw Gniewomir "PK" Krol |   Network Engineer ing | [e-mail]