[bess] Re: Ketan Talaulikar's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Jorge,

I think we are done here! Thanks again for the great discussion and taking
the time to make the updates. I hope it helps.

I'll clear my ballot (both DISCUSS and COMMENTs) once the submission
happens.

Thanks,
Ketan


On Thu, Mar 5, 2026 at 6:31 PM Jorge Rabadan (Nokia) <
[e-mail]> wrote:

> Hi Ketan,
>
> Revision 17 addresses your latest comments.
> I’m sending the text and the diff (enclosed) since I can’t post it due to
> the cut-off at the moment.
>
> Please see in-line for those that needed follow up.
>
> Thank you very much, your review was very thorough and to the point!
>
> Jorge
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Monday, March 2, 2026 at 10:20 AM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail]
> <[e-mail]>
> *Subject: *Re: Ketan Talaulikar's Discuss on
> draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
> Hi Jorge,
>
> Thanks for sharing the significant update and your responses. Please check
> inline below for follow-on and clarifications/suggestions. For the ones
> without responses, please consider them closed.
>
> I see that this version claims to "update" RFC4271. This is just not
> right. This document clearly does not apply to SAFI 1 which is what RFC4271
> specifies. Please remove this tag. The last thing that we want is that
> every spec that tweaks/adds something for a specific AFI/SAFI/feature to
> claim "updates" on RFC4271.
>
> One might say that this "updates" tag applies to RFC4364 or RFC7432 but
> even that is not really true since DPATH is an optional feature and not an
> update to these base specifications for IPVPN and EVPN. Hence, I do not
> understand the case for this "updates" tag.
>
> It looks like this confusion came about because of the following text in
> the abstract, which probably can be deleted:
>
> As a result, this specification updates the BGP best path selection
> procedure, but only in the context of IPVPN and EVPN route families.
>
> And further in the introduction, I would suggest the following:
>
> CURRENT:
> Accordingly, this document updates the BGP best path selection procedures
> specified in [RFC4271
> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>],
> but only in the context of IPVPN and EVPN families.
>
> SUGGEST:
> Accordingly, this document updates the BGP best path selection procedures
> specified in [RFC4271
> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>],
> but only in the context of IPVPN and EVPN families when interconnecting
> domains using the D-PATH attribute.
>
> *[jorge] The “updates” was added in rev 16 based on one of the reviews. It
> is gone in rev 17. I removed the sentence you suggested too. In the intro I
> took your suggestion, slightly modified (hope it’s ok):*
> *CURRENT:*
> *Accordingly, this document updates the BGP best path selection procedures
> specified in [**RFC4271
> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>**],
> but only in the context of IPVPN and EVPN families.*
> *NEW:*
> *Accordingly, this document updates the BGP best path selection procedures
> specified in [**RFC4271
> <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>**],
> but only for the IPVPN and EVPN families when the D-PATH attribute is used
> for inter-domain connectivity.*
>
> *See more below.*
>
>
> On Sun, Mar 1, 2026 at 3:06 AM Jorge Rabadan (Nokia) <
> [e-mail]> wrote:
>
> Hi Ketan,
>
> Thank you very much for the thorough review!
>
> Revision 16 attempts to address your concerns. Please, let us know if this
> clears your DISCUSS points.
> See some comments along your remarks with [jorge].
>
> Thank you!
> Jorge
>
> *From: *Ketan Talaulikar via Datatracker <[e-mail]>
> *Date: *Wednesday, January 21, 2026 at 1:23 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]
>  <[e-mail]>
> *Subject: *Ketan Talaulikar's Discuss on
> draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT)
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-bess-evpn-ipvpn-interworking-15: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for their this important document that has
> multiple implementations and widespread deployment.
>
> However, there are some points that I would like to discuss.
>
> <discuss-1> The document is about intra/inter-subnet forwarding within
> tenant
> networks but also bring in BGP IP (Global) Routing (SAFI 1) into the
> discussion
> which has no notion of multi-tenancy. I fail to see in the document where
> SAFI 1 is being used as an ISF SAFI or ISF Route. I do see some prospects
> about
> leaking routes between default VRF (global table) and non-default VRF
> (of tenants). However, that practice is an very old artifact of IPVPN and
> is unchanged by this document. I'll admit that artifact has not been fully
> specified in an IETF RFC, but not sure why this document should take that
> upon itself. And, if it was the intent to do so, we'll probably need more.
> So, the question is can SAFI 1 be removed as an ISF SAFI/Route in this
> document?
>
> *[jorge] Earlier versions of the document applied the procedures,
> including D-PATH, to SAFI 1. However, following concerns raised by the IDR
> chairs regarding the risks of using D-PATH with SAFI 1—particularly the
> potential leakage of D-PATH into the Internet, we removed SAFI 1 from the
> D-PATH procedures entirely. Some references to SAFI 1 remained, as certain
> aspects (e.g., path attribute propagation) could still be applicable to
> SAFI 1 routes. That said, retaining these references without additional
> clarification may create confusion. So yes, SAFI 1 can be removed. Check
> out the changes in revision 16. We also added this in the terminology
> section:*
>
> *"ISF SAFI: the Inter-Subnet Forwarding (ISF) Subsequent Address Family
> Identifier (SAFI) defines an MP-BGP (Multi Protocol Border Gateway
> Protocol) Sub-Address Family used to advertise IP prefix reachability for
> inter-subnet forwarding within a tenant network. The SAFIs used for ISF
> include 1 (applicable only to IPv4 and IPv6 AFIs), 128 (applicable only to
> IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI 25). The
> procedures defined in this document apply only to SAFI 128 and SAFI 70.
> Accordingly, for the purposes of this document, the term “ISF SAFI” refers
> exclusively to SAFI 128 or SAFI 70." *
>
>
> KT> Looks good. Thanks.
>
>
>
>
>
> <discuss-2> The title of the document but also the abstract/introduction is
> misleading in the sense that this document does not only specify EVPN
> interworking with IPVPN. It actually is about interconnecting of different
> domains that could be any combination of EVPN and IPVPN (e.g., two EVPN
> domains). Please correct if I am wrong. So then perhaps the title could be:
> "Interconnecting EVPN and IPVPN Domains" ... and this get clarified in
> the abstract and introduction?
>
> *[jorge] Good point. Done.*
>
>
> KT> Thanks.
>
>
>
>
> <discuss-3> The document references MPLS and NVO tunnels. However, I don't
> believe those terms cover SRv6 overlays (at least not per RFC9136). This
> document does seem to cover some SRv6 aspects though. Perhaps an easy way
> to
> address is to include 'SRv6 Overlay' alongside MPLS & NVO and maybe one or
> two
> bits of text needs adjustment. Another option is to introduce a term like
> "overlay" in the terminology section and clarify that overlay could use
> any of
> the encapsulations - MPLS, NVO, SRv6, foo ... Then most of the rest of the
> text
> is anyway abstracted from the encapsulation.
> *[jorge] another good point, please check the changes.*
>
>
> KT> Thanks. Can you please also include SRv6 in Figure 9 (both in IPVPN
> and EVPN domains)? I don't think it is necessary in Figure 10 though (since
> the purpose is something else) but I leave that to you.
> *[jorge] done.*
>
>
>
>
> <discuss-4> The document uses the term "propagates" and "propagation" in
> the
> context of advertisement of routes across domains (whether the ISF SAFIs
> are
> changing or not) by a Gateway PE. I believe the correct technical term for
> what is happening is "re-origination" (or export). The difference is
> important
> from BGP perspective since (re)origination is actually a fresh forming of
> the
> BGP UPDATE with the necessary attributes associated with the route. I am
> not getting into implementation aspects and instead sticking to the
> semantics.
> Propagation refers to the usual propagation of BGP routes across BGP
> speakers
> (hop by hop or over RRs) and not really what a Gateway PE does. When doing
> (re)origination, the attributes are "created" afresh - they may or may not
> pick up contents (called in this spec as no-propagation and propagation
> modes)
> from the original route advertisement that was imported. This depends
> almost
> always on the type of each specific attribute and its functionality. Then
> again,
> this import/export and (re)advertisement is clearly specified in section 8
> and also in the 2nd last para of section 1 when dealing with multiple
> encapsulations. So, why not bring the same consistency throughout the
> document?
>
> Note: Please see discuss-11 to better understand the reason why I bring up
> this
> important semantic.
>
> *[jorge] I agree with your point. However, since the Gateway procedures
> were already clearly defined, we did not initially consider it necessary to
> avoid the term “propagation” when referring to routes. Please review the
> latest changes. In summary, we have replaced “propagation” with
> “re-origination” in all instances where a route is exported by the Gateway
> PE. The term “propagation” is now used exclusively in the context of path
> attributes. It is understood that when a Gateway PE re-originates a route,
> it may choose to propagate (or not propagate) specific path attributes. In
> this context, “propagating” path attributes means copying them from the
> received route into the re-originated route. I think this way reads better,
> please let us know if it is ok.*
>
>
> KT> Yes, this is ok. Thanks.
>
>
>
>
> <discuss-5> Section 4 says:
>
> 492        Similar to AS_PATH, D-PATH is composed of a sequence of Domain
> 493        segments.  Each Domain segment is comprised of <domain segment
> 494        length, domain segment value>, where the domain segment value
> is a
> 495        sequence of one or more Domains, as illustrated in Figure 6.
> Each
>
> The document does not describe the semantics of a Domain Segment. A reading
> of the procedures gives the impression that Domain Segments are a mean to
> "attach more domains" when the Domain Segment Length cannot be incremented
> anymore (i.e., beyond 255 domains). I highly doubt the real-world/practical
> relevance of such a hypothetical situation. But then the bullet (f) makes
> me wonder if there is some other purpose as well. Can you please clarify?
>
> *[jorge] I changed bullet f to say **“**domain**”** instead of "domain
> segment**” to avoid misinterpretations**. It**’**s really a way to add
> more domains, however, there is no restriction on using multiple segments
> or a single segment that encompasses all domains (provided the total number
> remains below 255).*
>
>
> KT> OK. It would be good to be more precise here about introducing a new
> domain segment only when one runs out of space in the previous domain
> segment but maybe this comment is coming too late? If so, let's consider
> this closed.
> *[jorge] I’ve seen both ways in shipping code and deployed
> implementations, and this does not cause interop issues, so I’d prefer to
> leave it as is.*
>
>
>
>
> <discuss-6> Section 4 says:
>
> "The Local Administrator sub-field is any local 2-octet value, and its
> allocation
>  or configuration is a local implementation matter."
>
> I am having trouble understanding how this can be a "local implementation
> matter". If I have two gateway PEs from two different vendors, I need them
> both
> to have/use the exact same Domain-ID. So, this seems very important
> operational
> aspect for this to be specified - perhaps that it is configured by
> operator and
> may be some recommended default value if the Global Administrator
> sub-field is
> sufficient for unique identification of a domain? I believe some
> guidance/recommendations on the operational considerations for the setting
> of
> Local Administration along with the Global Administration would be helpful
> in
> this document. There is already some text on the Global Administration
> sub-field and in other places in the document. Consolidating it in one
> place to
> provide guidance based on existing implementations and deployments would be
> super-helpful.
>
> *[jorge] “a local implementation matter” meant that the field does not
> encode any particular value or has any semantics, whereas the Global Admin
> value may encode an ASN or an IP, for the operator’s convenience. New text:*
> *MODIFIED TEXT:*
> *DOMAIN-ID is a 6-octet field that represents a domain. It is composed of
> a 4-octet Global Administrator sub-field and a 2-octet Local Administrator
> sub-field. The Global Administrator sub-field MAY be filled with an
> Autonomous System Number (ASN, Public or Private), an IPv4 address, or any
> value. The combined Global Administrator and Local Administrator can use
> any value that guarantees the uniqueness of the DOMAIN-ID (when the tenant
> network is connected to multiple Operators) and helps troubleshooting and
> debugging of D-PATH in ISF routes. A Gateway PE that interconnects two
> domains is associated with two distinct DOMAIN-IDs, one per domain. All
> Gateway PEs attached to the same domain MUST use the same DOMAIN-ID value
> to represent that domain. Expressing the Global Administrator and Local
> Administrator values as opaque unsigned integers is RECOMMENDED.*
>
>
> KT> Looks good. Thanks.
>
>
>
> <discuss-7> Section 4 says:
>
> 539           local implementation matter.  Expressing the Global
> Administrator
> 540           and Local Administrator values as opaque unsigned integers is
> 541           RECOMMENDED.
>
> What is meant by "expressing" here? Is it how these fields are reported
> via YANG and/or in CLI outputs? Again, for operational consistency across
> implementations, is it possible to identify a few well-known/implemented
> ways of
> reporting these fields?
>
> *[jorge] That was a very specific request from Jeff Hass during his
> review. I’m pasting here the discussion with him:*
>
> *--------*
> *> > The intent for domain id appears to be that the contents of the type
> is*
> *> > "structured", in the sense that it has a "global" field and a "local"
> field is*
> *> > clear.  The related intent here appears to be that the contents are
> opaque.*
> *> > Several examples for the Global Admin field are offered.  The fact
> that the*
> *> > examples are aligned with RFC 4360 Extended Community types is
> perhaps not a*
> *> > surprise.*
> *> > [...]*
> *> > Consider whether the intended opaqueness and flexibility will be
> worth the*
> *> > future contention over display formats in interoperable management
> systems.*
> *>*
> *> [jorge] The format of the global admin value is purposedly kept lose so
> that the spec is not closed to a specific structure that may be useful. In
> reality, there are only two ‘structures’ – ipv4 address format or
> an unsignedinteger (which can match an ASN). Based on the implementations I
> am aware of, and that we tested at the EANTC event over the years, I can
> see that most vendors use the 4-octet-uint:2-octet-uint format for
> global-admin:local-admin values. I only know of one vendor that allows the
> ipv4 address format as an option. As you say, this does not represent a
> functional interoperability issue. But I see your point about YANG
> implementations using different structures. I added the following, which I
> think should be sufficient to guide people to use
> opaque unsigned integers as structure, while not forbidding the use of
> other structures:*
> *>*
> *> “The representation of the Global Administrator and Local Administrator
> values as opaque unsigned integers is RECOMMENDED.”*
>
> *That works.  It'll also provide the relevant guidance when it's time to
> do*
> *the YANG work.*
> *--------*
>
>
> KT> Thanks for confirming the context to be related to the rendering in
> CLI/YANG. Then, I would suggest the following:
>
> CURRENT:
> Expressing the Global Administrator and Local Administrator values as
> opaque unsigned integers is RECOMMENDED.
>
> SUGGEST:
> Expressing the Global Administrator and Local Administrator values as
> opaque unsigned integers in user interface and reporting (e.g., CLI/YANG)
> is RECOMMENDED.
>
> *[jorge] done.*
>
>
>
>
>
> <discuss-8> Section 4 says:
>
> 551                       +=======+============================+
> 552                       | Value | ISF_SAFI_TYPE              |
> 553                       +=======+============================+
> 554                       | 0     | Gateway PE local ISF route |
> 555                       +-------+----------------------------+
> 556                       | 70    | EVPN                       |
> 557                       +-------+----------------------------+
> 558                       | 128   | SAFI 128                   |
> 559                       +-------+----------------------------+
>
> 561                                      Table 1
>
> Is an IANA registry not required for the ISF_SAFI_TYPE? The text says
> "assigned by this document" but this is not being actually done. Another
> option is to say that these values come from the IANA SAFI registry
> with the exception that the value 0 is used as above and that this
> document recommends the use of only IPVPN and EVPN to avoid introducing
> a new registry.
>
> *[jorge] I think it would be redundant to open an IANA registry for values
> that match an existing registry. Let me know if the following new text
> before the table works for you:*
> *"The non-zero ISF_SAFI_TYPE values come from the IANA SAFI registry.
> These are the values allowed by this document:"*
>
>
> KT> Great. Can you also please add an informative reference to the URL
> https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml next
> to the registry?
> *[jorge] done.*
>
>
>
>
> <discuss-9> Section 4 says:
>
> 728        f.  The number of domains encoded in the D-PATH attribute
> reflects
> 729            the number of Gateway PEs that the corresponding ISF route
> update
> 730            has traversed.  If a transit Gateway PE performs route
> leaking
> 731            between two local tenant IP-VRFs, it MAY prepend a domain
> segment
> 732            to the D-PATH attribute with an ISF_SAFI_TYPE value of 0
> when
> 733            exporting the leaked route into an ISF SAFI.  In such
> cases, the
> 734            total number of domain entries in the D-PATH attribute
> represents
> 735            the number of tenant IP-VRFs through which the ISF route
> update
> 736            has propagated.
>
> I am having some trouble understanding the above procedure. Does
> the Gateway PE strip off the previous D-PATH attribute contents and start
> with
> a fresh one with the Local_ISF_Type of its tenant/domain (considering
> propagation mode)? Or does it still retain the previous contents and
> prepend
> a new domain segment within that same D-PATH attribute. Why is there
> a "MAY" here? If prepending to existing content, is there a problem with
> prepending into the existing Domain Segment? And how come domain entries
> only represent the number of tenant IP-VRFs if gateways were to add domain
> IDs
> as they re-originated the route further?
>
> *[jorge] the text was not very precise. Check the new text now:*
> *"The number of domains encoded in the D-PATH attribute reflects the
> number of Gateway PEs that the corresponding ISF route update has
> traversed. If a transit Gateway PE performs route leaking between two local
> tenant IP-VRFs, it MAY prepend a domain to the D-PATH attribute with an
> ISF_SAFI_TYPE value of 0 when exporting the leaked route into an ISF SAFI. **In
> such cases, the total number of domain entries in the D-PATH attribute
> reflects not only the number of Gateway PEs through which the ISF route has
> been re-originated, but also the number of tenant IP-VRF instances across
> those Gateway PEs."*
>
> *It was decided to use a “MAY” to make the route leaking d-path procedure
> optional, and not force the implementations to do it.*
>
>
> KT> Thanks. It is clear now.
>
>
>
>
> <discuss-10> Section 4 says:
>
> 780            6.  The D-PATH Path Attribute MAY be included only in UPDATE
> 781                messages that carry routes of SAFI 128 (IPVPN) or
> EVPN.  It
> 782                MUST NOT be included with any other AFI/SAFI
> combinations.
> 783                If a D-PATH attribute is received in an UPDATE message
> 784                associated with an unsupported AFI/SAFI, the "treat-as-
> 785                withdraw" procedure MUST be applied, in accordance with
> 786                [RFC7606].
>
> Why not perform "attribute discard" instead? Since, the D-PATH attribute
> has no use in any other SAFI routes, then its presence there is due to an
> error
> or bug. Is the most robust response to such situation not "attribute
> discard"
> so that other speakers don't encouter it as the route propagates further?
> The "treat-as-withdraw" takes out the route/path and will affect the
> functionality or reachability for that BGP prefix.
>
> *[jorge] **During the review by the IDR chairs, this approach was agreed
> to be the safest solution. In earlier versions of the specification, D-PATH
> was supported in SAFI 1 ISF routes. However, following strong feedback from
> the IDR chairs, we agreed to remove D-PATH support for SAFI 1 and apply a
> treat-as-withdraw behavior. While this may impact functionality, a route
> should not have been advertised with D-PATH under SAFI 1 in the first
> place. The presence of such a route (SAFI 1 route with d-path) indicates an
> issue with the advertising speaker. This behavior aligns with the
> implementations we are aware of in current deployments, and we would prefer
> not to modify it (again! 😉) *
>
>
> KT> OK. Please consider this point to be discussed and closed :-)
>
>
>
>
> <discuss-11> Section 4 says:
>
> 845        1.  Upon receiving an ISF route, the gateway PE imports the
> route
> 846            into the associated IP-VRF and stores the original BGP Path
> 847            Attributes.  When advertising the route into a different
> domain,
> 848            the gateway PE SHOULD propagate only the following set of
> 849            attributes.  All other Path Attributes SHOULD NOT be
> propagated:
>
> Have all the current/existing attributes been considered? How about
> ones that would be defined in the future? What if there is a proper
> use-case
> for advertising another attribute? Let's take Edge Metadata Path Attribute
> that is carried from one NVE to another to indicate information about the
> edge resources? I can understand normative text mandating or prohibiting
> propagation of certain specific attributes, but I am concerned with the
> "all
> other" blanket statement. The root issue that I see here is what is
> happening
> at a Gateway PE is "re-origination" and not "propagation". When
> "re-origination"
> is performed, attributes are determined afresh and whether or not
> information
> is copied across would depend heavily on the functionality/specification of
> that attribute (but also community of any type) itself.
>
> *[jorge] This is one of the topics we revisited multiple times.
> Ultimately, we concluded that the safest approach was to permit the
> propagation of a limited and commonly used set of attributes, while
> discouraging indiscriminate copying and re-advertisement, primarily for
> security reasons. The requirement is expressed as a SHOULD rather than a
> MUST to allow some flexibility. However, if you have a better proposal that
> maintains appropriate safeguards while providing more future-proof
> guidance, we would welcome your suggestions.*
>
>
> KT> I agree on the point of guidance and safeguards. Please add text
> before the numbered list to give this guidance. It is straightforward to
> specify SHOULD/SHOULD NOT for specific attributes. The problem is blanket
> statements like allowing all types Extended Communities, Large Communities,
> and Wide Communities - this can be dangerous. Similarly, blanket statements
> to not allow all other path attributes may also be problematic when
> inserting new features. The key part is that there is a contradiction
> between those two statements. Why is any other (new?) attribute problematic
> but any other (new?) Extended Community not problematic? How about instead
> recommending that implementations support route policies at import/export
> that enable filtering or allowing of specific attributes with the default
> to not propagate anything other than the specifically allowed ones?
>
> *[jorge] ok, I think I understand your point fully now.. let me know what
> you think of this modified text:*
>
> "In Uniform Propagation Mode, the Gateway PE retains and copies a
> consistent set of commonly used BGP Path Attributes when re-originating an
> ISF route between domains. This mode is typically employed in deployments
> where IP prefixes are seamlessly distributed using both EVPN and/or IPVPN
> SAFIs. *This specification permits the propagation of a limited set of
> commonly used attributes, while discouraging indiscriminate copying and
> re-advertisement, primarily for security reasons*.
>
> The following normative behavior MUST be followed by a Gateway PE
> operating in Uniform Propagation Mode:
>
>    1.
>
>    Upon receiving an ISF route, and provided that no validation errors
>    are detected and the route is permitted by local policy, the gateway PE
>    imports the route into the associated IP-VRF and retains the original BGP
>    Path Attributes. *When re-advertising the route into a different
>    domain, the gateway PE SHOULD, by default, propagate only the following set
>    of attributes. All other Path Attributes SHOULD NOT be propagated unless
>    explicitly permitted by local import/export policies:*
>    -
>
>       AS_PATH
>       -
>
>       D-PATH (only when advertising IPVPN or EVPN routes)
>       -
>
>       IBGP-only attributes (when advertising to IBGP peers): LOCAL_PREF,
>       ORIGINATOR_ID, CLUSTER_ID
>       -
>
>       MULTI_EXIT_DISC (MED)
>       -
>
>       AIGP [RFC7311
>       <https://author-tools.ietf.org/api/export/31bcef0d-afed-4c3e-9ce2-de081c731035/draft-ietf-bess-evpn-ipvpn-interworking-17.html#RFC7311>
>       ]
>       -
>
>       COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and WIDE_COMMUNITY
>       (as defined in [I-D.ietf-idr-wide-bgp-communities
>       <https://author-tools.ietf.org/api/export/31bcef0d-afed-4c3e-9ce2-de081c731035/draft-ietf-bess-evpn-ipvpn-interworking-17.html#I-D.ietf-idr-wide-bgp-communities>]),
>       except where explicitly excluded in Item 4 below.
>       2.
>
>    When re-advertising an ISF route to an IBGP peer, the gateway PE
>    SHOULD preserve the AS_PATH of the original ISF route without modification.
>    When re-advertising to an EBGP peer, the Gateway PE SHOULD prepend the
>    IP-VRF's ASN to the preserved AS_PATH.
>    3.
>
>    When re-originating an ISF route to IBGP peers, the gateway PE SHOULD
>    retain IBGP-only attributes (e.g., LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID)
>    from the original ISF route. As the route is re-originated, the gateway PE
>    is not required to perform the route reflector function described in [
>    RFC4456
>    <https://author-tools.ietf.org/api/export/31bcef0d-afed-4c3e-9ce2-de081c731035/draft-ietf-bess-evpn-ipvpn-interworking-17.html#RFC4456>
>    ].
>    4.
>
>    As stated in Item 1, the gateway PE SHOULD preserve the COMMUNITY,
>    EXTENDED_COMMUNITY, LARGE_COMMUNITY, and WIDE_COMMUNITY attributes from the
>    original ISF route. However, the following exceptions apply:
>    1.
>
>       BGP Encapsulation Extended Communities, as defined in [RFC9012
>       <https://author-tools.ietf.org/api/export/31bcef0d-afed-4c3e-9ce2-de081c731035/draft-ietf-bess-evpn-ipvpn-interworking-17.html#RFC9012>],
>       SHOULD NOT be propagated.
>       2.
>
>       Route Target Extended Communities SHOULD NOT be propagated and
>       SHOULD be re-initialized when re-advertising the ISF route into a different
>       domain. The re-initialized Route Target value MAY match the value used in
>       the original route.
>       3.
>
>       All EVPN-specific Extended Communities SHOULD NOT be propagated.
>       4.
>
>       *Gateway PEs SHOULD support import/export policies capable of
>       matching COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and WIDE_COMMUNITY
>       values to permit or deny their propagation between domains when the default
>       propagation behavior needs to be overridden."*
>
>
>
>
>
> Please see the comments section for some issue related to similar blanket
> statements about communities.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please also find below comments provided inline in the idnits text of v15
> of
> the document. Look for the tag <EoRv15> at the end of the email to ensure
> you
> have the full review.
>
> Some of these comments are minor/editorial/nits but I hope the authors will
> consider to improve the clarity, correctness and readability of this
> document.
>
> 25         tenant networks.  When a tenant network spans multiple domains —
> 26         including EVPN domains as well as domains that use BGP VPN-IP
> or IP
> 27         address families for inter-subnet forwarding — it becomes
> necessary
> 28         to define the interworking mechanisms among these BGP domains
> (EVPN,
> 29         VPN-IP, and IP) to ensure seamless end-to-end tenant
> connectivity.
>
> 31         In addition, this document defines a new BGP Path Attribute,
> referred
>
> <minor> Perhaps you meant to say that "This document defines the
> interworking
> ..." And then the above sentence with "In addition, this document defines
> ..."
> would make sense? Please consider rephrasing the last sentence of the first
> paragraph (it would also make it easier to read and remove those '-‘).
>
> *[jorge] done.*
>
> 123        between domains without proper safeguards.  For example, if
> gateway
> 124        PE1 imports a VPN-IP route for a given prefix and redistributes
> it as
> 125        an EVPN IP Prefix route into the EVPN domain, and a second
> gateway PE
> 126        (PE2) receives this EVPN route and re-advertises it back into
> the
>
> <nit> Perhaps ... second gateway PE2 ?
>
> *[jorge] done.*
>
> 131        The D-PATH attribute alters the BGP best path selection logic
> for
> 132        Multiprotocol BGP routes of SAFI 128 (VPN-IPv4/IPv6) and for
> EVPN IP
> 133        Prefix routes.  Accordingly, this document updates the BGP best
> path
> 134        selection procedures specified in [RFC4271], but only in the
> context
> 135        of IPVPN and EVPN families.
>
> <major> There are far too many occurrences of 'SAFI 128' in the document
> and
> almost all of them also indicate that the reference is to 'IPVPN'. On the
> other
> side there is only one reference to 'SAFI 70' in the terminology section
> where
> ISF SAFI is explained and the rest of the document simply says 'EVPN'. I
> found
> this contrast strange and also a bit jarring. Why not treat IPVPN and EVPN
> the
> same and indicate their SAFIs just once in the terminology section?
>
> *[jorge] done.*
>
> 145        When interworking with other BGP address families for
> inter-subnet
> 146        forwarding, the IP prefixes conveyed in these EVPN route types
> must
> 147        be propagated into corresponding address families (e.g.,
> VPN-IP), and
>
> <minor> s/must be propagated into/are propagated into ? (but please also
> see
> the discuss-4 point)
>
> *[jorge] done.*
>
> 200           |                +------------------+          |
> SAFIs       |
> 201           |                                              |  1
> +---+ |
> 202         -------------------------------------------------+  128
> |BGP| |
> 203           |                                                 EVPN
> +---+ |
> 204
> |                                                             |
> 205
> +-------------------------------------------------------------+
>
> 207                         Figure 1: EVPN-IPVPN Interworking PE
>
> <minor> There is an inconsistency in the figure when referring to the
> SAFIs.
> Either refer to all of them as numbers or names but not a mix of both. I
> would prefer names to numbers.
>
> *[jorge] done.*
>
>
> 209        *  ISF SAFI: the Inter-Subnet Forwarding (ISF) Subsequent
> Address
> 210           Family Identifier (SAFI) defines an MP-BGP Sub-Address
> Family used
> 211           to advertise IP prefix reachability for inter-subnet
> forwarding
> 212           within a tenant network.  The SAFIs used for ISF include 1
> 213           (applicable only to IPv4 and IPv6 AFIs), 128 (applicable
> only to
> 214           IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI
> 25).
> 215           This document uses the following terms interchangeably: ISF
> SAFI 1
> 216           or BGP IP, ISF SAFI 128 or IPVPN, ISF SAFI 70 or EVPN.
>
> <minor> Is it possible to use the terms IP Route, VPN Route, and EVPN Route
> (and for the SAFI names IP Unicast, IPVPN, and EVPN)? Once those terms are
> clarified in this section, the rest of the document will become much more
> readable by de-cluttering the SAFI references and SAFI numbers (also the
> innumerable instances of examples). This also takes care of different terms
> being used interchangeably.
>
> *[jorge] We tried to remove SAFI 128 throughout the document and use IPVPN
> and IPVPN routes. Hopefully it reads better now.*
>
>
> KT> Yes. Thanks. Please check for some instances of "VPN-IP" that probably
> should be replaced by IPVPN?
> *[jorge] done.*
>
>
>
>
> 218        *  ISF route: a route for a given prefix, whose ISF SAFI may
> change
> 219           as it transits different domains.  BGP IP routes as in
> [RFC4760]
> 220           [RFC8950], IPVPN routes as in [RFC4364], [RFC4659], EVPN IP
> Prefix
> 221           routes as in [RFC9136] or EVPN MAC/IP Advertisement routes
> when
> 222           they are programmed within an IP-VRF [RFC9135], are
> considered ISF
> 223           routes in this document.
>
> <major> Note that what BGP is used for "IP routes", IPVPN and EVPN - all of
> them. Please consider s/BGP IP Routes/IP Unicast Routes ? ... that is what
> SAFI
> 1 is for.
>
> *[jorge] We removed SAFI 1 as you requested, please check out the new
> text.*
>
> 233           (RTs), which are required attributes for its operation.
> These RD
> 234           and RT values are typically distinct from those used by any
> 235           associated IP-VRF, when such an IP-VRF is linked to the
> MAC-VRF
> 236           through a Bridge Table via an Integrated Routing and Bridging
> 237           (IRB) interface.
>
> <major> This is the first reference to IRB (baring the figure). Please
> consider
> adding reference to RFC9135.
>
> *[jorge] done.*
>
> 253        *  Ethernet Tag: used to represent a Broadcast Domain.
>
> <major> Please consider adding RFC7432 as reference for the term Ethernet
> Tag
> (at least here but perhaps also in the description of BT above). In
> general,
> please review other similar terms (e.g., EVI) in this section and provide
> the
> appropriate RFC references against them.
>
> *[jorge] done.*
>
> 267        *  IRB: Integrated Routing and Bridging interface.  It refers
> to the
> 268           logical interface that connects a BT to an IP-VRF and allows
> to
> 269           forward packets with destination in a different subnet.
>
> <major> Does IRB stand for 'Integrated Routing and Bridging' (as in the
> feature
> or technology) or 'Integrated Routing and Bridging Interface'? I find the
> usage
> inconsistent in RFC9135, but most of the text in that document seems to
> refer
> to the technology and the 'interface' suffix is added when the reference is
> to the interface. Can you please review and bring consistency in this
> document?
>
> *[jorge] I think it is now consistent at least in this document.*
>
> 271        *  MPLS/NVO tunnel: A tunnel that may be based on either MPLS
> or a
> 272           Network Virtualization Overlay (NVO) technology.  Such
> tunnels are
> 273           utilized by both MAC-VRFs and IP-VRFs.  Regardless of the
> 274           underlying tunneling technology, the tunnel may carry either
> 275           Ethernet or IP payloads.  MAC-VRFs are restricted to using
> tunnels
> 276           that carry Ethernet payloads - Ethernet NVO Tunnels
> [RFC9136] -
> 277           which are typically established via EVPN signaling.  In
> contrast,
> 278           IP-VRFs may utilize tunnels carrying Ethernet payloads -
> Ethernet
> 279           NVO Tunnels [RFC9136], signaled via EVPN - or IP payloads -
> IP NVO
> 280           Tunnels [RFC9136], signaled via EVPN or IPVPN mechanisms.
> IPVPN-
> 281           only PE devices support IP-VRFs but do not support sending or
> 282           receiving traffic over tunnels carrying Ethernet payloads.
>
> <major> I see RFC9014 as an informative reference but not really used
> anywhere.
> I would like to check if it was meant to be used as a reference perhaps in
> the
> above paragraph? If not, please remove that unused reference.
>
> *[jorge] removed.*
>
> 285           tunnel to transport Ethernet frames associated with
> MAC-VRF1.  The
> 286           PE device identifies the corresponding MAC-VRF and BT based
> on the
> 287           EVPN label, either an MPLS label or a Virtual Network
> Identifier
> 288           (VNI), depending on the encapsulation type.  Additionally,
>
> <major> Also SRv6 SID when using SRv6 encapsulation? Although perhaps this
> document does not need to get into the details of the encapsulation?
>
> *[jorge] added SRv6 consistently in the document.*
>
> 301        *  NVE: Network Virtualization Edge router.
>
> <major> NVE term needs RFC9136 reference?
>
>
> *[jorge] added RFC8365 *
> 376        *  Regular PE: A PE that is attached to a domain, either
> regular or
> 377           composite, and which uses one of the control plane protocols
> (BGP
> 378           IP, IPVPN or EVPN) operating in the domain.
>
> <major> S/control plane protocols/control plane ISF SAFI ... the control
> plane
> is BGP all through.
>
>
> *[jorge] done. *
> 380        *  Interworking PE: A PE device that is capable of advertising a
> 381           given IP prefix using one or more of the following route
> types: an
> 382           EVPN Inter-Subnet Forwarding (ISF) route, either an EVPN
> MAC/IP
> 383           Advertisement route or an EVPN IP Prefix route-an IPVPN ISF
> route,
>
> <nit> s/route-an IPVPN/route, an IPVPN
>
> *[jorge] done.*
>
>
> <minor> There is unnecessary repetition of terms here and through the
> document
> text that affects readability. Once the term ISF Route is defined above,
> why
> not use that and simplify the text and improve readability?
>
> 399           Example: Figure 1 shows an interworking PE of type gateway,
> where
> 400           ISF SAFIs 1, 128 and 70 are enabled.  IP-VRF1 and MAC-VRF1
> are
> 401           instantiated on the PE, and together provide inter-subnet
> 402           forwarding for the tenant.
>
> <minor> The example above introduces the gateway type but that type is
> defined
> further below. Perhaps it can just say 'interworking PE' without getting
> into
> the type just yet?
>
> *[jorge] done.*
>
> 404        *  Composite PE: An Interworking PE device that is connected to
> a
> 405           composite domain and is capable of advertising a given
> prefix to
> 406           multiple types of peers using appropriate route types.
> 407           Specifically, a Composite PE advertises the prefix to an
> IPVPN
> 408           peer using an IPVPN ISF route, to an EVPN peer using an EVPN
> ISF
> 409           route, and to a route reflector using both IPVPN and EVPN ISF
>
> <major> This assumes that the same RR is used for IPVPN and EVPN (as in
> Figure 4
> below). Can you please state this since RR is also a peer (unless you
> meant to
> use PE instead of peer).
> *[jorge] done.*
>
> 439           -  Propagates ISF routes using the same ISF SAFI, such as
> BGP IP,
> 440              IPVPN, or EVPN, between the connected domains.
>
> 442           -  Translates and propagates an ISF route received with one
> ISF
> 443              SAFI to a domain that uses a different ISF SAFI.  For
> example,
> 444              a received EVPN ISF route may be propagated as an IPVPN
> ISF
> 445              route, and vice versa.
>
> <minor> The above two bullets unnecessary repeat things already clarified
> previously in the terminology section (i.e., ISF route and ISF SAFI). Such
> repetition here and throughout this document just makes it verbose but also
> affects readability. I'll stop pointing this out again, but please consider
> cutting out all of this endless repetition - all the "for examples" can
> just be removed?
> *[jorge] done.*
>
> 467        *  Composite/Gateway PE: An Interworking PE device that
> 468           simultaneously performs the functions of both a Composite PE
> and a
> 469           Gateway PE.  This type of PE is connected to two domains: one
> 470           regular domain and one composite domain.  It operates as
> follows:
>
> 472           -  Propagates an ISF route received from the regular domain
> into
> 473              the composite domain.  Within the composite domain, it
> performs
> 474              the behavior of a Composite PE.
>
> 476           -  Propagates an ISF route received from the composite
> domain into
> 477              the regular domain.  In the regular domain, the route is
> 478              advertised using the ISF SAFI applicable to that domain.
>
> 480           This functionality is particularly useful in scenarios where
> a
> 481           tenant network spans multiple domains using different ISF
> SAFIs
> 482           (e.g., BGP IP, IPVPN, and EVPN), and where any-to-any tenant
> 483           connectivity is required.  In such deployments, maintaining
> 484           consistent end-to-end control plane behavior across domains
> is
> 485           desirable when feasible.
>
> <minor> Please consider if it is possible to include an example here - it
> would
> really be helpful (a mix of figures 4 and 5 perhaps?).
>
> *[jorge] done.*
>
> 551                       +=======+============================+
> 552                       | Value | ISF_SAFI_TYPE              |
> 553                       +=======+============================+
> 554                       | 0     | Gateway PE local ISF route |
> 555                       +-------+----------------------------+
> 556                       | 70    | EVPN                       |
> 557                       +-------+----------------------------+
> 558                       | 128   | SAFI 128                   |
>
> <major> Why not call it IPVPN instead of SAFI 128 ? After all, that is
> what is
> used in the procedures section further below.
>
> *[jorge] done.*
>
> 567        Gateway PEs.  In addition, D-PATH:
>
> <minor> This "In addition, D-PATH:" does not parse for many of the bullets
> below. Since these are D-PATH related procedures, how about - "The rest of
> this
> section specifies the D-PATH related procedures." (or something like that)
> and
> then fix the opening sentences for a few of the bullets?
>
> *[jorge] done.*
>
>
> 592            *  In order to minimize the number of segments in the D-PATH
> 593               attribute, the local gateway PE prepends its own domain
> as the
>
> <major> Why not "... gateway PE MUST prepend its own domain as ...” ?
>
> *[jorge] done.*
>
> 599        b.  Is added/modified by a gateway PE when propagating an
> update to a
> 600            different domain (which runs the same or different ISF
> SAFI):
>
> <major> Unlike the previous bullet (a), the sub-bullets under (b) use
> examples
> instead of normative text to describe what are normative procedures.
> Suggest to
> follow the way in which both normative text and examples are used
> independently
> as done in the case of (a).
>
> *[jorge] done.*
>
> 631        c.  For a local ISF route, i.e., a configured route or a route
> 632            learned from a local attachment circuit, a gateway PE
> following
>
> <major> It is not clear whether "local" here means only prefixes that are
> configured on one the local interfaces or ACs. Or can it also include say
> locally configured static routes that are redistribute.
>
> *[jorge] added:*
> *"For a local ISF route, i.e., a configured static route or a route
> learned from a local attachment circuit"*
>
> 633            this specification has three choices:
>
> <major> Only these 3 choices or are there more? The MAYs in the 3 choice
> allow
> for other unspecified options.
>
> *[jorge] removed the MAYs*
>
> 672            *  The route MAY be installed in the IP-VRF only if it is
>
> <major> perhaps s/route MAY be installed/route is installed ?
>
> *[jorge] done.*
>
> 755                *  The total length of the D-PATH attribute is less than
> 756                   eight octets.
>
> <minor> Doesn't the above bullet fit better under (1) than (2)?
>
> *[jorge] done*
>
> 788        h.  The use of the D-PATH attribute is restricted to "walled
> garden"
> 789            Virtual Private Network (VPN) deployments.  An operator
> MUST NOT
> 790            enable the generation of D-PATH attributes in conjunction
> with
> 791            IPVPN and/or EVPN routes if any CE devices connected to a PE
> 792            device, belonging to any domain within the VPN, is also
> connected
> 793            to the public Internet.
>
> <major> I do not follow this. How is the provider operator going to
> determine
> what all a particular customer CE is doing. It is very much likely that a
> CE
> is also peering with another independent ISP for Internet. What is required
> here is that implementations by default strip the D-PATH attribute when
> advertising from a VRF instance on a PE towards the CE - this should
> normally
> happen anyway since the PE-CE session is IP Unicast SAFI? After all, this
> seems
> to be what is indicated in the Security Considerations. Isn't this an
> inconsistencies?
>
> *[jorge] it is again text that was agreed with the IDR WG chairs, they
> wanted the readers to be extra cautious with the use of D-PATH. *
>
>
> KT> That may be so. However, the text is not clear and is in the normative
> procedures with some things needlessly repeated in multiple places. The
> text seems like a false warning label that someone wanted to stick at a
> place that does not gel with the document.  Let us break things down:
>
> The use of the D-PATH attribute is restricted to "walled garden" Virtual
> Private Network (VPN) deployments.
>
> Why is it needed when there is the following text in the same section. And
> then this "walled garden" text is also there in security considerations.
>
> The BGP D-PATH attribute is supported on ISF routes of type IPVPN and EVPN
> and MUST NOT be advertised along with routes different from IPVPN and EVPN
> routes.
>
> Then we have
>
> An operator MUST NOT enable the generation of D-PATH attributes in
> conjunction with IPVPN and/or EVPN routes if any CEs connected to a PE,
> belonging to any domain within the VPN, is also connected to the public
> Internet.
>
> How does the provider know what all the CE is doing? Is the CE always
> managed by the provider? Most importantly, this statement is moot. The
> point is that PE talks SAFI 1 to CE and it MUST NOT send D-PATH to the CE.
> This is covered already. So, then I just don't understand the difference
> whether the CE is connected to the public Internet or not. This is all
> discussed with proper text in the security considerations. Please just
> remove point h and let's be done with it? Unless you believe that I am
> missing something?
>
> *[jorge] After re-reading the entire section and the security
> considerations again, I think you are absolutely right. I removed point h.
> Thank you very much for dissecting the point and explaining it so clearly.*
>
>
>
>
> 838        advertising an ISF route between domains.  This mode is
> typically
> 839        employed in deployments where IP prefixes are seamlessly
> distributed
> 840        using both EVPN and IPVPN SAFIs.
>
> <major> Is it "using both EVPN and IPVPN" or "only when using EVPN and/or
> IPVPN" ? i.e., not used when using IP Unicast.
>
> *[jorge] used “and/or"*
>
> 878        4.  As stated in Item 1, the gateway PE SHOULD preserve the
> 879            COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and
> 880            WIDE_COMMUNITY attributes from the original ISF route.
> However,
> 881            the following Extended Community types SHOULD NOT be
> propagated::
>
> <major> Similar to the attributes (please see discuss-11), I am wondering
> how
> this document can put a blanket statement about preservation of all these
> types of communities (current and future). Should it not depend on the
> functionality of the community? I can understand the exceptions for not
> propagating some of the communities that are typically used with
> IPVPN/EVPN -
> although even those really don't need to be specified as they are obvious
> based
> on their functionality. e.g., it is obvious that the RTs to be used as
> determined via the IP-VRF configuration when re-originated from the VRF.
>
> *[jorge] please check the new text, if you have better suggestions, please
> let us know.*
>
>
> KT> Please see my response to <discuss-11>
> *[jorge] hope the new text addresses this point.*
>
>
>
>
> 886            b.  Route Target Extended Communities.  Route Targets MUST
> NOT be
> 887                propagated and MUST be re-initialized when
> re-advertising the
> 888                ISF route into a different domain.  The re-initialized
> Route
> 889                Target value MAY or MAY NOT match the value used in the
> 890                original route.
>
> <major> Incorrect use of BCP14 keyword. I would suggest the following since
> "MAY" implicitly allows the possibility of "MAY NOT":
>
> The re-initialized Route Target value MAY match the value used in the
> original
> route.
>
> *[jorge] done.*
>
> 892            c.  All EVPN-specific Extended Communities.
>
> <major> Are we sure that no current or future EVPN-specific ECs are to be
> propagated even when the ISF SAFIs of both domains is EVPN (say with
> different
> encapsulation so they need the gateway function)?
>
> *[jorge] Future specifications may decide whether to make an exception for
> new EVPN ext communities. If you have a better suggestion please, let us
> know. *
>
>
> KT> This is ok. It is upto that future specification to cover. The same
> can be perhaps incorporated to the main point here which is <discuss-11> ?
> *[jorge] hope the new text addresses this point too.*
>
>
>
>
> 897        5.  For a given ISF route, only the BGP Path Attributes
> associated
> 898            with the best path MAY be propagated when re-advertising the
> 899            route into a different domain.  If multiple paths are
> received
> 900            for the same prefix within the same ISF SAFI, the standard
> BGP
> 901            best path selection procedure MUST be applied to determine
> the
> 902            active path and its associated attributes.  Even when
> Equal-Cost
> 903            Multi-Path (ECMP) is enabled for the IP-VRF, only the Path
> 904            Attributes of the selected best path SHALL be propagated.
>
> <major> SHALL = MUST. Is that a MUST or a SHOULD? What would be the issue
> if an implementation picks the attributes from any one of the ECMP paths?
>
> *[jorge] added SHOULD to allow minor flexibility, but it is good to have
> consistency in implementations.*
>
> <major> I am probably missing something, but what about (5) is new or
> specific
> to interworking between EVPN/IPVPN or interconnecting multi-domains? Is
> this
> not standard BGP (albeit I cannot remember where this is specified).
>
> *[jorge] since the propagation of path attributes in gateways is new in
> this spec, we think it needs to be specified here.*
>
> 940        *  The Community, Extended Community, Large Community and Wide
> 941           Community attributes of an aggregated ISF route SHOULD
> include the
> 942           union of the corresponding attributes from all constituent
> ISF
> 943           routes that were aggregated, with the exception of those
> Extended
> 944           Community types explicitly excluded from propagation as
> specified
> 945           in Section 5.2.
>
> <major> This is another blanket statement for all types of communities
> being
> handled in a particular way during aggregation without regards to the
> semantics
> of those specific ECs. Consider Link Bandwidth EC. Is this handling
> appropriate?
>
> *[jorge] added:*
> *"...**or those for which the applicable specifications define different
> handling."*
>
> 947        *  For other attributes, rules in [RFC4271] are followed.
>
> <major> Why only RFC4271? What about attributes from RFC4456 or other RFCs
> (currently available or those coming in future) that would introduce new
> attributes?
>
>
> *[jorge] added “...or the attribute applicable specifications are
> followed." *
> 1100           Composite PEs MUST advertise the same IP prefixes using
> each ISF
> 1101           SAFI to the Route Reflector (RR).  For example, as shown in
> 1102           Figure 7, the prefix IP1/24 is advertised by PE1 and PE2 to
> the
> 1103           Route Reflector in two separate NLRI entries: one for
> AFI/SAFI
> 1104           1/128 (IPVPN) and another for EVPN.  If both routes are
>
> <major> This seems to preclude a design where different RRs are used for
> different ISF SAFIs. It probably does not matter to the composite PE but
> would be good to clarify that such an alternate design is possible.
>
> *[jorge] done.*
>
> 1157       6.  Applicability of EVPN Forwarding Enhancements
> 1158           In composite domains such as the one depicted in Figure 7,
> the
> 1159           advanced forwarding features provided by EVPN are available
> only
> 1160           to composite and EVPN-capable PEs that select an EVPN IP
> Prefix
> 1161           route as the best path.  These enhancements are not
> available to
> 1162           IPVPN-only PEs.  For example, if PE1 advertises IP1/24
> using both
> 1163           EVPN and IPVPN routes, and the EVPN route is selected as
> the best
> 1164           path, only composite PEs such as PE2 and PE4 can leverage
> EVPN-
> 1165           specific recursive resolution and forwarding mechanisms.
> IPVPN
> 1166           PEs, such as PE3, cannot utilize these capabilities.
> 1167           Consequently, the benefits of EVPN-based indirection and
> route
> 1168           resolution in large-scale deployments may not be available
> 1169           uniformly across all PEs in the network.
>
> <minor> Can you please provide reference so the reader can understand these
> EVPN Forwarding Enhancements?
>
> *[jogre] added reference to RFC9136*
>
> 1256               specification.  For example, an EVPN IP Prefix route
> that
> 1257               contains both a non-zero EESI and a Gateway IP address
> is
>
> <nit> s/EESI/ESI
>
> *[jorge] done*
>
> 1296       b.  The gateway PE MAY use the Route Distinguisher (RD) of the
> IP-VRF
> 1297           when re-advertising prefix P via ISF SAFI y.
>
> <minor> Why MAY? What are the other options? How about "The gateway PE
> uses the
> Route Distinguisher …"
>
> *[jorge] ok*
>
> 1299       c.  Label allocation for route advertisement is an
> implementation-
> 1300           specific matter.  The gateway PE MAY use per-VRF,
> per-prefix, or
>
> <major> Is it an implementation-specific or a local matter? How about for
> other
> encapsulation types - VNI and SRv6 SIDs? Perhaps this can be abstracted as:
> "The encapsulation specific context (e.g., label) allocation is a local
> matter.”
>
> *[jorge] done.*
>
> 1309       e.  Although Figure 8 illustrates a scenario with only two
> domains
> 1310           per gateway PE, gateway PEs MAY interconnect more than two
> 1311           domains.
>
> <minor> Perhaps ... gateway PEs may/can interconnect more … ?
>
> *[jorge] done.*
>
> 1316       g.  If Uniform Propagation Mode is used for BGP Path Attribute
> 1317           propagation, the gateway PE MUST follow the procedures
> defined in
> 1318           Section 5.2 in addition to the D-PATH specific behavior
> described
> 1319           in item (a).
>
> <minor> I am not sure what (g) provides more than (a). Perhaps consider
> combining?
>
> *[jorge] combined.*
>
> 1371            Figure 9: Gateway and composite combined functions -
> example
>
> 1373       In the example illustrated, PE1 and PE2 MUST follow the
> procedures
>
> <major> Please don't mix normative text and examples. The normative text
> should
> stand on its own and then the examples clarify.
>
>
> *[jorge] removed *
> 1384    10.  BGP Error Handling on Interworking PEs
>
> 1386       An Interworking PE, whether operating in a Gateway PE or
> Composite PE
> 1387       role, MUST adhere to the following error-handling procedures
> when
> 1388       processing Inter-Subnet Forwarding (ISF) routes:
>
> <major> Why just interworking PE? Aren't some of these procedures also
> applicable for other BGP Speaker roles such as RR or normal ingress/egress
> PEs
> or even ASBRs? i.e., for the new D-PATH attribute.
>
> *[jorge] changed to BGP speakers*
>
> 1401          type.  Applicable references include::
>
> 1403             BGP IP routes: [RFC4760], [RFC8950].
>
> 1405             IPVPN routes: [RFC4364], [RFC4659].
>
> 1407             EVPN MAC/IP Advertisement routes (Route Type 2):
> [RFC7432],
> 1408             [RFC8365].
>
> 1410             EVPN IP Prefix routes (Route Type 5): [RFC9136].
>
> 1412             ISF routes installed in IP-VRFs with SRv6 forwarding:
> 1413             [RFC9252].
>
> <major> I think trying to list specific ISF Routes and provides pointers is
> going to be tricky. EVPN error handling is coming only in the RFC7432bis.
> Perhaps consider skipping the specific references above since this document
> needs to cover only what is newly introduced or new procedures.
> *[jogre] ok, removed.*
>
> 1448    11.  Conclusion
>
> <minor> Conclusion section seems odd. This text, however, would fit nicely
> in
> the introduction section and be helpful for the reader.
>
> *[jorge] there was another suggestion to change it to summary, and that’s
> what we did. Let us know if it is ok*
>
>
>
> KT> I leave it to the editors. This becoming an RFC, I would have liked to
> see this in the introduction. If it were a presentation, then a summary at
> the end as a reminder/recap is very apt.
> *[jorge] ok, I gave it a try. Moved the text to the end of the
> introduction section. Let me know if it reads better this way.*
> *Thank you!*
> *Jorge*
>
> Thanks,
> Ketan
>
>
>
>
>
> 1564    15.  Contributors
>
> <nit> please remove empty contributors section
>
> *[jorge] done.*
>
> <EoRv15>
>
>
>
>