Subject: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 20 Oct 2021 22:49:32 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: 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/blog/handling-iesg-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-bum-procedure-updates/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm not sure whether the Leaf A-D route (route type specific field) as
specified by this document is guaranteed to have a unique
interpretation (§3.3).  It's supposed to start with the "route key",
which is just the route-type-specific field of the PMSI route that
triggered the Leaf A-D route.  That makes the route key variable length
(as stated), and this variation is clearly achieved given that even the
Per-Region I-PMSI A-D route and S-PMSI A-D route defined in this
document have different length and layout.  I'm not sure what
information is expected to be available to bound and determine the
length of this "route key" field, other than "not the rest of the
stuff".  "The rest of the stuff" is the originator's address and length
thereof, but the length is in the middle of the structure, so even if we
start parsing from the back we still can't distinguish reliably between
a 4-byte IPv4 address and a 16-byte IPv6 address.  It seems that the
Originator's Addr Length would need to be the last field in order to
provide a unique interpretation, with "parse backwards" used to extract
the Originator's Address, and "the rest of the stuff" being the route
key that can be matched to the triggering PMSI route.  Is there some
other procedure or contextual information available that ensurs a unique
interpretation of this data?  Looking at RFCs 6514 and 7117, it does not
seem like this document has some key change that renders it
fundamentally different in this regard, so I mostly assume that the
received route can be disambiguated somehow; I just don't know what that
way is.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

   It is expected that audience is familiar with EVPN and MVPN concepts
   and terminologies.  For convenience, the following terms are briefly

Please provide references for EVPN and MVPN that would serve as entry
points for gaining such familiarity.  E.g., RFCs 7432 and 6513/6514.

   explained.

I suggest including PMSI Tunnel Attribute in this list, especially since
RFC 6514 does not actually use the PTA acronym.

Section 2.1

   There is a difference between MVPN and VPLS multicast inter-as
   segmentation.  For simplicity, EVPN will use the same procedures as
   in MVPN.  All ASBRs can re-advertise their choice of the best route.

While it is defensible to rely on the stated expectation that the reader
is familiar with EVPN and MVPN concepts (hmm, which does not actually
include VPLS concepts?), it would be appreciated to include some
indication of the nature of the difference, before stating which variant
EVPN will use.

   For inter-area segmentation, [RFC7524] requires the use of Inter-area
   P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
   of "Leaf Information Required" L flag in PTA in certain situations.
   Either of these could be optional in case of EVPN.  Removing these

"Could be"?  It sometimes is and sometimes isn't?  When is it still
mandatory?

Section 2.1.1

   For example, an MVPN/VPLS/EVPN network may span multiple providers
   and Inter-AS Option-B has to be used, in which the end-to-end

Is this "option (b)" of §7.2 of RFC 7117?  Regardless, a specific
reference seems in order.

   Another advantage of the smaller region is smaller BIER sub-domains.
   In this new multicast architecture BIER [RFC8279], packets carry a

RFC 8279 was published just about four years ago.  Does that still
qualify as "new"?  (I honestly am not sure, given the distribution of
time from -00 to RFC.)

Section 3

   The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
   starts with a type 1 RD, whose Administrator sub-field MUST match
   that of the RD in all non-Leaf A-D (Section 3.3) EVPN routes from the
   same advertising router for a given EVI.

Is the requirement really so specific as "everything except Leaf A-D"?
What if some new type is allocated that also doesn't start with an RD?
Is it safe to say that any type that does have an RD must meet this
criterion?

Section 4

   The optional optimizations specified for MVPN in [RFC8534] are also
   applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are
   used for EVPN selective multicast forwarding.

Are we going to need a
draft-ietf-something-bum-procedure-further-updates in another five years
to perform the same type of "gap filling" that this document is doing
for how RFC 7432 referred to the RFC 7117 procedures?

