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

Hi Ketan/PK,

On Thu, Nov 21, 2019 at 4:57 AM Ketan Talaulikar (ketant) <ketant@cisco.com>
wrote:

> Hi PK,
>
>
>
> I will make the text change for the community part as discussed below in
> the next update.
>
Just to confirm, we're not treating both RT_TGT and NO_ADV  being present
as an error, right? The update will only be to clarify that both are
allowed together.

>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Przemyslaw Krol <pkrol@google.com>
> *Sent:* 21 November 2019 05:39
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com>; idr@ietf.org; Prakash
> Badrinarayanan <prakash@arista.com>; Manoharan Sundaramoorthy <
> manoharan@arista.com>
> *Subject:* Re: [Idr] I-D Action:
> draft-ietf-idr-segment-routing-te-policy-08.txt
>
>
>
> 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 <robert@raszuk.net> 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 | pkrol@google.com
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>