[RTG-DIR] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt

Donald Eastlake <d3e3e3@gmail.com> Tue, 18 July 2023 02:17 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9385EC14CE2E; Mon, 17 Jul 2023 19:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.814
X-Spam-Level:
X-Spam-Status: No, score=-6.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, T_HK_SPAMMY_FILENAME=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iusJbp6hQvO; Mon, 17 Jul 2023 19:17:45 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC83C14CF17; Mon, 17 Jul 2023 19:17:41 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-51e429e1eabso7351504a12.2; Mon, 17 Jul 2023 19:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689646659; x=1690251459; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=W42EPczm3jF/2HUSIY+ndZ5/HIEyKmGAYoYZoNBc60o=; b=dOhDgDHThY/icfsskq4OW45H+OSVC0sDwGL9YMw/qrhngvP0n/ZCS67w961Q2apQFl YllQkG9WJdCBRbhGLwm00srJlX3LR1QUn6QVN+iO6JTzSwZ+RMOnutmVr2nr2thISWxn a/uOAgArHWNvoCQCu8WUS7qz+nGFDW1egnP4+fpL3kD7Ck+CoyyJ7RFYarEs9+PYpohs qqavu4b6hR5nX3i2ERIc1Ds28UUDBq9t+elc7z8xexnG2nAE5cIZMGBUcemnV7FvHm1y K93I2sSXPxGy6sbPiwg/OXJ0YW+H65vEeUv14eKsZX5zLDAir+1TMD+OE6iTy3648+z8 AxlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689646659; x=1690251459; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=W42EPczm3jF/2HUSIY+ndZ5/HIEyKmGAYoYZoNBc60o=; b=RkykvmSVNKm5AVlWEbbTfwkFPu6EZpgLZ8HxM6KGrHcjSNafVvsaVqyJymzEQ/0Bbh x3IGepK16Y1zuZriaqGZCVr6HSDCR1N0rjCFV2B9OlmBHQOb8wbbdlp5G1kqARdCDP9T mElxFra0LfvDASxvItFTD2pUHg1YUMZfMFLb6YcB2koi0Av5VVPNWog4DQWWB3aeVDo8 RtBcF1p+FGXF6hyTMY/FAeNp9iSD6JFqlXwbp3BK08afbOi0kPoiIkv/p/q9AU5v3guo cQw3yO7djSR2z03pV8Xcq3O1BQyB2rfr3KJ49ishBp6Fpc6aBUPdSASDalVWwLFo3beV SmlA==
X-Gm-Message-State: ABy/qLYHT+uGPqkarW8+8x75uyHym8BXDRh2O/1JfW7lYKFX3gyZGHl8 W3b4f3vfOiFj5F6sNPKMoJCHGvUxG2rvKx6Ya70GdyG6t4Q=
X-Google-Smtp-Source: APBJJlHA3JrDh4stWZxyTtRA6dgtX+LrX3aIHaG7XgbZJAodD0OqnIg0aZrqAm4prRN3GsLTZ0Gfs4jMkBPdi/LvxIY=
X-Received: by 2002:a05:6402:2037:b0:51d:92bf:e6b9 with SMTP id ay23-20020a056402203700b0051d92bfe6b9mr12440590edb.34.1689646658717; Mon, 17 Jul 2023 19:17:38 -0700 (PDT)
MIME-Version: 1.0
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 17 Jul 2023 22:17:26 -0400
Message-ID: <CAF4+nEGD=gEU7x0OVF_wGoUXM7TTyUQSZn-9JHM1TN7OX=pV4A@mail.gmail.com>
To: bess-chairs@ietf.org, draft-ietf-bess-evpn-irb-extended-mobility.all@ietf.org
Cc: rtg-dir@ietf.org, BESS <bess@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000e426320600b9844d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/L31nFe_vOx9nENCrzBKunyAfhus>
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-bess-evpn-irb-extended-mobility-10.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2023 02:17:46 -0000