Section 5.1

   The above VPLS behavior requires complicated VPLS specific procedures
   for the ASBRs to reach agreement.  For EVPN, a different approach is
   used and the above quoted text is not applicable to EVPN.

What about the text we didn't quote, that places MUST-level requirement
on the "best route selection procedures" that determine whether a given
ASBR re-advertises the route within its own AS?

      "The PMSI Tunnel attribute MUST specify the tunnel for the segment.
      If and only if, in order to establish the tunnel, the ASBR needs to
      know the leaves of the tree, then the ASBR MUST set the L flag to
      1 in the PTA to trigger Leaf A-D routes from egress PEs and
      downstream ASBRs. It MUST be (auto-)configured with an import RT,
      which controls acceptance of leaf A-D routes by the ASBR."

It seems like we might want to make some further statement about what
scope that import RT is expected to limit acceptance of the route to.

Section 5.2

   considered as leaves (as proxies for those PEs in other ASes).  Note
   that in case of Ingress Replication, when an ASBR re-advertises IMET
   A-D routes to IBGP peers, it MUST advertise the same label for all
   those for the same Ethernet Tag ID and the same EVI.  When an ingress

This seems like an eminently reasonable thing to require.  I wonder if
it's worth saying a little more about why it is required, though -- what
breaks if you don't do this?

   PE builds its flooding list, multiple routes might have the same
   (nexthop, label) tuple and they MUST only be added as a single branch
   in the flooding list.

I'm not entirely confident that I could implement this behavior for the
flooding list right now.  On the other hand, I also haven't written any
BGP code, so maybe it's expected that I couldn't implement it, but it
still seems like this might be glossing over some details.

Section 5.3

   o  An egress PE sends Leaf A-D routes in response to I-PMSI routes,
      if the PTA has the L flag set (by the re-advertising ASBRs).

I don't think I understand the parenthetical.  Which previous text is it
intending to refer to?

Additionally, while we mention in the first paragraph of §5.2 the RFC
7432 requirement to not set the L flag in IMET A-D routes, I don't see
where we lift that requirement for the segmented procedures.  The change
in §5.1 to let the ASBR set the L flag does not seem constructed in a
way that lifts the requirement from §11.2 of RFC7432.

   To address this backward compatibility problem, the following
   procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
   A-D routes):

Can be used, but is in no way mandatory, not even to implement?  That's
rather surprising.

   o  The ASBRs in an AS originate per-region I-PMSI A-D routes and
      advertise to their external peers to advertise tunnels used to
      carry traffic from the local AS to other ASes.  Depending on the

This may or may not just be a grammar nit: *what* do the ASBRs advertise
to their external peers to advertise tunnels?  (Are we just missing
"them" for "advertise them"?)

Section 6.3

   [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
   to change the BGP next hop when they re-advertise I/S-PMSI A-D routes

I failed to find any place where RFC 7524 used the string "S-NH-EC", and
suggest writing out "Segmented Next-Hop Extended Community" somewhere.

Section 9

I would posit that at least some of the security considerations from RFC
6513 are relevant here, in addition to the (already mentioned) 6514
considerations.

Section 12.1

I do not think that RFC 7988 needs to be classified as normative; we
reference it only once, in an example; RFCs 4875 and 6388 are used in
the same way for the same example, but are classified as informative.

Section 12.2

I don't see what's different between RFCs 6513 and 6514 to make the
latter normative while the former is informative -- they are referenced
in largely the same places, and often.

NITS

Abstract

   This document specifies procedure updates for broadcast, unknown
   unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

I'd suggest NEW:

 This document specifies updated procedures for handling broadcast,
 unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),

Section 1

   o  IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D
      route.  The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route.

I would say that a de novo explanation is likely to be of more general
applicability than a dense MVPN reference.  Perhaps "Advertised by PEs
to enable reception of BUM traffic for a given VLAN" or similar?

   o  SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective
      Multicast Ethernet Tag A-D route.  The EVPN equivalent of MVPN
      Leaf A-D route but unsolicited and untargeted.

