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

Hi Nandan,

Yes. That is correct.

Thanks,
Ketan

From: Nandan Saha <nandan@arista.com>
Sent: 21 November 2019 12:00
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Przemyslaw Krol <pkrol@google.com>; Robert Raszuk <robert@raszuk.net>; 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 Ketan/PK,

On Thu, Nov 21, 2019 at 4:57 AM Ketan Talaulikar (ketant) <ketant@cisco.com<mailto: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<mailto:pkrol@google.com>>
Sent: 21 November 2019 05:39
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; idr@ietf.org<mailto:idr@ietf.org>; Prakash Badrinarayanan <prakash@arista.com<mailto:prakash@arista.com>>; Manoharan Sundaramoorthy <manoharan@arista.com<mailto: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<mailto: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<mailto:pkrol@google.com>

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr