Re: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

[<[e-mail]>]

Hi Shu, all,

Please see inline.

Cheers,
Med


De : Softwires [mailto:[e-mail]] 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.