I have been selected to do a routing directorate “early” review of this
draft.

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-extended-mobility/
<https://datatracker.ietf.org/doc/draft-foo-name/>

This is an early general readiness review of this draft.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-irb-extended-mobility-10.txt
Reviewer: Donald Eastlake
Review Date: 2023 July 17
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.

*Comments:*

I would rate the readability of the draft as moderate. Hopefully some of my
suggestions below will help.

I believe the technical quality is high and the document takes a reasonable
approach to maintaining appropriate handling of sequence numbers when there
is a mobility event that changes the pairing between MAC and IP addresses
under various circumstances; however, I do have a few questions below.

This document repeatedly says that it may be considered a clarification of
RFC 7432. I believe it is true that the behavior specified in this document
is permitted by RFC 7432 but other behaviors are permitted and perhaps
common. In order to handle the mobility cases covered in this document the
behaviors in the document would have to be implemented or some other
solution adopted. Thus I think the title page header should show this
document as updating RFC 7432 and this should be mentioned in the Abstract
and Introduction.

It seems to me that the last paragraph of Section 7.2 ignores the case
where Mx-IPx with sequence number N movez to Mz-IPx where child IP-MACs
under Mz were currently being advertised with sequence number M where M >
N. The paragraph says the new Mz sequence number must be incremented to N+1
but if M>N I think it must be incremented to M+1. I have suggested changes
to the last two paragraphs of Section 7.2 in the attached.

Drafts should generally be worded so the text will be correct in the final
RFC. So both occurrences of "proposed" in this draft should be replaced by
"specified" or "defined" and occurrences of "draft" in the body text should
be replaced with "document".

Section 2.1 lists subsequent sections as Informative or Normative but omits
Sections 3 and 7. I think Section 3 is Informative. The right category for
Section 7 is a bit unclear but I'm inclined towards normative.

Section 10.2 refers to section 6.1 but there isn't any section 6.1. The
bullet point in Section 10.2 seems essentially incomplete: What "MUST be
higher than the "Mz" sequence number"?

In the last sentence of Section 4.3.1, it is not completely clear what "It"
refers to. Assuming it is the interpretation in the previous sentence, I
suggest "It could be interpreted as" -> "This interpretation could be
considered".

"GW devices" occurs only once in this document in Section 2 and GW is never
expanded. I suggest, assuming this is correct, that the phrase be replaced
with "PE devices".

In section 9, since it is not expanded and not listed in the glossary, I
think "EXT-COMM" -> "Extended Community".

Based on the usual order of RFC Sections and the RFC Editor's recommended
table of contents, I think Sections 1 and 2 should be swapped.

The requirements language boilerplate at the beginning of Section 1 needs
to be updated to the latest version also normatively referencing RFC 8174.

The document references RFC 7432 but I think it should reference the
rfc7432bis draft instead.

I am doubtful that there are truly no new security considerations. At a
minimum, I would think the Security Consideration section (section 11)
should refer readers to the Security Considerations sections of [EVPN-IRB]
and rfc7432bis and should state that the methods specified in this document
will increase the consumption of sequence numbers.

RFCs are generally limited to a maximum of five authors. This document
lists six but does say why it needs to list that many. This could be in a
first page note to be deleted before publication.

Nits:

Abstract: "Procedure to handle host mobility" -> "The procedure to handle
host mobility"

Section 2, first sentence: "EVPN-IRB enables capability ..." -> "EVPN-IRB
enables the capability ...

Section 2: "Purpose of this draft is to define additional ..." => "This
document defines additional ... "

Section 4.3.1: "Complication with this ..." -> "The complication with this
..."

Section 8.8: "This sections is to be treated as optional ..." -> "This
section is optional ..."

Although the above stuck out a bit more to me, there are many other nits
including some spelling typos and a duplicated word, so I went through
marking what I consider to be fixes and these are shown in the attached.

I hope this review is helpful.
Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com