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

From: Ian Farrer <[email-masked]>
Date: Tue, 30 May 2017 11:37:03 +0200

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.