Likewise, this might be something like "Advertised by PEs to indicate
that the indicated BUM traffic should be sent to the advertising PE."

Section 2

   [RFC7117] specifies procedures for Multicast in Virtual Private LAN
   Service (VPLS Multicast) using both inclusive tunnels and selective
   tunnels with or without inter-as segmentation, similar to Multicast
   VPN (MVPN) procedures specified in [RFC6513] and [RFC6514].

s/to Multicast/to the Multicast/

Section 2.1.1

   Segmentation can also be used to divide an AS/area to smaller
   regions, so that control plane state and/or forwarding plane state/

s/to smaller/into smaller/

Section 4

   of egress PEs for selective forwarding with BIER).  An NVE proxies
   the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or
   (C-*,C-G) SMET routes and advertises to other NVEs, and a receiving

I think s/and/that it/

   NVE converts the SMET routes back to IGMP/MLD messages and send them

s/send/sends/

Section 5.3

   o  An ingress PE uses the Next Hop instead of Originating Router's IP
      Address to determine leaves for the I-PMSI tunnel.

It was not previously required to use Originating Router's IP Address,
so maybe s/instead of/and not use/.

Section 6.1

   changes the next hop to its own address and changes PTA to specify
   the tunnel type/identification in the neighboring region 3.  Now the

I'm not sure that we ever explicitly named the region.  We implicitly do
in the following figure that says "segment 3", but the number and string
"region" don't seem paired anywhere directly.

Section 6.2

   propagated to other regions.  If multiple RBRs are connected to a
   region, then each will advertise such a route, with the same route
   key (Section 3.1).  Similar to the per-PE I-PMSI A-D routes, RBRs/PEs

Mention of route key seems to be in §3.3, not 3.1.

Section 6.3

   NH-EC.  The advantage of this is that neither ingress nor egress PEs
   need to understand/use S-NH-EC, and consistent procedure (based on
   BGP next hop) is used for both inter-as and inter-region
   segmentation.

s/consistent/a consistent/

Section 7

   including Ingress Replication.  Via means outside the scope of this
   document, PEs know that ESI labels are from DCB and existing multi-
   homing procedures work as is, whether a multi-homed Ethernet Segment
   spans across segmentation regions or not.

I'm not sure this is a well-formed sentence.  Is it supposed to be a
list?  Or just two things that PEs know OOB: (ESI labels are from
existing multi-homing procedures work as is) and (whether or not a
multi-homed Ethernet Segment spans across segmentation regions)?

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 21 Oct 2021 14:11:01 +0000

Hi Ben,

Thanks for your review and comments. Let me first address the DISCUSS point below and then follow up with another email on other points.

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]>
Sent: Thursday, October 21, 2021 1:50 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Please refer to https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXZV7E-lH$
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXVyyzOC6$

Zzh> All routes have the following format:

                    +-----------------------------------+
                    |    Route Type (1 octet)           |
                    +-----------------------------------+
                    |     Length (1 octet)              |
                    +-----------------------------------+
                    | Route Type specific (variable)    |
                    +-----------------------------------+
Zzh> For a Leaf A-D route, its "Route Type specific" part is the triggering PMSI route's NLRI, so it explodes into the following (the three lines marked with '*' are the triggering PMSI).

                   Route Type 11 (Leaf A-D)
                   Length (of the entire Leaf A-D route NLRI)
                   * Route Type x (for the triggering PMSI route)
                   * Length (of the PMSI route NLRI)
                   * Route Type specific (for the PMSI route)
                   Originator's Addr Length (for the Leaf A-D route)
                   Originator's Addr (for the Leaf A-D route)

Zzh> With the above, there should be no problem parsing the NLRI?
Zzh> Thanks.
Zzh> Jeffrey

Section 1

   explained.

