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

Thanks folks.

On Thu, Nov 21, 2019 at 12:06 PM Ketan Talaulikar (ketant) <[email protected]>
wrote:

> Hi Nandan,
>
>
>
> Yes. That is correct.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Nandan Saha <[email protected]>
> *Sent:* 21 November 2019 12:00
> *To:* Ketan Talaulikar (ketant) <[email protected]>
> *Cc:* Przemyslaw Krol <[email protected]>; Robert Raszuk <[email protected]>;
> [email protected]; Prakash Badrinarayanan <[email protected]>; Manoharan
> Sundaramoorthy <[email protected]>
> *Subject:* 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) <
> [email protected]> 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 <[email protected]>
> *Sent:* 21 November 2019 05:39
> *To:* Robert Raszuk <[email protected]>
> *Cc:* Ketan Talaulikar (ketant) <[email protected]>; [email protected]; Prakash
> Badrinarayanan <[email protected]>; Manoharan Sundaramoorthy <
> [email protected]>
> *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 <[email protected]> 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 | [email protected]
>
>
>
> _______________________________________________
> Idr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/idr
>
>

-- 
Przemyslaw Gniewomir "PK" Krol |   Network Engineer ing | [email protected]

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr