Subject: Re: [Last-Call] Rtgdir last call review of draft-ietf-idr-bgp-open-policy-18

From: Alexander Azimov <[email-masked]>
Date: Fri, 7 Jan 2022 22:40:09 +0300

Ines,

Thank you for your review and comments. Sorry for the delay in responding.
Responses marked with [AA/KS] below.

1- It would be nice to mention in the first paragraph of Section 4 when you

present the OTC Attribute that is included into the UPDATE message.

[AA/KS]: Looks intuitive as Path Attributes in RFC4271 are defined only for
UPDATE messages but it seems easy enough to add. So we mention it now per
your suggestion.

Old text:

   The Only to Customer (OTC) Attribute is an optional transitive path

   attribute with Attribute Type Code 35 and a length of 4 octets.

New text:

   The Only to Customer (OTC) Attribute is an optional transitive path

   attribute of the UPDATE message with Attribute Type Code 35 and a

   length of 4 octets.

2- Should the attribute-flags of the OTC attribute mentioned explicitly in

Section 4? e.g. the high order bit (bit 0) is 1 (optional); the bit 1 is 1

(transitive); the bit 2 (partial bit) is 0/1(?), etc?

[AA/KS]:  We don’t think this is needed. Have you seen such definitions for
new attributes in any document? We think that optional & transitive
specification should be enough. Please see RFCs 7752 and 8205 as recent
examples.

4- In Section 4,  the ingress policies guide to leak detection and the
egress

policies guide to leak prevention. Correct?

[AA/KS]: Yes. And both are equally responsible for route marking.

5- Section 5: Is there a formal definition for complex peering
relationships?

Should it be added into terminology section? Maybe defining what is a simple

peering relationship and then stating that what is not simple is complex?

[AA/KS]: This looks like a fair point. Section 2 now defines what is a
normal relationship and also what is called a Complex relationship.

How are the security considerations in complex peering relationships?

[AA/KS]: For the Complex case also, it is no different from setting an
incorrect BGP Role. It has been already stated, ‘A misconfiguration of the
BGP Role may affect prefix propagation.’

We have uploaded the new version (v19) of the document that incorporates
the above changes.

ср, 8 дек. 2021 г. в 13:54, Ines Robles via Datatracker <[email-masked]>:

> Reviewer: Ines Robles
> Review result: Ready
>
> Hello,
>
> I have been selected to do a routing directorate review of this draft.
>
> For more information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Document: draft-ietf-idr-bgp-open-policy-18
> Reviewer: Ines Robles
> Review Date: 08-12-2021
> Intended Status: Standards Track
>
> Summary:
>
> This document provides configuration automation using BGP Roles. An
> optional,
> transitive BGP Path Attribute, called Only to Customer (OTC), is
> specified. It
> prevents ASes from creating leaks and detects leaks created by the ASes in
> the
> middle of an AS path.
>
> This document is basically ready for publication, I have some minor
> comments/questions below.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/Comments/Questions:
>
> 1- It would be nice to mention in the first paragraph of Section 4 when you
> present the OTC Attribute that is included into the UPDATE message.
>
> 2- Should the attribute-flags of the OTC attribute mentioned explicitly in
> Section 4? e.g. the high order bit (bit 0) is 1 (optional); the bit 1 is 1
> (transitive); the bit 2 (partial bit) is 0/1(?), etc?
>
> 4- In Section 4,  the ingress policies guide to leak detection and the
> egress
> policies guide to leak prevention. Correct?
>
> 5- Section 5: Is there a formal definition for complex peering
> relationships?
> Should it be added into terminology section? Maybe defining what is a
> simple
> peering relationship and then stating that what is not simple is complex?
>
> How are the security considerations in complex peering relationships?
>
> Thanks for this document,
> Ines.
>
>
>

-- 
Best regards,
Alexander Azimov