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.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
