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

[Mach Chen <[e-mail]>]

Hi, Sriram

Thanks for the update, it addressed my comments!

Best regards,
Mach

> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of Sriram, Kotikalapudi (Fed)
> Sent: Thursday, June 10, 2021 12:09 AM
> To: Mach Chen <[e-mail]>; Alexander Azimov
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Idr] [RTG-DIR] RtgDir Early review:
> draft-ietf-idr-bgp-open-policy-15.txt
> 
> 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 <[e-mail]>
> Sent: Saturday, May 29, 2021 4:03 AM
> To: Alexander Azimov
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]] On Behalf Of Alexander Azimov
> Sent: Saturday, May 29, 2021 4:05 AM
> To: Mach Chen <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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