IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks
draft-ietf-softwire-mesh-multicast-25

A couple of nits:

1) "COULD" is not one of RFC 2119 keywords, so it shouldn't be uppercased in order to avoid causing confusion for readers.

2) In Section 10 the document says:

   Compared with [RFC4925], the security concerns SHOULD be considered
   more carefully: ...

This is not a requirement statement on implementations or operators, so use of SHOULD is not appropriate here. So please lowercase it to avoid RFC 2119 meaning.

Building off of Mirja's comment and the Gen-ART review, I have a specific suggestion for Sec. 7.3:

OLD
The specific requirements for
   fragmentation and tunnel configuration COULD be referred to in
   [I-D.ietf-intarea-tunnels], which is under revision currently.

NEW
Fragmentation and tunnel configuration considerations are provided in [RFC4459] and [I-D.ietf-intarea-tunnels].

(1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format".  Even though source address mapping had just been discussed (§5.3), it wasn't clear right away that you were talking about the same thing.  Maybe it was the name used ("IPv4-Embedded IPv6 Virtual Source Address Format"), which doesn't show up anywhere else.  Putting a note in §5.3 about the name would be nice.

(2) §5.4: "...every AFBR MUST announce the address of one of its E-IPv4 interfaces in the "v4" field..."  Please put a reference here to rfc6052 (so it's easy to remember where that field came from).

(3) §6.4: "According to [RFC7761], it SHOULD propagate..." That SHOULD is out of place because it is not normative in this document.  Either change it to 'should', or quote the text.

(4) §6.4: Several SHOULDs are used in this section.  In general, are there cases where it's ok to not follow the specification?  For example, "When RP' receives this encapsulated message, it SHOULD decapsulate..." -- are there cases where the RP' wouldn't decapsulate.  IOW, why not use MUST instead?

(5) §6.4: "...so RP' SHOULD NOT simply process this message as specified in [RFC7761] on the incoming interface."  That "SHOULD NOT" seems to just be a statement and not have normative value (the normative text comes in the next paragraph).  s/SHOULD NOT/should not

§2: Please use the boilerplate from RFC 8174.

§10: "... the security concerns SHOULD be considered more carefully...":

That seems more a statement of fact than a normative requirement. I suggest changing the "SHOULD" to "should".

I'm balloting No Objection instead of Discuss, but I think this document
has a few things that need to be resolved before publication.  In
particular:

I'm concerned that the informative references may actually need to be
normative references, but not quite enough to cross my Discuss threshold.
See my comments on Section 9 for details.

There are several things that look like internal references but are not
resolvable (see per-section comments).

Section 1

I think you should provide a brief summary of what "(S,G) states" are in
this document, as well as the reference.

Section 3

   o Address Family Border Router (AFBR) - A router interconnecting two
   or more networks using different IP address families.  Besides, in
   the context of softwire mesh multicast, the AFBR runs E-IP and I-IP

nit: maybe s/Besides/Additionally/?

nit: using "upper reaches" and "lower reaches" is still basically the same
metaphor as upstream/downstream.  I guess "closer to the source" and
"closer to a receiver" might be different, but offer no opinion on whether
it would be better.

Section 5.2/5.3

Please expand SSM and ASM on first usage.

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).

   When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be
   generated according to the format specified in Figure 3, with the
   "source address" field set to * (wildcard value).  The translated

There is no "source address" field in Figure 3.

   message will be forwarded to the corresponding upstream AFBR.  Since
   every PIM router within a PIM domain MUST be able to map a particular
   multicast group address to the same RP (see Section 4.7 of
   [RFC7761]), when the upstream AFBR checks the "source address" field
   of the message, it finds the IPv4 address of the RP, and ascertains
   that this is originally a (*,G) message.  This is then translated
   back to the (*,G) message and processed.

I'm failing to find where the downstream AFBR is setting the source address
to that of the RP; presumably this just means I'm confused about how this
part works.

Section 6.4

   Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT
   of (S,G), and decided to perform an SPT switchover.  According to

Is it the AFBR that has joined the (E-IP) group and decided to switchover,
or some system in the client network?

Section 8

   In Figure 5, the semantics of fields "PIM Ver", "Type", "Reserved",
   and "Checksum" can be referred in Section 4.9 of [RFC7761].
   IPv4 Group Address (Encoded-Group format): The encoded-group format
   of the IPv4 group address described in Section 4.2.

   IPv4 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv4 source address described in Section 4.3.

   IPv6 Group Address (Encoded-Group format): The encoded-group format
   of the IPv6 group address described in Section 4.2.

   IPv6 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv6 source address described in Section 4.3.

This document has no Section 4.2 or 4.3 (and those sections of RFC 7761 do
not seem appropriate here, either).

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.

Section 10

It may be worth calling out the "interface agent" as being an additional
workload susceptible to DDoS.

It is true that the trusted nature of the BGP peer is what is relevant for
deciding to accept Well-Known prefix advertisements, but perhaps there is
room to mention the potential use of cryptographic methods for
authenticating the peer so as to have increased confidence that such trust
is properly placed.

On section 7.3: Thanks for discussing fragmentation and pointing to [I-D.ietf-intarea-tunnels]. As [I-D.ietf-intarea-tunnels] is still work in progress, I guess it could make sense to also add a reference to rfc4459 directly. Also I don't think COULD is a well-know key word...