Ballot for draft-ietf-softwire-mesh-multicast
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
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...