[Softwires] Review of draft-ietf-softwire-map-mib-09

Ian Farrer <ianfarrer@gmx.com> Tue, 30 May 2017 09:37 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6E129423; Tue, 30 May 2017 02:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.9
X-Spam-Level:
X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTiL9JmalLFO; Tue, 30 May 2017 02:37:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0037127077; Tue, 30 May 2017 02:37:06 -0700 (PDT)
Received: from teraadmins-mbp.lan ([80.159.240.147]) by mail.gmx.com (mrgmx002 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MWSwU-1dRCIs0hNy-00Xe1x; Tue, 30 May 2017 11:37:04 +0200
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <C6B76757-5711-402A-A374-8B14F6B00E64@gmx.com>
Date: Tue, 30 May 2017 11:37:03 +0200
Cc: Softwires-wg <softwires@ietf.org>
To: draft-ietf-softwire-map-mib@ietf.org
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:RTKgIIJM0WBR6jCGm+5COmOd8AUHBnwkHTcAvCsa6Izoew8/85j vo5j9uhKwEn/Nqy+Uu2rdfG7dSrEY2nnfkSI/zJZ/zXBFcBQaD3uiKKMw0EqNKX0In3WwC4 hkPbbbZSbWJpENPZdSaZisr6SJ2eSnuvQxUH2slGxJRWnrYRhohiwTQueblDM29fL+xbIEG W8W19mLYnatqXZyg464oA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2payDYKJe+8=:nMENzEl6A8WwGCnfLDFPjg YAQaDg3ysNPGe08jIfYMW+isxuVo6ZawGa/Fh3amfZwPOFKiDjU30J7qUhNzVRm5vArIwhhW0 EZTiydElgjf7UbL+9Lak2a6zIagCizzK3Wa+TA/AkY5Fnnnv6KWEZQuBjQuCZ5iBzn6ssVNXC 1pYaUrLeXYeHd1b67w+RY4If1N1qEyYC9Izs3mPNRZ2RF45bhX0hOquS4SrCLYDm8P+d+41pA +hkMnuf2P25F/QLgOXOtJnOkqaQARDjWVUsmAHR7JQiv3qVbL+Sll39DOnKXxXATXeq11wXc4 zh8BNB3PCi0mw7g4v882P9pBuUNeXpYS3FK5d4XCm3LzJct0WS82VdR7fqYExmcj/qltHxFgV mLfsam5m/YKuj05m7G7hg1lx3a0u6TOWKN/LgNJqfUivBVoYDzTQINpHMlcu0chLeI9qYrlYQ AI59Lx5wVc+zVh6PMZnGLFP3zIzO0jrcrAlS9Z184Qmz4Y0Tg31LOfvKkVv6rdpArVqrQeGUF WxCbgXPaGTCk6ID2qIhp+8DVKAJXpXgQZQltaAKw9e4IdqbZloRHDtZt1k+vFRpvEAoQx4OKR 2uqdxYKZ8niAUyZZvDWS9/cBv5jpdSHHifCJD7DYh+uzjVuh4z6jNh804h81BL+7KiEslg2X8 eenLX6CkLm2Nh/z4EAAJEVslIk+EYcwSndIgpOVaz/62MchMO+gg0FfSJSwHlUe4aUZcoHO+l gVjJVLsGGGE87oEZUrnyuOCk/4OPvHxRxapfMLzlNRZDOwvZfKPtGXPz6J6Vt/mzCWB/lIcZa ufUvw6B
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/bzFfLdAL8p7BIZyF-97CXXJfrv0>
Subject: [Softwires] Review of draft-ietf-softwire-map-mib-09
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2017 09:37:09 -0000

Hi,

Here is a review of the current version of the draft.

Cheers,
Ian

Introduction

a1) This needs to be updated: RFC7597 is for MAP-E and encapsulation is the single mode described there. RFC7599 deals with translation and so probably doesn’t need to be mentioned at all as it’s not part of the scope.

a2) Section 4.1.2
The description of error cases is not correct. The checks that are performed by both CE and BR validate that the v6, v4 and l4 ports are consistent, not just the v6 and dest. ports. Please check RFC7597 section 8.1.

MIB Comments:

b1) It appears that the intention to provide a single model to be used by both BR and CE. For ‘mapRuleBRIpv6Address, the description only provides information about what the CE does with this value. Is it valid for a BR? What should the BR do with it?
Also, for the ‘mapRuleType’ field - Is there a case where a rule provisioned to a BR is not an FMR? (I’m not familiar enough with MAP BR implementations to know if this is the case)

b2)   mapRuleID OBJECT-TYPE
           DESCRIPTION
                        "An identifier used to distinguish the multiple mapping
           rule which is unique with each CE in the same BR.”

[if - The description is unclear. If I understand the purpose of this object, it is to give a unique identifier to each rule. If this is the case, I would propose: “A unique identifier used to distinguish mapping
           rules.”


b3) The DESCRIPTION fields of  mapRulePSIDLen and mapRuleOffset are identical. The text makes sense for mapRulePSIDLen, but is incorrect for mapRuleOffset.


b4)   RulePSID ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "0x:"
      STATUS       current
      DESCRIPTION
          "It represents the PSID represented in the hexadecimal version
           so as to display it more clearly."
      SYNTAX       OCTET STRING (SIZE (4))

[if - Is 4 correct here? The allowable range for the PSID is 0..65535 which is 2 octets]


 b5)  mapRuleEALen OBJECT-TYPE
       SYNTAX     Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
          "The length of the Embedded-Address (EA) defined in
           mapping rule which will be assigned to CE."
      REFERENCE
            "EA: section 3 of RFC 7597."
       ::= { mapRuleEntry 10 }

[if - This can also be constrained for allowable values (0..48)]

b6) mapRuleType

[if - The choice that is being presented here isn’t inline with the F-Flag field described in sec 4.1 of RFC7598 (and by extension the FMR description in RFC7597). The F flag defines if a rule can be used for forwarding (i.e. mesh mode), not if it is a a BMR or an FMR (a BMR can be used for mesh mode if the F flag is set). Any of the received rules can be considered as a suitable BMR via the longest prefix match.