Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 9 Jun 2021 16:09:09 +0000

Hi Mach,

Thanks for your patience. Alexander and I were able to complete the discussion between us. 

Please let us know if the following two proposed changes would adequately address your comment:

We added the following new paragraph in Section 5.1 (just before the OTC attribute processing section (Sec. 6)):

   In the case of a neighbor who doesn't participate, the BGP Role is
   configured unilaterally based on local knowledge of the peering
   relationship.  (Note: This applies only to the default non-strict
   mode; remember that in strict mode, the BGP connection is rejected
   for any non-participating neighbor.)  The only thing lacking would be
   a mutual confirmation with the neighbor about BGP Role (this is
   permissible for backward compatibility in partial deployment).  The
   OTC attribute processing (Section 6) remains unaffected.

In the above, if you feel normative language should be used, then we can
s/BGP Role is configured unilaterally/BGP Role SHOULD be configured unilaterally/.
Please let us know. 

We made the following old text / new text substitution in Section 8:

Old text:
   No Roles SHOULD be configured on a 'complex' BGP session (assuming it
   is not segregated) and in that case, OTC MUST be set by configuration
   on a per-prefix basis.  However, there are no built-in measures to
   check correctness of OTC use if BGP Role is not configured.

New text:
   No Roles SHOULD be configured on a 'complex' BGP session (assuming it
   is not segregated) and in that case, the OTC attribute processing
   MUST be done relying on configuration on a per-prefix basis.  (Note:
   The per-prefix configuration of peering relationship is currently
   done to handle 'complex' BGP sessions.)  However, there are no built-
   in measures to check the correctness of OTC use if BGP Role is not
   configured.

I've attached a diff file that highlights the above-proposed changes 
and also the changes in response to your nits. We'll plan to upload 
a new version -16 after we hear back from you on these proposed changes. 
Thank you.

Sriram
________________________________________
From: Mach Chen <[email-masked]>
Sent: Saturday, May 29, 2021 4:03 AM
To: Alexander Azimov
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

Hi Alexander,

Please see me response inline with [Mach]

From: rtg-dir [mailto:[email-masked]] On Behalf Of Alexander Azimov
Sent: Saturday, May 29, 2021 4:05 AM
To: Mach Chen <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-idr-bgp-open-policy-15.txt

Dear Mach,

Thank you for your comments, all nits are already applied.

[Mach] OK.

But it proved that different authors have a different reading of your comment related to section 6:
Section 6.
It does not specify how a speaker handle a route with OTC attribute but the sender's role is unknown.
Are you speaking about the OTC processing in case of the absence of a locally configured role?
Or does it about receiving OTC attribute from a neighbor that doesn't participate in the role negotiation?

[Mach] Actually, in both cases, the role of the peer is uncertain, if so what will the ingress policy and egress policy be? For example, regarding ingress policy, how to handle a route with OTC attribute but not sure the sender’s role. And regarding the egress policy, if the peer’s role cannot be determined, Whether the route should be sent to the peer? Should the OTC be kept?

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Fri, 11 Jun 2021 09:15:50 +0000

Hi, Sriram

Thanks for the update, it addressed my comments!

Best regards,
Mach

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Sriram, Kotikalapudi (Fed)
> Sent: Thursday, June 10, 2021 12:09 AM
> To: Mach Chen <[email-masked]>; Alexander Azimov
> <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Idr] [RTG-DIR] RtgDir Early review:
> draft-ietf-idr-bgp-open-policy-15.txt
> 
> Hi Mach,
> 
> In the above, if you feel normative language should be used, then we can s/BGP
> Role is configured unilaterally/BGP Role SHOULD be configured unilaterally/.
> Please let us know.
> 
> I've attached a diff file that highlights the above-proposed changes and also the
> changes in response to your nits. We'll plan to upload a new version -16 after we
> hear back from you on these proposed changes.
> Thank you.
> 
> Sriram
> [Mach] Actually, in both cases, the role of the peer is uncertain, if so what will the
> ingress policy and egress policy be? For example, regarding ingress policy, how to
> handle a route with OTC attribute but not sure the sender's role. And regarding
> the egress policy, if the peer's role cannot be determined, Whether the route
> should be sent to the peer? Should the OTC be kept?
> 
> Best regards,
> Mach