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

[Adam Roach <[e-mail]>]

Thanks for the quick response! Some replies inline.

On 12/18/19 4:03 PM, Holland, Jake wrote:
> §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.
> [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,


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


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


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


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


That addresses my concern. Thanks!


> 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."?
>

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