Subject: Re: [Idr] Genart last call review of draft-ietf-idr-bgp-open-policy-18

From: Alvaro Retana <[email-masked]>
Date: Tue, 4 Jan 2022 07:12:28 -0800

On December 21, 2021 at 8:01:21 PM, Gyan Mishra wrote:

Gyan:

Hi!  Happy New Year!

Thank you for the review!

...
> Summary: ... The new BGP role capabilities mismatch code 2 subcode 8
> discussed on ML seems to have multiple implementations deployed and one
> confined by Cisco. I agree that the authors should request a new subcode
> for the role mismatch notification.

To catch others up:  there is a confirmed case of squatting on the
assigned subcode.  A consultation on the next steps is open on the idr
list and will close tomorrow (Jan/5).

https://mailarchive.ietf.org/arch/msg/idr/RBD3Z9YIboudGAIeJLS8L--p4BU/

...
> Nits/editorial comments:
> Comment related to Gao-Rexford model. The Gao-Rexford Model only has 3 peer
> types North bound upstream Provider, Southbound Customer and lateral same
> tier level peer. With the role capabilities, RS and RS-Client is added which
> makes it slightly different but almost identical. In describing the role
> types would it make sense to have a graphical depiction of Gao-Redford model
> with the role capabilities on adjacent peers to help explain the role
> relationship for local and remote-as. Just an idea to help explain the role
> capabilities.

The role definitions are described in this document, not strictly
carried over from Gao-Rexford.  Nonetheless, a graphical description
on the roles defined here may make sense.  I'll leave it to the
authors to consider (if not too complicated).

> In the role correctness section scenario where the peer receives multiple
> role capabilities to send role mismatch notification. What if there is a
> timing issue and the multiple are received after the BGP open and peer is
> established possible sequence of events issue. Is it possible the peer may
> not get a mismatch notification if the peer establishes prior to getting a
> different capabilities where a mismatch or problem exists that is missed
> that could result in a route leak. I am thinking of possibly false positive
> or negative or negative during BGP open capabilities exchange

All capabilities are signaled in the OPEN, so there's no possibility
for receiving a Role Capability afterwards.

Alvaro.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 4 Jan 2022 10:44:24 -0500

Hi Alvaro

Happy New Year!

Welcome!

On Tue, Jan 4, 2022 at 10:12 AM Alvaro Retana <[email-masked]>
wrote:

> Gyan> Thanks for update

Gyan> Perfect

> for receiving a Role Capability afterwards.

Gyan> Agreed.  The multiple capabilities received is mentioned in the text,
however as it’s signaled in the open how would multiple capabilities be
received.  As the role capabilities are sent in the open , how can the
possibility of multiple capabilities occur?

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 4 Jan 2022 08:02:07 -0800

On January 4, 2022 at 10:44:35 AM, Gyan Mishra wrote:

Gyan:

...
> Gyan> however as it’s signaled in the open how would multiple capabilities
> Gyan> be received. As the role capabilities are sent in the open , how can
> Gyan> the possibility of multiple capabilities occur?

The OPEN can include multiple instances of the same capability.  This
is from rfc5492:

   BGP speakers SHOULD NOT include more than one instance of a
   capability with the same Capability Code, Capability Length, and
   Capability Value.  Note, however, that processing of multiple
   instances of such capability does not require special handling, as
   additional instances do not change the meaning of the announced
   capability; thus, a BGP speaker MUST be prepared to accept such
   multiple instances.

   BGP speakers MAY include more than one instance of a capability (as
   identified by the Capability Code) with non-zero Capability Length
   field, but with different Capability Value and either the same or
   different Capability Length.  Processing of these capability
   instances is specific to the Capability Code and MUST be described in
   the document introducing the new capability.

Alvaro.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 4 Jan 2022 16:35:50 +0000

Hi Gyan,

[I am following up on the messages exchanged between Alvaro and you this morning. Thanks to both of you for that.] 

Sorry for the delay in replying (considering your original review date). Thank you for your careful review and comments/nits. Please see responses marked with [KS/AA] below.

