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

[Ballot comment]
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.

[Ballot comment]
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].

[Ballot comment]
§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".

[Ballot comment]
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.

[Ballot comment]
(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

[Ballot comment]
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...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-softwire-mesh-multicast-22, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-06):

From: The IESG
To: IETF-Announce
CC: softwire-chairs@ietf.org, Ian Farrer , ianfarrer@gmx.com, draft-ietf-softwire-mesh-multicast@ietf.org, softwires@ietf.org, terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to consider
the following document: - 'IPv4 Multicast over an IPv6 Multicast in Softwire
Mesh Network'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  During the transition to IPv6, there will be scenarios where a
  backbone network internally running one IP address family (referred
  to as the internal IP or I-IP family), connects client networks
  running another IP address family (referred to as the external IP or
  E-IP family).  In such cases, the I-IP backbone needs to offer both
  unicast and multicast transit services to the client E-IP networks.

  This document describes a mechanism for supporting multicast across
  backbone networks where the I-IP and E-IP protocol families differ.
  The document focuses on IPv4-over-IPv6 scenario, due to lack of real-
  world use cases for IPv6-over-IPv4 scenario.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ballot/


No IPR declarations have been submitted directly on this I-D.

Dear INT Area Directors and IESG-Secretary -

Please advance in the process and publish the draft from the
Softwires WG. Here is the proto writeup for the draft:
draft-ietf-softwire-mesh-multicast-22


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended status: Standards Track (Indicated on title page)
This document describes a mechanism for transporting IPv4 multicast
traffic over meshed IPv6 native backbones using encapsulation.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
This document defines a mechanism for transporting IPv4 multicast
traffic over single-stack IPv6 multicast service provider's networks.

This is achieved through the use of the underlying IPv6 multicast
distribution tree. The IPv4 traffic is statelessly encapsulated in
IPv6. The main benefit of this solution is using an IPv6
multicast network for the efficient distribution of IPv4 based
multicast content.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

There is consensus in the WG for the publication of this
document. A question was raised about scope overlap
between this document and RFC8114 (Delivery of IPv4
Multicast Services to IPv4 Clients over an IPv6 Multicast
Network). The two differ in the RFC8114 covers multicast
for DSLite based networks, whereas this document is
for multicast over mesh based provider backbone networks.
Text has been added to the Introduction of this
document to clarify the difference in scope and the
authors of RFC8114 have agreed the text.



Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

One of the authors (Shu Yang) stated that the Bitway company (a networking device company in China)
have implemented a prototype.


Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Ian Farrer (Softwire co-chair), is the Document Shepherd.
Terry Manderson is the Responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed by the Document Shepherd for technical
content, completeness and language. All raised comments have been resolved.
The document is well written and ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR issues have been filed. All authors have confirmed that
they are not aware of any IPR related to this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG consensus has been achieved and all of the related active
participants agree on the advancement of this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review are necessary.


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document contains no requests to IANA.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None (no formal language included in the document).

Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Chris Metz , Mingwei Xu

This got accidentally left in the WGLC state. Once an update with the issues raised at WGLC is received, the document should be ready to advance.

Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Yong Cui , Mingwei Xu , Chris Metz

Request for posting confirmation emailed to previous authors: Jianping Wu , softwire-chairs@ietf.org, Greg Shepherd , Shu Yang , Mingwei Xu , Yong Cui , Chris Metz