Section 2.1

Section 2.1.1

Section 3

Section 4

Are we going to need a

Section 5.1

Section 5.2

Section 5.3

Section 6.3

Section 9

Section 12.1

Section 12.2

NITS

Abstract

I'd suggest NEW:

Section 1

Section 2

Section 2.1.1

Section 4

I think s/and/that it/

s/send/sends/

Section 5.3

Section 6.1

Section 6.2

Section 6.3

Section 7

Juniper Business Use Only

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Oct 2021 20:07:38 -0700

Hi Jeffrey,

> Thanks for your review and comments. Let me first address the DISCUSS point below and then follow up with another email on other points.

Sure, that sounds good.

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!S0XsefTxpcM08Cegf69h1Kt6chs_TkO5AGOfS5hXEhy1jFTSKNgIn4vlXVyyzOC6$

Thanks for writing it out like that.

In a sense the triggering NLRI is "self-describing" because it has its own
type and length information; that internal structure does allow for the
location of the Originator's Addr Length field to be determined and the
rest of the Leaf A-D route to be parsed.  (And any given route type is
presumably going to have a fixed internal structure, though not necessarily
a fixed-length internal structure, which also helps ensure a unique
interpretation.  The triggering route has to be parsed itself, after all!)

So in short, there is no protocol issue here, though we might want to think
about whether to include the "expanded version" of the diagram you show
above in the document itself, to avoid any other readers getting confused
in the same way that I did.

I will update my ballot position in the datatracker now, and wait for any
additional reply to the comment portion of the ballot.

Thanks again,

Ben

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 25 Oct 2021 23:38:38 +0000

Hi Ben,

I have posted -012 revision. It should address most of your comments.

https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-bum-procedure-updates-12.txt

Please see zzh2> below for both the DISCUSS and COMMENT points below.

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Sent: Thursday, October 21, 2021 11:08 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked] <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)

Hi Jeffrey,

Sure, that sounds good.

Zzh2> If it's ok with you, I'd like to not include the "expanded version". The Leaf A-D NRLI embedding the entire triggering PMSI NLRI started in RLI6514 (MVPN) and have been used extensively. I did add " Its NLRI embeds the entire NLRI of the triggering PMSI A-D route" in the terminology section.

Zzh2> Thanks! More below on the COMMENTs.

Thanks again,

Ben

> Zzh> Jeffrey

Zzh2> You're right. I had added references to where the terms are listed, but I should also added references for EVPN/MVPN in general.

> RFC 6514 does not actually use the PTA acronym.

Zzh2> Added.

> indication of the nature of the difference, before stating which variant

Zzh2> I added VPLS to the "familiar" list 😊
Zzh2> I also added a reference to " 5.1.  Changes to Section 7.2.2 of [RFC7117]" to indicate the difference.

> "Could be"?  It sometimes is and sometimes isn't?  When is it still

Zzh2> This is in the "descriptive" part of the document. Later in the normative part, I do have the following:

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-11#section-6.3

   ... this document specifies that RBRs change the BGP
   next hop when they re-advertise I/S-PMSI A-D routes and do not use S-
   NH-EC.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-11#section-6.4

   ... To be consistent with the inter-as case, the ingress PE does
   not set the L flag in its originated I-PMSI A-D routes, and
   determines the leaves based on the BGP next hops in its received
   I-PMSI A-D routes, as specified in Section 5.2.

> reference seems in order.

Zzh2> Yes; but it started in MVPN (6513/6514) though not officially called as "option (b)". To make it simple I just removed the wording:

       For example, an MVPN/VPLS/EVPN network may span multiple providers
       and the end-to-end provider
       tunnels have to be segmented at and stitched by the ASBRs.

