Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.
 
---

## Summary 

This standard track document defines the interworking mechanisms among these BGP domains (EVPN, VPN-IP, and IP) to ensure seamless end-to-end tenant connectivity. It also defines a new BGP path Attribute for loop prevention on gateways nodes and update BGP best path selection procedure. I think this document is well written, however it seems to lack some clarity on local policy in several sections such as section 5 and section 12 and also not clear about backward compatibility.

## Major Issues

1. Section 6.1 said:
"
This procedure extends the standard BGP best path selection behaviour
as specified in [RFC4271] for SAFI 128 and EVPN IP Prefix routes by
incorporating D-PATH based tie-breaking to prefer routes that
traverse the fewest Gateway PEs or domains."
   
[Qin] This document extends standard BGP best path selection behaviour
 as specified in [RFC4271]? I am wondering whether there are backward compatibility issues when one PE with standard BGP best path selection support talks to the other PE with extended BGP best path selection support.

2. Section 5.3 said:
"If there is at least one contributing ISF route that has a different D-PATH DOMAIN-ID, the gateway PE
SHOULD advertise each contributing ISF route with its own D-PATH
(prepended with the gateway's domain).
An implementation MAY override this behaviour, via policy, to advertise an ISF aggregate
route without D-PATH in case the contributing routes did not have
the same D-PATH DOMAIN-ID members."

[Qin] what does the policy looks like here? local policy, does such local policy introduce inconsistent behaviour of the gateway PE?
when such ISF aggregate route without D-PATH, how is such ISF aggregate Route handled? 

## Minor issues
 
1. Section 1 said:
"Accordingly, this document updates the BGP best path
selection procedures specified in [RFC4271], but only in the context
of IPVPN and EVPN families." 

[Qin] Is there a need to indicate update to RFC4271 in the front page?

2. Section 12 said:
"As a further safeguard, implementations SHOULD enforce local policy
on upgraded PEs to discard any ISF EVPN or IPVPN routes received from
non-upgraded peers if such routes include a D-PATH attribute, to
prevent unintended propagation."


[Qin] what does local policy look like, policy indicating peer itself is upgraded or non-upgraded?, how does upgraded PEs with such local policy know the ISF EVPN or IPVN routes are received from non-upgraded peers? 

3. Section 5.1
where remote IPVPN or IP-based PEs do not require the original EVPN-specific BGP Path Attributes for path selection or policy evaluation.

[Qin] where EVPN-specific BGP path attributes for policy evaluation specified? RFC4271?, it will be nice to add reference for policy evluation.


4. Section 6.1 said:
"These rules MUST NOT be applied to routes received under AFI/SAFI combinations other than
 SAFI 128 or EVPN; such routes get a treat-as-withdraw procedures as
 described in Section 4."
   
[Qin] where treat-as-withdraw procedures are specified in section 4 of this document? is this paragraph related to error handling procedure 
apply to the D-PATH Path Attribute? How such treat-as-withdraw procedure is different from one defined in RFC7606?

## Nits
s/Interworking PE Section 3/Interworking PE in Section 3
s/reoriginates/re-originates