Subject: [MBONED] Adam Roach's No Objection on draft-ietf-mboned-driad-amt-discovery-10: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 17 Dec 2019 22:50:56 -0800

Adam Roach has entered the following ballot position for
draft-ietf-mboned-driad-amt-discovery-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work that went into creating this document! This approach to
multicast tunnel establishment sounds quite useful, and I hope it sees broad
adoption.

---------------------------------------------------------------------------

Please expand "AMT" in the title.

---------------------------------------------------------------------------

§2.2:

>                        Figure 2: DRIAD Messaging

This example uses IPv4 rather than IPv6. Please either add a similar diagram
showing IPv6 usage, or change this diagram to use IPv6. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further information.

---------------------------------------------------------------------------

§2.6:

>  AMTRELAY records MAY also appear in other
>  zones...

What would this mean? Is this intended for future specifications to
take advantage, or is the document assuming that the reader is able
to figure out the semantics of AMTRELAY RRs elsewhere in the DNS tree?
If the latter, please spell it out explicitly. If the former, please
indicate that using records in this way may be specified in future
documents.

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 18 Dec 2019 22:03:38 +0000

Hi Adam,

Thanks for the review.  Some comments below.

> Please expand "AMT" in the title.

[JH] Good catch, thanks.
OLD:
                      DNS Reverse IP AMT Discovery

NEW:
      DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery

> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further information.

[JH] The point is well taken, thanks.

I have no objection to changing the AMT Relay address in the diagram from
203.0.113.15 to an IPv6 example address, like so:

NEW:
   \  /          +---------------+
    \/           |   AMT Relay   |
                 |  2001:db8::f  |
                 +---------------+
                         |        4: Gateway connects to Relay,
                                     sends Join(S,G) over tunnel
                         |
                Unicast
                 Tunnel  |

     ^                   |        3: --> DNS Query: type=AMTRELAY,
     |                           /         15.100.51.198.in-addr.arpa.
     |                   |      /    <-- Response:
 Join/Leave       +-------------+          AMTRELAY=2001:db8::f
  Signals         | AMT gateway |

However, the full application of this suggestion introduces an unfortunate
formatting challenge for changing the (S,G) to use IPv6, namely that the
reverse DNS name for e.g. 2001:db8:c::f would become this:

f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

This domain name does not even legally fit into a single line.  In text
I guess I would follow the example from section 2.5 of RFC 3596 and wrap
the "arpa." to the next line:
https://tools.ietf.org/html/rfc3596#section-2.5

But no sane way to fit it into the diagram has occurred to me yet.  If you
have a suggestion that doesn't lose clarity I'd be happy to use it instead,
but I was wondering whether it would be reasonable to just add a paragraph
to the end of section 2.2 providing the substitutions if using IPv6?  I'm
hoping this would do the same job:

NEW:
   In the case of an IPv6 (S,G), the only difference in the AMT relay
   discovery process is the use of the ip6.arpa reverse IP domain name,
   as described in Section 2.5 of [RFC3596]), instead of the in-
   addr.arpa domain name.

   For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the
   reverse domain name for the AMTRELAY query would be:

   f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6.
                                                                  arpa.

I agree it's useful to give an example like this, in that it gives
implementors and operators something pasteable to compare against.  But
absent a proposed edit to the diagram that's still reasonable-looking and
correct, would these edits adequately addresses your concerns?

> indicate that using records in this way may be specified in future

Ah, thanks for noticing this was unclear, I think I didn't explain
this well.

The main point is because the reverse zones are often delegated to a
named zone, and in these cases it's necessary in practice to put the
record in the delegated zone.

Does this make it more clear?

NEW:
   AMTRELAY records MAY also appear in other
   zones, since this may be necessary to perform delegation from the
   reverse zones (see for example Section 5.2 of [RFC2317]), but the use
   case enabled by this document requires a reverse IP mapping for the
   source from an (S,G) in order to be useful to most AMT gateways.

I was intending to leave undefined the use of such records in other
ways.  Do you think it's helpful to add to the end of the above something
like "This document does not define semantics for the use of AMTRELAY
records obtained in a way other than by a reverse IP lookup."?

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Dec 2019 17:28:00 -0600

Thanks for the quick response! Some replies inline.

> 203.0.113.15 to an IPv6 example address, like so:

How do you feel about the following?

                  +---------------+
                  |    Sender     |
   |    |         | 2001:db8:c::f |
   |    |         +---------------+
   |Data|                 |
   |Flow|      Multicast  |
  \|    |/      Network   |
   \    /                 |        5: Propagate RPF for Join(S,G)
    \  /          +---------------+
     \/           |   AMT Relay   |
                  |  2001:db8::f  |
                  +---------------+
                          |        4: Gateway connects to Relay,
                                      sends Join(S,G) over tunnel
                          |
                 Unicast           3: --> DNS Query: type=AMTRELAY,
                  Tunnel  |       / f.0.0.0.0.0.0.0.0.0.0.0.
                                 / 0.0.0.0.0.0.0.0.c.0.0.0.
      ^                   |     / 8.b.d.0.1.0.0.2.ip6.arpa
      |                        /
      |                   |   /       <-- Response:
  Join/Leave       +-------------+ AMTRELAY=2001:db8::f
   Signals         | AMT gateway |
      |            +-------------+
      |                   |        2: Propagate RPF for Join(S,G)
      |        Multicast  |
                Network   |
                          |        1: Join(S=2001:db8:c::f,G=ff33::cd)
                   +-------------+
                   |   Receiver  |
                   |  (end user) |
                   +-------------+