> qualify as "new"?  (I honestly am not sure, given the distribution of

Zzh2> Good point 😊 It's still new in that its deployment is hindered by the fact that new hardware is needed. I changed to the following:

   Another advantage of the smaller region is smaller BIER [RFC8279]
   sub-domains. With BIER, packets carry a BitString ...

> Is it safe to say that any type that does have an RD must meet this

Zzh2> I added "current" wording 😊

> for how RFC 7432 referred to the RFC 7117 procedures?

Zzh2> Well the MVPN/EVPN procedures keep evolving so if it's warranted maybe another -bis version of this document will happen in the future 😊
> ASBR re-advertises the route within its own AS?

Zzh2> Basically procedures in RFC7117 related to the electing that ASBR will not be used for that purpose.

> scope that import RT is expected to limit acceptance of the route to.

Zzh2> Do you mean the following?

       This RT is IP address specific.  The Global Administrator field
       of this RT MUST be set to the IP address carried in the Next Hop
       field of all the S-PMSI A-D routes advertised by this PE (if the
       PE uses different Next Hop fields, then the PE MUST be
       (auto-)configured with multiple import RTs, one per each such
       Next Hop field).  The Local Administrator field of this Route
       Target MUST be set to 0.

Zzh2> It's already in RFC7117 so not repeated in this document. I can add if that's necessary.

> breaks if you don't do this?

Zzh2> I thought only SHOULD requires text explain what happens if it is not done 😊
Zzh2> If they did not advertise the same label, then the ingress PE will send multiple copies to the ASBR.

> still seems like this might be glossing over some details.

Zzh2> Basically a PE builds its forwarding state (referred to as flooding list here) used to replicate traffic. Each replication branch maps to a (nexthop, label) tuple. If you receive multiple routes with the same tuple, only one branch will be added. This should be a natural result, but a MUST is used here to be sure.

> I don't think I understand the parenthetical.  Which previous text is it

Zzh2> While an ingress PE does not set the L flag, it may be set by an ASBR when the route is re-advertised.

> way that lifts the requirement from §11.2 of RFC7432.

Zzh2> PEs still don't set the L flag. They don't need the L flag (to trigger Leaf AD routes) for leaf tracking purpose.

> Can be used, but is in no way mandatory, not even to implement?  That's

Zzh2> The intention is that if there is no backward compatibility issue to worry about an implementation may choose not to implement the procedure (of course if a deployment does have backward compatibility issue then that implementation will not be able to be deployed there).
Zzh2> I changed to:

    If this backward compatibility problem need to be addressed, the following
    procedures MUST be used ...

> "them" for "advertise them"?)

Zzh2> Missing "them" added.

> suggest writing out "Segmented Next-Hop Extended Community" somewhere.

Zzh2> It's in Section 2.1 of this document:

   For inter-area segmentation, [RFC7524] requires the use of Inter-area
   P2MP Segmented Next-Hop Extended Community (S-NH-EC),

> 6513 are relevant here, in addition to the (already mentioned) 6514

Zzh2> Added.

> the same way for the same example, but are classified as informative.

Zzh2> While they're all only referenced in the following:

   Different providers may use different tunnel technologies (e.g.,
   provider A uses Ingress Replication [RFC7988], provider B uses RSVP-
   TE P2MP [RFC4875] while provider C uses mLDP [RFC6388]).

Zzh2> there are additional text about Ingress Replication in section 5 - that's the difference that led to the normative reference. But I changed it to informative.

> in largely the same places, and often.

Zzh2> OK I made both normative.

>  unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
Zzh2> Changed.

> to enable reception of BUM traffic for a given VLAN" or similar?

Zzh2> The main point is establish the equivalence between IMET route and I-PMSI route, and then the purpose of IMET route is explained via I-PMSI route.

> s/to Multicast/to the Multicast/

Zzh2> Fixed.

> s/to smaller/into smaller/

Zzh2> Changed.

>    (C-*,C-G) SMET routes and advertises to other NVEs, and a receiving

Zzh2> Changed.

