Re: [bess] John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Jeffrey,

Thanks for the quick turnaround. The update looks good, I’ll clear my discuss. I have a couple new comments/questions regarding the “Context-Specific Label Space ID Type” registry.

- Is there any existing group of registries you could suggest IANA organize the new registry under? At first glance, it appears as though it might fit in the “Border Gateway Protocol (BGP) Extended Communities” group, there are a bunch of other (sub)type registries there. If you agree that’s the place for it, add that suggestion in the IANA section.

- Probably add another line to the table, indicating values 1-255 are unassigned. Unless you want to reserve value 255, sometimes people like to do that, for various reasons. It doesn’t really seem necessary in this case, but on the other hand, it may come under the heading of “can’t hurt, might help“. In that case, it would be two new lines: “1-254, unassigned; 255, reserved”. 

Thanks,

—John

> On Oct 3, 2023, at 9:13 PM, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> Hi John,
> 
> Thanks for your review and for catching those issues.
> I posted -13 revision that addresses them (and some comments from others).
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-mvpn-evpn-aggregation-label-12&url2=draft-ietf-bess-mvpn-evpn-aggregation-label-13&difftype=--html
> 
> Please see zzh> below for two clarifications.
> 
> 
> Juniper Business Use Only
> -----Original Message-----
> From: John Scudder via Datatracker <[e-mail]>
> Sent: Tuesday, October 3, 2023 6:06 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: John Scudder's Discuss on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with DISCUSS and COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> John Scudder has entered the following ballot position for
> draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9ysPLbofw$
> 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-mvpn-evpn-aggregation-label/__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9y8nKQlYI$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> # John Scudder, RTG AD, comments for
> draft-ietf-bess-mvpn-evpn-aggregation-label-12 CC @jgscudder
> 
> Thanks for this spec. I have one serious concern (but I think it will be easy to take care of) and a few comments and nits.
> 
> (Sorry for the iteration on this ballot, I missed one of my pages of notes in my haste to get this sent off.)
> 
> ## DISCUSS
> 
> ### Section 3.2, ignoring routes considered harmful
> 
> Zzh> You're right. Thanks for the detailed explanation. I changed both to "treat-as-withdraw".
> 
> There are two places toward the end of this subsection where you specify that a route must be ignored. The first is:
> 
> "A PE MUST ignore a received route with both the DCB-flag and the Context Label Space ID EC attached, treating as if it was not received."
> 
> The second is:
> 
> "If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure one of the following" ... "Otherwise, a receiving PE MUST ignore the routes."
> 
> Literally ignoring routes is one of the classic Bad Ideas in BGP. There can be exceptions, if the conditions for ignoring the routes are carefully chosen so that correctness (or something like it) is preserved, but as a general matter, ignoring routes is a one-way ticket to persistent traffic loss or worse. It's for this reason that RFC 7606 specifies treat-as-withdraw for many error conditions. I'll illustrate the general problem with an example that uses simple IPv4 unicast routes:
> 
> - Suppose we receive 10/8, with nexthop 1.1.1.1, choose it as best, and install it in the FIB. - Now suppose the router that advertised it to us sends a replacement, an advertisement for 10/8, nexthop 2.2.2.2, including path attribute P that we decide is malformed. We ignore the route as our error handling strategy. - We are left in a state where we still have 10/8 via
> 1.1.1.1 selected and installed, because we ignored the replacement, "treating it as if was not received". This is an incorrect state. I can easily show you scenarios where it leads to traffic loss, persistent loops, etc. - The correct behavior in this scenario would be to remove the 10/8 route received in the first step; RFC 7606 calls this "treat-as-withdraw".
> 
> It might be that something special about MVPN/EVPN routes means this isn't an issue for the two cases I've quoted, but you haven't made this clear in the document. I think at minimum, some analysis is needed to show that the strategy is OK. On the other hand if what you meant by "ignore" is something closer to the "treat-as-withdraw" strategy, I think the language has to be made more specific and leave less to the creativity and imagination of the implementor.
> 
> Let's have a discussion about which it is, and see where to go from there.
> 
> Edited to add: I sent this as a followup to my original ballot, with cc
> idr-chairs: "I suspect my DISCUSS would have been caught if there had been review from IDR. Searching for the draft name in the IDR mailing list archive doesn’t surface any traffic about it, so I’m guessing this didn’t occur."
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ## COMMENTS
> 
> ### Section 3, EC
> 
> Please expand "EC" on first use, or put it in your glossary, or my personal favorite, just use the words "Extended Community" and remove "EC" altogether, it's unnecessary and (in my opinion) unhelpful to abbreviate it.
> 
> ### Section 3.1, need registry?
> 
> You have an ID-Type and define the semantics of type 0. You probably should create a registry for the unallocated types.
> 
> ### Section 3.1, AND or OR?
> 
> You have:
> 
>   In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
>   route "carries DCB-flag" or "has DCB-flag attached" we mean the
>   following:
> 
>   *  The route carries a PMSI Tunnel Attribute (PTA) and its Flags
>      field has the Extension bit set
> 
>   *  The route carries an "Additional PMSI Tunnel Attribute Flags" EC
>      and its DCB flag is set
> 
> I think you need to indicate if the bullets are ANDed or ORed. I infer from later context that they're ORed, in which case perhaps "we mean one or the other of the following".
> 
> Zzh> It's actually "AND". The PTA has an extension flag to indicate the existence of additional flags that are carried in that EC, and RFC7902 requires both.
> Zzh> Thanks!
> Zzh> Jeffrey
> 
> ### Section 3.1, values aren't TBA, they've been assigned
> 
> You write, "Sub-Type value to be assigned by IANA". But your IANA section shows that the sub-type has been assigned the value 0x08. Please update the "to be assigned" language, and put the value into the diagram.
> 
> You also write, "This document introduces a DCB flag (to be assigned by IANA)".
> Again, your IANA section shows IANA has assigned value 47, so please update the text in this section to match.
> 
> ## NITS
> 
> ### Section 2.2
> 
> - "number of total number of labels" --> too many "number of"s
> 
> ### Section 2.2.2.3
> 
> - "w/o" --> "without"
> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues.
> 
> [ICMF]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9yY_CUuaA$
> [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!DCMEQpDxLLxMiP1UHgTMTxAPXUhT-KT3_3rIVmJ9CNiiUKgKhsCBWmSR2xjtPxyphO6-wP9yoK_vl7o$
> 
> 
>