Hi Shu, all, Please see inline.
Cheers, Med De : Softwires [mailto:[email protected]] De la part de ?? Envoyé : dimanche 2 juin 2019 17:30 À : Benjamin Kaduk; The IESG Cc : softwires; draft-ietf-softwire-mesh-multicast; softwire-chairs Objet : Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT) Dear Benjamin, Thank you for your helpful and detailed comments, we reply as following, > Section 5.4 > To achieve this, every AFBR MUST announce the address of one of its > E-IPv4 interfaces in the "v4" field alongside the corresponding > uPreifx64. The announcement MUST be sent to the other AFBRs through > MBGP [RFC4760]. Every uPrefix46 that an AFBR announces MUST be > unique. "uPrefix46" is an IPv6 prefix, and the distribution > mechanism is the same as the traditional mesh unicast scenario. > I am not very familiar with this space, and just wanted to check that both > "uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64" > being a typo). We have modified the typo. [Med] Given that this document relies on RFC8114 to construct multicast prefixes (and other matters), I suggest to use the same terms as those defined in RFC8114: mPrefix64: a dedicated multicast IPv6 prefix for constructing IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode [RFC4607<https://tools.ietf.org/html/rfc4607>]. The size of this prefix is /96. Note: "64" is used as an abbreviation for IPv6-IPv4 interconnection. uPrefix64: a dedicated IPv6 unicast prefix for constructing IPv4-embedded IPv6 unicast addresses [RFC6052<https://tools.ietf.org/html/rfc6052>]. This prefix may be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network- Specific Prefix (NSP). … > Section 9 > "MUST [...] follow the requirements mentioned in > [I-D.ietf-intarea-tunnels]" seems like it needs a normative reference. > "MUST [...] allow the use of encapsulation mechanisms mentioned in > [RFC4925]" would seem to do the same. We change these references to be normative. [Med] I’m not sure this is the right approach. Do you really need draft-ietf-intarea-tunnels? IMHO, that section can be replaced with a sentence pointing to rfc5565#section-8.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