>    NVE converts the SMET routes back to IGMP/MLD messages and send them

Zzh2> Fixed.

> so maybe s/instead of/and not use/.

Zzh2> Changed.

> "region" don't seem paired anywhere directly.

Zzh2> It's first mentioned in 2.1 as following:

   [RFC7524] assumes that segmentation happens at area borders.
   However, it could be at "regional" borders, where a region could be a
   sub-area, or even an entire AS plus its external links (Section 6).

Zzh2> I now refer to section 6.1 specifically instead of section 6 in the above paragraph.
Zzh2> I do see where the confusion comes from. The diagram is for "inter-as" not "inter-region" (I now have that clarified); but the text says that in that diagram, you can have the regions to include inter-as links so now you'd have fewer segments (one segment for each region).

> Mention of route key seems to be in §3.3, not 3.1.

Zzh2> I meant "Region ID" (and Ethernet Tag ID). Changed.

> s/consistent/a consistent/

Zzh2> Fixed.

> multi-homed Ethernet Segment spans across segmentation regions)?

Zzh2> I changed to the following:

   ... PEs know that ESI labels are from DCB and then existing multi-
   homing procedures work as is (whether a multi-homed Ethernet Segment
   spans across segmentation regions or not)

zzh2> Thanks a lot for your detailed review and comments!
Zzh2> Jeffrey

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Oct 2021 19:55:18 -0700

Hi Jeffrey,

> Please see zzh2> below for both the DISCUSS and COMMENT points below.

Also inline...

> Zzh2> If it's ok with you, I'd like to not include the "expanded version". The Leaf A-D NRLI embedding the entire triggering PMSI NLRI started in RLI6514 (MVPN) and have been used extensively. I di…

That is okay.
(By the way, I see that one place in §3.3 changed from saying that the
route key for the Leaf A-D route is the route-type specific field of the
triggering route, to saying that it's the NLRI of the triggering route.
That distinction may have been part of why I was confused and put a Discuss
in.  But it's all clear now, so there's nothing to do.)

> Zzh2> I also added a reference to " 5.1.  Changes to Section 7.2.2 of [RFC7117]" to indicate the difference.

Thanks!
By the way (and probably unrelated), I filed
https://www.rfc-editor.org/errata/eid6724 against RFC 7177 based on a
paragraph from it that this draft quotes.  I think this draft should
continue to quote the actual text in RFC 7117, though, so am not sure that
there are any changes to make to this draft as a result of that errata
report.

> Zzh2> This is in the "descriptive" part of the document. Later in the normative part, I do have the following:

My point is that these are not "optional" in the sense that an
implementation has a choice to make -- we know exactly when they will or
will not be used.  It seems unhelpful to the reader to be ambiguous about
whether there is a requirement here, since there is required behavior
specified later on.  We might, for example, say that these requirements, or
when they apply, are modified for the EVPN case, or "In the EVPN case, the
requirements around S-NH-EC and the PTA "L" flag differ from [RFC7524]".
This continues to let the reader know that there is divergence from RFC
7524, but sets the expectation that more details will appear later in this
document.

> Zzh2> Yes; but it started in MVPN (6513/6514) though not officially called as "option (b)". To make it simple I just removed the wording:

Sounds good!

> Zzh2> Basically procedures in RFC7117 related to the electing that ASBR will not be used for that purpose.

Ok.  I would suggest (but do not insist) that more of the RFC 7117 text be
quoted so as to be covered by the "above quoted text is not applicable to
EVPN" disclaimer.

>        Next Hop field).  The Local Administrator field of this Route

Yes :)

> Zzh2> It's already in RFC7117 so not repeated in this document. I can add if that's necessary.

Ah, I think I did not look in RFC7117 for this.  No need to add it here.

> Zzh2> I thought only SHOULD requires text explain what happens if it is not done 😊

I don't think there's a hard rule (in either case, actually).  Sometimes it
is useful to say, and sometimes not.