> Comment related to Gao-Rexford model.  The Gao-Rexford Model only has 3 peer
types North bound upstream Provider, Southbound Customer and lateral same tier
level peer.  With the role capabilities, RS and RS-Client is added which makes
it slightly different but almost identical.  In describing the role types would
it make sense to have a graphical depiction of Gao-Redford model with the role
capabilities on adjacent peers to help explain the role relationship for local
and remote-as.  Just an idea to help explain the role capabilities. 

[KS/AA]: We felt that instead of a graphical depiction, it is more useful to include text to enumerate the peering relationships corresponding to various Roles. So, we have added (in v-19 to be uploaded soon that will also include changes to reflect Ines' comments) the following new text in Section 2 after Roles are defined:

   If the local AS has one of the above Roles (in the order shown), then
   the corresponding peering relationship with the remote AS is
   Provider-to-Customer, Customer-to-Provider, RS-to-RS-Client, RS-
   Client-to-RS, or Peer-to-Peer (i.e., lateral peers), respectively.

Please let us know if this seems acceptable.

>In the role correctness section scenario where the peer receives multiple role
capabilities to send role mismatch notification.  What if there is a timing
issue and the multiple are received after the BGP open and peer is established
possible sequence of events issue.  Is it possible the peer may not get a
mismatch notification if the peer establishes prior to getting a different
capabilities where a mismatch or problem exists that is missed that could
result in a route leak. I am thinking of possibly false positive or negative or
negative during BGP open  capabilities exchange.

[KS/AA]: We feel that Alvaro has already adequately addressed this comment in his two messages. Please let us know if you still have a question.

Regards,
Sriram / Alexander   

-----------------------------------------------------------------------
From: Gyan Mishra <[email-masked]> 
Sent: Tuesday, January 4, 2022 10:44 AM
To: Alvaro Retana <[email-masked]>
Cc: Gyan Mishra via Datatracker <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-ietf-idr-bgp-open-policy-18

Hi Alvaro

Happy New Year!

Welcome!

Gyan> Perfect

Gyan> Agreed.  The multiple capabilities received is mentioned in the text,
however as it's signaled in the open how would multiple capabilities be
received.  As the role capabilities are sent in the open , how can the
possibility of multiple capabilities occur?

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Jan 2022 00:38:33 -0500

Hi Sriram & Alexander

Responses in-line

Kind Regards

On Tue, Jan 4, 2022 at 11:35 AM Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> Hi Gyan,
>
> [I am following up on the messages exchanged between Alvaro and you this
> morning. Thanks to both of you for that.]
>
> Sorry for the delay in replying (considering your original review date).
> Thank you for your careful review and comments/nits. Please see responses
> marked with [KS/AA] below.
>
> tier
> [KS/AA]: We felt that instead of a graphical depiction, it is more useful
> to include text to enumerate the peering relationships corresponding to
> various Roles. So, we have added (in v-19 to be uploaded soon that will
> also include changes to reflect Ines' comments) the following new text in
> Section 2 after Roles are defined:

   Gyan> Perfect

> Please let us know if this seems acceptable.

Gya> Agreed that is acceptable.  In the description as well maybe listing a
pecking order similar to what is described in Gao-Rexford model style
 route preference in the import and export policy verbiage for each role.
Also could mention that a good reasons for role capabilities usage by
operators  is to prevent routing policy disputes between peering points
that can result in sub optimal routing instability and feedback loops along
with route leaks mentioned.

> role
> [KS/AA]: We feel that Alvaro has already adequately addressed this comment
> in his two messages. Please let us know if you still have a question.

    Gyan> Agreed.

> Cc: Gyan Mishra via Datatracker <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > > not get a mismatch notification if the peer establishes prior to
> getting
> > a
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Jan 2022 02:06:13 -0500

Thanks Alvaro !

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 5 Jan 2022 17:12:11 +0000

Hi Gyan,

Thank you. Please see the responses inline.

Gyan> Agreed that is acceptable.  In the description as well maybe listing a
pecking order similar to what is described in Gao-Rexford model style
route preference in the import and export policy verbiage for each role.

[KS/AA]: That is interesting. We did already enhance the Role descriptions as follows to add the import policy verbiage (to the already existing export policy) in Sec. 2 of v-19 to be uploaded:

Old text:

   The following is a list of BGP Roles for eBGP peering and the
   corresponding rules for route propagation:

   Provider:  MAY propagate any available route to a Customer.

   Customer:  MAY propagate any route learned from a Customer, or
      locally originated, to a Provider.  All other routes MUST NOT be
      propagated.

   Route Server (RS):  MAY propagate any available route to a Route
      Server Client (RS-Client).

   RS-Client:  MAY propagate any route learned from a Customer, or
      locally originated, to an RS.  All other routes MUST NOT be
      propagated.

   Peer:  MAY propagate any route learned from a Customer, or locally
      originated, to a Peer.  All other routes MUST NOT be propagated.

New text:

   The following is a list of BGP Roles for eBGP peering and the
   corresponding rules for route propagation and acceptance:

   Provider:  May propagate any available route to a Customer.  May
      accept routes originated by the Customer or its Customers; all
      other routes from the Customer must not be accepted.

   Customer:  May propagate any route learned from a Customer, or
      locally originated, to a Provider; all other routes must not be
      propagated.  May accept any route from the Provider.

   Route Server (RS):  May propagate any available route to a Route
      Server Client (RS-Client).  May accept routes originated by the
      RS-Client or its Customers; all other routes from the RS-Client
      must not be accepted.

   RS-Client:  May propagate any route learned from a Customer, or
      locally originated, to an RS; all other routes must not be
      propagated.  May accept any route received from the RS.

   Peer:  May propagate any route learned from a Customer, or locally
      originated, to a Peer; all other routes must not be propagated.
      May accept routes originated by the Peer or its Customers; all
      other routes from the Peer must not be accepted.

--- end of new text ---

[KS/AA]: Maybe adding the following paragraph at the end of Section 3.2 (Role Correctness) would do it?

Besides facilitating a route leak solution, the Role Capability usage by network operators also helps prevent routing policy disputes between peering ASes. This can in turn prevent sub-optimal routing and routing instability.

Not sure if the feedback loop needs to be mentioned. Do you mean a loop in the AS path (normally prevented by checking the presence of the speaker's own AS in the path)?

Sriram / Alexander

---

From: Brian Dickson <[email-masked]>
Date: Wed, 5 Jan 2022 10:08:49 -0800

Top-reply (sorry) and first-of-thread reply (also sorry):
The diagram question/issue might be addressed by referencing the
better-than-Gao-Rexford model published in RFC7908 (included in the
References).
It has actual diagrams, including the initial role labeling on peering
sessions (excluding RS and RS-client but otherwise more complete than G/R).

Would that help address your concerns?

Brian Dickson
(Contributor, and co-author of 7908)

On Tue, Dec 21, 2021 at 5:01 PM Gyan Mishra via Datatracker <
[email-masked]> wrote:

> Reviewer: Gyan Mishra
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-idr-bgp-open-policy-??
> Reviewer: Gyan Mishra
> Review Date: 2021-12-21
> IETF LC End Date: 2021-12-17
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft provides a new BGP open role capability and OTC path
> attribute to detect and mitigate route leaks automatically.  I have been
> following this draft on IDR and supported through Adoption and WGLC.  This
> document has matured and is ready for publication.  The new BGP role
> capabilities mismatch code 2 subcode 8 discussed on ML seems to have
> multiple
> implementations deployed and one confined by Cisco.  I agree that the
> authors
> should request a new subcode for the role mismatch notification.
>
> Major issues:
> None
>
> Minor issues:
> None
>
> Nits/editorial comments:
> and remote-as.  Just an idea to help explain the role capabilities.  In the
> role correctness section scenario where the peer receives multiple role
> negative during BGP open  capabilities exchange
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 6 Jan 2022 00:29:12 +0300

Colleagues,

I would like to unveil what took us so long to reply.
We have an ongoing discussion about adding a formal description of
Complex/Sibling relations.
With the import and export policy definitions, it can be done rather easy,
it follows the Peer definition that Sriram has already shown:

   Sibling:  May propagate any available route to a Sibling.  May accept
      any available route received from a Sibling.

Sriram's concern was that Sibling has a notation for ASNs belonging to the
same administrative entity (701, 702, 703 belonging to Verizon as an
example), while I believe that the term Sibling isn't bound only for this
kind of peering relation and can safely replace Complex, though improving
the readability of the document.

ср, 5 янв. 2022 г. в 20:12, Sriram, Kotikalapudi (Fed) <
[email-masked]>:

> [KS/AA]: That is interesting. We did already enhance the Role descriptions
> as follows to add the import policy verbiage (to the already existing
> export policy) in Sec. 2 of v-19 to be uploaded:
>
>
>
> Old text:
>
>
>
> Besides facilitating a route leak solution, the Role Capability usage by
> network operators also helps prevent routing policy disputes between
> peering ASes. This can in turn prevent sub-optimal routing and routing
> instability.
>
>
>
> Not sure if the feedback loop needs to be mentioned. Do you mean a loop in
> the AS path (normally prevented by checking the presence of the speaker’s
> own AS in the path)?
>
>
>
> Sriram / Alexander
>

-- 
Best regards,
Alexander Azimov

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 5 Jan 2022 13:33:06 -0800

On January 5, 2022 at 12:12:14 PM, Sriram, Kotikalapudi wrote:

Sriram:

Hi!

> [KS/AA]: as follows to add the import policy verbiage (to the already
> [KS/AA]: existing export policy) in Sec. 2 of v-19 to be uploaded:

Route leaks are created by the (incorrect) advertisement of routes.
Defining egress rules is then in line with the subject of this
document.

OTOH, ingress rules are not.  Also, the ingress behavior is tied in
the draft to the OTC attribute (and not directly to the role).

The result is that the updated text is not consistent with the
behavior already defined elsewhere.  For example, using the Provider

...
...
...
> other routes from the Customer must not be accepted.

[Besides loosing the normative language...]

A strict interpretation of the text (routes originated by a Customer
can be accepted) is in contradiction with this text in §4:

   1.  If a route with the OTC Attribute is received from a Customer or
       RS-Client, then it is a route leak and MUST be considered
       ineligible (see Section 1.1).

Note that this text doesn't talk about the origin, but it qualifies
the policy based on the OTC attribute.

All this is to say that the expected ingress behavior, which depends
on the OTC attribute, is already defined elsewhere and there's no need
to change the role definition.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 5 Jan 2022 13:48:11 -0800

On January 5, 2022 at 4:29:22 PM, Alexander Azimov wrote:

Alexander:

Hi!

I'm moving this part of the discussion off the last-call and gen-art
lists because it is going in a direction beyond the original review.

In general, I don't think such a late addition (which would require a
lot more than the single bullet below) should be done without
consulting the WG and getting their consensus.

Personally, I think this is an unnecessary change because as you
explained in the text, "complex" relationships are, well, complex.  §5
talks about them being made up of multiple roles (which could be
segregated), but the text below tries to simplify that to send/receive
anything.

Given that you and Sriram don't agree yet on what type of
relationships are covered tells me that much more discussion may be
needed.  If you want to, I can send the document back to the WG for
this discussion.

Thanks!

Alvaro.

> With the import and export policy definitions, it can be done rather easy, it
> follows the Peer definition that Sriram has already shown:
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Jan 2022 16:57:51 -0500

Hi Brian

I agree that RFC 7908 reference would help.

Thank you

Gyan

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Jan 2022 17:27:05 -0500

Hi Alvaro

Responses In-line

I think the document needs to clearly state that the role priority by
itself does not have an import policy that is automatically configured.
The import policy is based on OTC Attribute.  The document should also
clearly state that Role priority must be used in conjunction with OTC
attribute.  I think this is being implied but needs to be clear that role
priority must be used with OTC attribute for route leak detection and
prevention.  Also in order for the route leak detection and prevention to
work correctly, the role priority cannot have an automatic inbound policy
and must depend on the dynamic signaling nature of OTC path attribute to
signal route leak.

Kind Regards

Gyan

> Defining egress rules is then in line with the subject of this

   Gyan> Agreed

> the draft to the OTC attribute (and not directly to the role).

   Gyan> Agreed

> behavior already defined elsewhere.  For example, using the Provider

   Gyan> Good point

>        ineligible (see Section 1.1).

     Gyan> Very Good point.  OTC attribute must be used for the route leak
detection dynamic import policy.

> the policy based on the OTC attribute.

   Gyan> Agreed

> to change the role definition.

    Gyan> Completely agree

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 6 Jan 2022 01:35:19 +0300

Alvaro,

Since I was pushing adding the ingress rules into the peering relation
definition I will try to answer your comments.

> Defining egress rules is then in line with the subject of this

It's true. But the incorrect or absent ingress rules are responsible for
route leak propagation.
The OTC tries to address both problems: prevent networks from leaking
prefixes and stop route leak propagation if it happens.

> the draft to the OTC attribute (and not directly to the role).

Here we try to define peering relations. These definitions are not strictly
bound to OTC mechanics, and IMO it doesn't bring any contradiction.
Today the ingress policy by Providers and Peers is done by generating
prefix lists from AS-SETs. In an ideal situation, it should be equal to
customer cone which is prefixes originated by Customer and its Customers.

> the policy based on the OTC attribute.

The definition of peering relations is followed by the next phrase:

   A BGP speaker may apply policy to reduce what is announced, and a
   recipient may apply policy to reduce the set of routes they accept.

So, the Provider/Peer may accept routes from the customer cone of
Customer/Peer respectively.
If OTC is set, it signals that the route was leaked, such routes MUST be
rejected, even if coming from the customer cone.

Have I missed your point?

> to change the role definition.

These edits emerged when I tried to formally define Complex/Sibling
relations. The sole propagation rule isn't enough to distinguish it from
other types of peering relations.
New text (full version):

   Provider:  May propagate any available route to a Customer.  May
      accept routes originated by Customer or its Customers; all other
      routes from Customer must not be accepted.

   Customer:  May propagate any route learned from a Customer, or
      locally originated, to a Provider; all other routes must not be
      propagated.  May accept any available route received from a
      Provider.

   Route Server (RS):  May propagate any available route to a Route
      Server Client (RS-Client).  May accept routes originated by RS-
      Client or its Customers; all other routes from RS-Client must not
      be accepted.

   RS-Client:  May propagate any route learned from a Customer, or
      locally originated, to an RS; all other routes must not be
      propagated.  May accept any available route received from RS.

   Peer:  May propagate any route learned from a Customer, or locally
      originated, to a Peer, all other routes must not be propagated.
      May accept routes originated by Peer or its Customers; all other
      routes from Peer must not be accepted.

If you suggest that the formal definition of Sibling relations doesn't
improve the readability I will revert these changes and keep propagation
rules only.

-- 
Best regards,
Alexander Azimov

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Jan 2022 17:40:42 -0500

Alvaro,

[TL;DR - I agree with you.]

> consulting the WG and getting their consensus.

I agree.

> needed.  If you want to, I can send the document back to the WG for

The benefit of the open-policy work comes from two properties:
1. Exchanging the role in the OPEN message.
2. The Only to Customer attribute and automatic policy based on the role.

The "sibling" case in many cases resembles an operational headache we've
been seeing creep into BGP extensions in recent years: Behaviors that expect
to be done on eBGP boundaries sometimes might be better off not done.  (For
example, some of the rt-constrain procedures.)

In the past, such things would fit into bgp confederation behavior, but
confederations aren't popular these days.  The "siblings" case is yet
another example of a set of "federated" BGP ASes.

Since the sibling case wouldn't have procedural changes for 2, above, is
there any benefit to noting the role in the OPEN message?

My initial bit of thinking is that the idea has some benefit in the sense
that you can have "strict" processing for roles for your siblings.  It
removes a case where "complex" really ends up being indistinguishable from
"doesn't support open-policy".

That said, I think if this sort of thinking is the intent, better to pull
the document back for longer discussion.

-- Jeff

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 5 Jan 2022 15:00:58 -0800

On January 5, 2022 at 5:35:31 PM, Alexander Azimov wrote:

Alexander:

...
> It's true. But the incorrect or absent ingress rules are responsible for

The absent case has already been addressed by rfc8212.

We can only hope when related to incorrect policies: the operator can
also misconfigure the roles and render OTC useless. :-(

...
> Have I missed your point?

Yes.

The text already talks about the possibility to have stricter policies.

Without that context (stricter-than-what-the-OTC-related-policy) then
the new text is left to be "May accept routes originated by the
Customer or its Customers" which is not true because of the MUST later
on.

IOW, the extra text is complicating the interpretation of the roles.

...
> If you suggest that the formal definition of Sibling relations doesn't improve the readability I will revert these changes and keep propagation rules only.

As I said in my other message, I think that adding Sibling is unnecessary.

Thanks!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Jan 2022 15:02:56 -0800

> My initial bit of thinking is that the idea has some benefit in the
> sense that you can have "strict" processing for roles for your
> siblings.  It removes a case where "complex" really ends up being
> indistinguishable from "doesn't support open-policy".

an uninteresting corner case.

i keep reading and trying to figure out how this all makes sense.  i
have not succeeded.

[ fwiw, historically, confeds tended to be used in two ways, peers, as
  in uunet (where they even shared an igp) and customer/provider, a la
  verio, where they were used to stage assimilation.  attempting to
  accommodate either in this draft is a foolish embellishment doomed to
  accomplish nothing useful; so probably appropriate </snark> ]

otc would be useful.  stop trying for perfection in boiling the ocean.

randy

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 6 Jan 2022 16:50:26 +0300

Colleagues,

Thank you for your feedback.
These edits were meant only to improve readability, and since it didn't
work out - I don't see the reason to argue.

Together with Sriram we will intercorporate minor nits and send the diff
file to the reviewers.

ps: turned off the fire under the ocean of perfection. :)

-- 
Best regards,
Alexander Azimov

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 7 Jan 2022 17:25:34 +0000

Gyan,

>I think the document needs to clearly state that the role priority by itself does not have an import policy that is automatically configured.  The import policy is based on OTC Attribute.  The document should also clearly state that Role priority must be used in conjunction with OTC attribute.  I think this is being implied but needs to be clear that role priority must be used with OTC attribute for route leak detection and prevention.  Also in order for the route leak detection and prevention to work correctly, the role priority cannot have an automatic inbound policy and must depend on the dynamic signaling nature of OTC path attribute to signal route leak.

Just reporting back here the agreement in the off-list conversation between you and the authors. We have made the following change (at the end of Section 3.2) and you kindly accepted it:

Old text:
   The BGP Role value for the local AS is used in the route leak
   prevention and detection procedures described in Section 4.
New text:
   The BGP Role value for the local AS (in conjunction with the OTC
   Attribute in the received UPDATE message) is used in the route leak
   prevention and detection procedures described in Section 4.
: Does this seem adequate?
: Gyan> Yes. Perfect

Thanks once again for your thorough review and help in improving the readability of the document.

Sriram / Alexander

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 Jan 2022 20:23:57 -0500

Hi Sriram

Responses in-line

On Fri, Jan 7, 2022 at 12:25 PM Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> Just reporting back here the agreement in the off-list conversation
> between you and the authors. We have made the following change (at the end
> of Section 3.2) and you kindly accepted it:
>
>
>
> Old text:
>
>  Gyan>  Welcome.  The verbiage looks good.  I am all set.
>
> Sriram / Alexander
>
> --

*Gyan Mishra*

*M 301 502-1347*

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 13:21:54 -0500

Alexander and Sriram:  

I agree with Alvaro that adding the siblings will require bringing this document back to IDR and re-starting the process.  I agree with Randy that the siblings is a corner case. 

As your shepherd, thank you for releasing version -19. 

Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, January 5, 2022 4:48 PM
To: Alexander Azimov; Sriram, Kotikalapudi (Fed)
Cc: [email-masked]; [email-masked]
Subject: [Idr] Siblings (WAS: Genart last call review of draft-ietf-idr-bgp-open-policy-18)

Alexander:

Hi!

Thanks!

Alvaro.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 20 Jan 2022 14:03:25 +0200

Gyan, thank you for your review and everyone else on the follow-on discussion. I have entered a No Objection ballot for this document.

Lars

> On 2021-12-22, at 3:01, Gyan Mishra via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Gyan Mishra
> capabilities mismatch code 2 subcode 8 discussed on ML seems to have multiple
> implementations deployed and one confined by Cisco.  I agree that the authors
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art