Ah, okay. Yep, that's what I missed.

>     source from an (S,G) in order to be useful to most AMT gateways.

That addresses my concern. Thanks!

> records obtained in a way other than by a reverse IP lookup."?

I think it's useful, in that it makes it clear that future documents can 
do so without conflicting with this document (should a situation arise 
for which that makes sense).

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Dec 2019 09:45:17 -0600

I just now noticed that something on the mail handling path mangled my 
diagram pretty badly. What I tried to send looks like this:

https://www.dropbox.com/s/4l5orheo0fyv64s/driad-diagram.txt?dl=0

/a

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 19 Dec 2019 19:08:42 +0000

Thanks Adam, the revised one looks good.  Your dedication to the
universal deployment of IPv6 is very inspiring.

Although I do think it ends up slightly less readable than the IPv4
version, I agree it's a reasonable tradeoff that helps to make IPv6
more natural to use when there's a choice, in alignment with the IAB
recommendation.  So I'll pull in your edit and make the text changes
to match the updated example.

However, I think I have to make a few changes to the addresses:
- For the multicast group I'll use ff3e::8000:d, to be a globally scoped
  address from the SSM space for dynamic allocation by a host (from
  Section 1 of RFC 4607 and Section 2.7 of RFC 2373)
- I'll make the sender the shorter address, so it fits into the diagram
  along with the larger group address I needed.  (The column count hits
  exactly on the limit...)

<revised-text>
                  +---------------+
                  |    Sender     |
   |    |         |  2001:db8::a  |
   |    |         +---------------+
   |Data|                 |
   |Flow|      Multicast  |
  \|    |/      Network   |
   \    /                 |        5: Propagate RPF for Join(S,G)
    \  /          +---------------+
     \/           |   AMT Relay   |
                  | 2001:db8:c::f |
                  +---------------+
                          |        4: Gateway connects to Relay,
                                      sends Join(S,G) over tunnel
                          |
                 Unicast           3: --> DNS Query: type=AMTRELAY,
                  Tunnel  |       /       a.0.0.0.0.0.0.0.0.0.0.0.
                                 /        0.0.0.0.0.0.0.0.0.0.0.0.
      ^                   |     /         8.b.d.0.1.0.0.2.ip6.arpa
      |                        /
      |                   |   /       <-- Response:
  Join/Leave       +-------------+         AMTRELAY=2001:db8:c::f
   Signals         | AMT gateway |
      |            +-------------+
      |                   |        2: Propagate RPF for Join(S,G)
      |        Multicast  |
                Network   |
                          |        1: Join(S=2001:db8::a,G=ff3e::8000:d)
                   +-------------+
                   |   Receiver  |
                   |  (end user) |
                   +-------------+

   In this simple example, the sender IP is 2001:db8::a, it is sending
   traffic to the group address ff3e::8000:d, and the relay IP is
   2001:db8::c:f.

   The content provider has previously configured the DNS zone that
   contains the reverse IP domain name for the sender's IP address so
   that it provides an AMTRELAY RR with the relay's IP address.  (See
   Section 4.3 for details about the AMTRELAY RR format and semantics.)
   As described in Section 2.5 of [RFC3596], the reverse IP FQDN of the
   sender's address "2001:db8::a" is:

   a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.
                                                                  arpa.

   The sequence of events depicted in Figure 2 is as follows:

   1.  The end user starts the app, which issues a join to the (S,G):
       (2001:db8::a, ff3e::8000:d).

   2.  The join propagates with RPF through the receiver's multicast-
       enabled network with PIM [RFC7761] or another multicast routing
       mechanism, until the AMT gateway receives a signal to join the
       (S,G).

   3.  The AMT gateway performs a reverse DNS lookup for the AMTRELAY
       RRType, by sending an AMTRELAY RRType query for the reverse IP
       domain name for the sender's source IP address (the S from the
       (S,G)).

       The DNS resolver for the AMT gateway uses ordinary DNS recursive
       resolution until it has the authoritative result that the content
       provider configured, which informs the AMT gateway that the relay
       address is 2001:db8::c:f.

   4.  The AMT gateway performs AMT handshakes with the AMT relay as
       described in Section 4 of [RFC7450], then forwards a Membership
       report to the relay indicating subscription to the (S,G).

   5.  The relay propagates the join through its network toward the
       sender, then forwards the appropriate AMT-encapsulated traffic to
       the gateway, which decapsulates and forwards it as native
       multicast through its downstream network to the end user.

   In the case of an IPv4 (S,G), the only difference in the AMT relay
   discovery process is the use of the in-addr.arpa reverse IP domain
   name, as described in Section 3.5 of [RFC1035], instead of the
   in6.arpa domain name.  For example, if the (S,G) is (198.51.100.12,
   232.252.0.2), the reverse IP FQDN for the AMTRELAY query would be
   "12.100.51.198.in-addr.arpa.". 
</revised-text>

Thanks,
Jake

On 2019-12-19, 07:45, "Adam Roach" <[email-masked]> wrote:

/a