> Zzh2> If they did not advertise the same label, then the ingress PE will send multiple copies to the ASBR.

Is that just using up extra bandwidth, or would there be risk of the
multiple copies propagating further in the network?  If we require a
behavior in order to protect the network (or CE) from receiving duplicate
packets, that could be important enough (i.e., a security consideration) to
tilt the balance in favor of adding the extra explanation.

> Zzh2> Basically a PE builds its forwarding state (referred to as flooding list here) used to replicate traffic. Each replication branch maps to a (nexthop, label) tuple. If you receive multiple rou…

I trust you :)

> Zzh2> While an ingress PE does not set the L flag, it may be set by an ASBR when the route is re-advertised.

Ah.  Maybe "added by the re-advertising ASBRs" or "as might have been added
by the re-advertising ASBRs", then?

> Zzh2> PEs still don't set the L flag. They don't need the L flag (to trigger Leaf AD routes) for leaf tracking purpose.

Thanks for the extra explanation; I had missed that distinction.

>     procedures MUST be used ...

Thanks.  (In my experience it is basically impossible to reliably know at
implementation time whether backward compatibility will (eventually) be
needed at runtime.  The new text strikes a good balance.)

> Zzh2> there are additional text about Ingress Replication in section 5 - that's the difference that led to the normative reference. But I changed it to informative.

Ok.  Another option would have been to add a reference to RFC 7988 in
section 5, but I am not going to ask you to keep making changes.

> Zzh2> The main point is establish the equivalence between IMET route and I-PMSI route, and then the purpose of IMET route is explained via I-PMSI route.

To me, the current text doesn't seem like an "explanation" that provides
"convenience" for the reader.  I recognize that opinions may differ.

>    sub-area, or even an entire AS plus its external links (Section 6).

That talks about the concept of a region in general.  My remark was
specifically about "region 3".

> Zzh2> I do see where the confusion comes from. The diagram is for "inter-as" not "inter-region" (I now have that clarified); but the text says that in that diagram, you can have the regions to incl…

First off, thanks for these changes!
However, if there is no figure that indicates anything that would
correspond to this "region 3", then I don't think there is much value in
using a region number in the prose.  Wouldn't it convey the same
information to just say "in the neighboring region"?

>    spans across segmentation regions or not)

Thanks, that helps me figure it out.  I will leave any further wordsmithing
to the RFC Editor :)

> zzh2> Thanks a lot for your detailed review and comments!

You're welcome!  Thanks for the additional explanations here, as well as
the changes in the -12.

-Ben

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sun, 31 Oct 2021 02:18:38 +0000

Hi Ben,

Text snipped to focus on outstanding issues. The draft posting window is not open yet, so let me post a diff file here.

Please see zzh3> below.

---------------------

zzh3> Yes - there was indeed a text error. Thanks for your original question - it led to the discovery of this error.

https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6724__;!!NEt6yMaO-gk!UqH90SqHM2qJynm-VnBnIZRpYUfjzBBPsJ5_pWD03kOhlk1YFyd3kuF75bpuZwSD$  against RFC 7177 based on a

Zzh3> I see that it's an editorial errata - "tunnel type" instead of "tunnel identifier". I think we can get away w/o doing anything here, as the error is obvious - anyone who need to understand the paragraph should be able to figure out.

Zzh3>  ok changed.

Zzh3> OK I added "Otherwise, duplicated copies will be sent by the ingress PE and received by egress PEs in other regions."

Zzh3> What's the difference between the "set" and "add" here? The flag is a bit in a bit field. Do you mean I should/could simply remove the parenthesis, like "if the PTA has the L flag set by the re-advertising ASBR"?

Zzh3> OK I added " used to announce the tunnels that instantiate an I-PMSI".

zzh3> I see. I removed " 3".

Zzh3> Thanks a lot!

Zzh3> Jeffrey