Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

From: "roll issue tracker" <[email-masked]>
Date: Thu, 11 Jul 2013 20:47:13 -0000

#132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

Comment (by [email-masked]):

 The most recent rev of draft-droms-6man-multicast-scopes defines scope
 0x03 as:

  3  Network-Specific scope, greater than Link-Local scope, defined
      automatically from the network topology

 To be confirmed: will this definition suffice for MPL?

-- 
---------------------------------------+------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                     |      Status:  new
 Priority:  major                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Jul 2013 17:14:07 -0400

> To be confirmed: will this definition suffice for MPL?

I think it is sufficient, because we understand what it means.
I am concerned about the word "Network"... which could mean anything to anyone.

I'd think that the right word would be "subnet", because the intent is that
it is for the entire /64 or whatever it is that one is using.  I think that
is the term that is used in RFC4291.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Jul 2013 15:29:40 -0700

> is the term that is used in RFC4291.

I think that having a network-wide, multi-link subnet is a bad idea:
http://tools.ietf.org/html/rfc4903

Regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Jul 2013 17:40:19 -0700

That's what I feared... I think it's an unfortunate decision.

Btw, should that mean that RFC4903 should be obsoleted?

Ulrich

On Thu, Jul 11, 2013 at 5:05 PM, Ralph Droms (rdroms) <[email-masked]> wrote:
>
>
> On Jul 11, 2013, at 6:29 PM, "Ulrich Herberg" <[email-masked]> wrote:
>
> That decision has already been made and is carried through many protocols..
>
> - Ralph
>
>>
>> Regards
>> Ulrich

---

From: Don Sturek <[email-masked]>
Date: Thu, 11 Jul 2013 20:15:25 -0700

Hi Ulrich,

I think the multi-link subnet is an unfortunate side effect of route over
mesh protocols.

I would be interested in hearing of any solution around this since we (the
folks implementing ZigBee IP) seemed to have to go through a lot of
trouble over multi-link subnets.....

Don

On 7/11/13 5:40 PM, "Ulrich Herberg" <[email-masked]> wrote:

>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Jul 2013 21:31:07 -0700

Hi Don,

The IETF has already documented a solution in
http://tools.ietf.org/html/rfc5889
(using /128 prefixes)

I wrote a whole chapter on that issue in my Ph.D. Thesis a few years ago:
http://herberg.name/downloads/pubs/thesis.pdf

Regards
Ulrich

On Thursday, July 11, 2013, Don Sturek wrote:

> On 7/11/13 5:40 PM, "Ulrich Herberg" <[email-masked] <javascript:;>>
> wrote:
>
> >On Thu, Jul 11, 2013 at 5:05 PM, Ralph Droms (rdroms) <[email-masked]<javascript:;>
> >
> >wrote:
> >>
> >>
> >> On Jul 11, 2013, at 6:29 PM, "Ulrich Herberg" <[email-masked]<javascript:;>
> >
> >>wrote:
> >>
> >>> <[email-masked] <javascript:;>> wrote:
> >>>>
> >[email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 12 Jul 2013 04:51:19 +0000

The issue at hand is defining a new multicast scope.  Any multicast scope greater than link-local covers multiple links by definition.

Or are you simply saying that you disagree with Michael's suggestion and would prefer a name other than "subnet"?

--
Jonathan Hui

On Jul 11, 2013, at 9:31 PM, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Don,

The IETF has already documented a solution in http://tools.ietf.org/html/rfc5889
(using /128 prefixes)

Regards
Ulrich

Don

On 7/11/13 5:40 PM, "Ulrich Herberg" <[email-masked]<javascript:;>> wrote:

>On Thu, Jul 11, 2013 at 5:05 PM, Ralph Droms (rdroms) <[email-masked]<javascript:;>>
>wrote:
>>
>>
>> On Jul 11, 2013, at 6:29 PM, "Ulrich Herberg" <[email-masked]<javascript:;>>
>>wrote:
>>
>>> <[email-masked]<javascript:;>> wrote:
>>>>
>[email-masked]<javascript:;>

_______________________________________________
Roll mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Jul 2013 22:05:57 -0700

Jonathan,

On Thu, Jul 11, 2013 at 9:51 PM, Jonathan Hui (johui) <[email-masked]> wrote:
>
> The issue at hand is defining a new multicast scope.  Any multicast scope
> greater than link-local covers multiple links by definition.
>

Yes, that is what I am saying. That said, I understand Michael's
concern about the word "network" (but have no better proposal so far).

Best regards
Ulrich

> On Jul 11, 2013, at 9:31 PM, Ulrich Herberg <[email-masked]> wrote:
>
> Hi Don,
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 12 Jul 2013 00:05:13 +0000

- Ralph

---

From: Don Sturek <[email-masked]>
Date: Fri, 12 Jul 2013 09:11:36 -0700

Hi Ulrich,

I don't think the Trickle Multicast draft would be too different even if a
/128 was used instead of the "all MPL forwarders"ŠŠ

Don

From:  Ulrich Herberg <[email-masked]>
Reply-To:  Routing Over Low power and Lossy networks <[email-masked]>
Date:  Thursday, July 11, 2013 9:31 PM
To:  Routing Over Low power and Lossy networks <[email-masked]>
Cc:  "Ralph Droms (rdroms)" <[email-masked]>
Subject:  Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 -
subnet-local

Hi Don,

Regards
Ulrich

On Thursday, July 11, 2013, Don Sturek  wrote:
> On 7/11/13 5:40 PM, "Ulrich Herberg" <[email-masked] <javascript:;> >
> wrote:
> 
>> >On Thu, Jul 11, 2013 at 5:05 PM, Ralph Droms (rdroms) <[email-masked]
>> <javascript:;> >
>> >wrote:
>>> >>
>>> >>
>>> >> On Jul 11, 2013, at 6:29 PM, "Ulrich Herberg" <[email-masked]
>>> <javascript:;> >
>>> >>wrote:
>>> >>
>>>> >>> <[email-masked] <javascript:;> > wrote:
>>>>> >>>>
_______________________________________________ Roll mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 12 Jul 2013 09:32:43 -0700

Hi Don,

My comment was more regarding multi-link subnets (and usage of the
term "subnet" as multicast scope). All the issues mentioned in RFC4903
disappear when using host prefixes.

Best regards
Ulrich

On Fri, Jul 12, 2013 at 9:11 AM, Don Sturek <[email-masked]> wrote:
> /128 was used instead of the "all MPL forwarders"……
>
> Don
>
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 15 Jul 2013 10:55:40 +0000

(BCC: 6man mailing list, which is where this document is intended to become a work item)

> is the term that is used in RFC4291.

"subnet" implies that this multicast scope must derive from the address assignment topology.  The first (and only) use case is derived from the /64 prefix; do we want to have that limitation for all uses of scope 0x03?

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Jul 2013 12:42:21 -0400

Ralph Droms (rdroms) <[email-masked]> wrote:
    >>> The most recent rev of draft-droms-6man-multicast-scopes defines
    >>> scope 0x03 as:
    >>
    >> I think it is sufficient, because we understand what it means.  I am
    >> concerned about the word "Network"... which could mean anything to
    >> anyone.
    >>
    >> I'd think that the right word would be "subnet", because the intent is
    >> that it is for the entire /64 or whatever it is that one is using.  I
    >> think that is the term that is used in RFC4291.

    > "subnet" implies that this multicast scope must derive from the address
    > assignment topology.  The first (and only) use case is derived from the
    > /64 prefix; do we want to have that limitation for all uses of scope
    > 0x03?

I think so.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 16 Jul 2013 12:41:47 +0000

> I think so.

Same here.

Pascal

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Jul 2013 23:59:44 +0100

This draft is on the 6man agenda for Berlin.  I expect the discussion will be taken up there.

In my opinion, the multicast scope should not be tied, thought the words in the description of the scope, to the address assignment architecture.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jul 2013 14:32:56 -0400

> In my opinion, the multicast scope should not be tied, thought the
    > words in the description of the scope, to the address assignment
    > architecture.

Do you have a specific use case that you are thinking of?

How can it be tied to the subnet, and yet not be related to the address
assignment architecture?  Can you suggest another definition?

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Jul 2013 03:44:55 +0200

> would prefer a name other than "subnet"?

I prefer using *sub-cluster* or *net-cluster* for MPL purposes.

AB

>
> --
> Jonathan Hui
>
> On Jul 11, 2013, at 9:31 PM, Ulrich Herberg
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Don,
>
>>>>>>scope

---

From: Robert Cragie <[email-masked]>
Date: Tue, 23 Jul 2013 18:44:18 +0100

+1

So "subnet" is not the right term. I think "network" as Ralph wrote is 
fine but if the disassociation with network addressing needs to be 
clear, why not use the term "domain"? After all, trickle-mcast talks 
about MPL Domains. I appreciate it may have some pre-established 
connotations but from an abstract definition point of view, "domain" 
seems eligible enough.

Robert

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 24 Jul 2013 02:38:26 -0700 (PDT)

----- Original Message -----
> From: Robert Cragie <[email-masked]>
> To: [email-masked]; [email-masked]
> Cc: 
> Sent: Wednesday, 24 July 2013 3:44 AM
> Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 -	subnet-local
> 
> +1
> 

I think "domain" is really good when there is a qualifier on the front e.g., addressing domain, routing domain, multicast domain etc.

Regards,
Mark.

>>  In my opinion, the multicast scope should not be tied, thought the words in 
> the description of the scope, to the address assignment architecture.
>> 
>>  - Ralph
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 24 Jul 2013 11:43:32 +0200

> I think "domain" is really good when there is a qualifier on the front
> e.g., addressing domain, routing domain, multicast domain etc.

agree

Peter

Mark ZZZ Smith schreef op 2013-07-24 11:38:
> I think "domain" is really good when there is a qualifier on the front
> e.g., addressing domain, routing domain, multicast domain etc.
> 
> Regards,
> Mark.
> 
> Robert
> 
> This draft is on the 6man agenda for Berlin.  I expect the discussion 
> will
> be taken up there.
> 
> words in

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2013 10:58:29 -0400

I would still like an explanation of why "subnet" is the wrong term.

When would scope-3 would be used such that it would not correspond to the set
of links on which a "/64" (or other size) is used?

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 24 Jul 2013 15:21:16 +0000

> of links on which a "/64" (or other size) is used?

Hm, I thought I responded but apparently not...

This change to scope 0x03 is not just for MPL, so we don't know how else it might be used in the future.

Specific examples:

1) two adjacent RPL domains, which do not share a prefix but are to be considered as one realm for mDNS
2) one RPL domain and one other non-RPL subnet that are to be considered as one realm for mDNS

- Ralph

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 24 Jul 2013 08:32:14 -0700

I have pointed out two documents in my earlier email that explain in
long detail why I believe that multi-hop subnets are a really bad
idea. The AUTOCONF RFC 5889 presents an architecture for avoiding all
these problems by using /128 prefixes. In that regards, a subnet wide
flooding would be fairly uninteresting, as it would not go beyond a
single router.

Regards
Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2013 12:37:44 -0400

> else it might be used in the future.

I understand, but perhaps it would be better, if, when another use case comes
along, they write a document explaining why scope-3 is correct and
non-conflicting with the trickle mcast use case.

    > considered as one realm for mDNS

I accept that this is a plausible scenario, but I believe that it
presupposes a technical answer from the not-yet occured sdnsext BOF.
sDNSext could well mandate a proxy solution where actual multicast packets do
not cross that boundary.

    > 2) one RPL domain and one other non-RPL subnet that are to be considered as one realm for mDNS

Do you mean, in fact, one LLN and another non-LLN technology, which have MPL
capable routers connecting them?

I write it this way, because I think that there is a belief that RPL can only
be used in LLNs, while the RPL architecture is very specifically for multiple
link types, and I find it hard to imagine an MPL capable router which does
not also speak RPL.

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Jul 2013 17:47:21 +0100

Can you provide a practical example of how you would configure IPv6 
addresses for a simple RPL network comprised of, say, a DODAG root and 
two RPL routers at a rank above? And generally how route-over networks 
would work where interfaces are assigned solely a /128 prefix? 
Forbidding the use of a subnet prefix on the basis that link 
connectivity cannot be guaranteed seems rather odd to me.

Robert

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Jul 2013 09:49:42 -0700

Hi Ulrich,

I did review the you cited in your earlier e-mail (RFC 5889).   It seems
that RFC suggests that link local addresses not be generated for
interfaces with undetermined link characteristics (which certainly apply
to route over protocols like ROLL RPL and the MANET protocols).

However, in looking 6LoWPAN ND (RFC 6775), isn't assignment of link local
addresses to such a topology exactly what is going on?  If you add ROLL
RPL (RFC 655) to this deployment scenario and specifcally with the
illustrative examples in Annex A, it seems clear that a multi-hop subnet
is exactly what is described.

Next, if someone were to want to support a protocol like mDNS (RFC 6792)
which uses link locals, how could that be supported using RFC 5889?

I think these are important topics as we seemed to have to go to extremes
in our work (ZigBee IP) to deal with ULAs when it would have been great if
link locals were available in the context of a route over protocol like
ROLL RPL.

Don

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 25 Jul 2013 09:13:53 +0000

Michael...

> non-conflicting with the trickle mcast use case.

I don't agree; in my opinion, it's better to release scope 0x03 from "reserved" state and give guidelines for its use.

Let's see how 6man WG consensus develops...

- Ralph

---

From: peter van der Stok <[email-masked]>
Date: Thu, 25 Jul 2013 14:53:06 +0200

For me RFC 1136 was quite clarifying.

It states that the Internet subnet term is ambiguous
- It refers to one-hop IP connectivity
- it refers to address hierarchy

RFC 1136 defines the adminsitrative domain and the routing domain

IMO, routing domain is nicely defined in RFC 1136.

an adminsitrative domain can contain one or more routing domains.

I translate a mesh subnet running RPL as a routing domain
while an adminstrative domain can contain several interconnected RPL 
domains

For the latter I understood we want to use scope-3 to run for example 
service discovery.
and in our case multicast to multiple devices where the network topology 
is motivated by history, and organizational and physical constraints.

Any mistakes in the above?

Peter

Ralph Droms (rdroms) schreef op 2013-07-25 11:13:
> I don't agree; in my opinion, it's better to release scope 0x03 from
> "reserved" state and give guidelines for its use.
>

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 06:06:59 -0700

Hi Peter,

What you wrote seems exactly correct.

The one area that I think needs some work (maybe 6MAN?) is the forwarding
rules when encountering scope-3 packets.  For example, if I am a border
router with 5 interfaces each with a different prefix, which of those
interfaces do I forward the packet to and which do I not (eg, which
interfaces face inward in my topology and which face outward).   If there
is already an RFC on this topic a reference would be greatly appreciated.

Don

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2013 10:07:05 -0400

> "reserved" state and give guidelines for its use.

I think that we agree about what we want.

What I see you saying is that you want a definition which I find rather
(technically) vague, in anticipation of uses which are not yet well defined,
and may never come to pass.

I'm saying, let's make the MPL scope-3 use case clear and precise, and if
another situation comes along for which scope-3 is appropriate, let's extend
the definition at that time.

Otherwise, this reminds of site-local scope:
  We defined it in what we thought were clear terms for a human, but which
  turned out to be too vague for machines, with the result that it could never
  be discovered/used.

Meanwhile, I think that MPL is hung up waiting for this to be properly
clarified.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2013 10:19:13 -0400

It is important to keep the 6man CC, since the document is a 6man document.
I will top-post your entire comments for 6man, but then copy them again
and comment.

    > - it refers to address hierarchy

Please recognize that RFC1136 is from an era prior to classless domain routing.
Subnetting in that period of time referred to taking a class-ful route
("class A", "class B", "class C") and further dividing it within an AS.

RFC1136 also predates BGP4, and therefore even the term AS is not used.
Further, it's a translation from OSI to IETF terminology.

    > an adminsitrative domain can contain one or more routing domains.

In the internet today, one has Autonomous Systems (AS), identified by
AS Numbers in BGP4.  The terms routing domain and administrative domains
are not also very precise today.
For ISPs, an administrative domain may correspond to the convex set of all
networks that announce using the same ASN.  Some ISPs have non-convex
parts of their networks, and use multiple ASNs.

A routing domain might be said to be akin to an OSPF area, which is typically
a subset of an ASN. (In particular, the convex nature of BGP4 means that an
AS needs to have full connectivity within)

    > while an adminstrative domain can contain several interconnected RPL domains

I don't think use of these terms helps define scope-3 at all.

    > while an adminstrative domain can contain several interconnected RPL domains

    > For the latter I understood we want to use scope-3 to run for example service
    > discovery.
    > and in our case multicast to multiple devices where the network topology is
    > motivated by history, and organizational and physical constraints.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 25 Jul 2013 14:46:45 +0000

> I think that we agree about what we want.

Sorry, I disagree.  I simply want to release the scope from "(reserved)" state and write down whatever constraints needed for consistency with other scopes.

Jinmei-san (if I may make an inference from his e-mail) supports writing this definition into  and made the helpful suggestion to add the MPL use case as an example, which I support.

> Meanwhile, I think that MPL is hung up waiting for this to be properly

Really?  I suggest MPL is hung up waiting author revisions for several last call comments, including this one - none of which have been addressed since the last call back in March.  This issue could be addressed directly in the roll WG by explicitly writing down the behavior of scope 0x03 for MPL forwarding in the MPL spec, which is, in my opinion, where it belongs.

My point is that, in my opinion, reserving scope 0x03 for MPL is not the right thing to do.

- Ralph

---

From: Robert Cragie <[email-masked]>
Date: Fri, 26 Jul 2013 08:46:00 +0100

+1 to all Ralph says below.

I support draft-droms-6man-multicast-scopes-00 with the addition of 
using MPL as an example.

Robert

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2013 10:11:36 -0400

Having had a number of private exchanges with Ralph, I support the document
as worded.

It was not clear to me before that trickle-mcast will be *expected* to
define what it means for the scope to be "defined automatically from the
network topology"

I thought that further clarification of the use of scope-3 within MPL would
be considered an infringment upon 6man's charter.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 26 Jul 2013 00:53:57 -0700

At Thu, 25 Jul 2013 14:46:45 +0000,

> Jinmei-san (if I may make an inference from his e-mail) supports writing this definition into  and made the helpful suggestion to add the MPL use case as an example, which I support.

I didn't have a strong opinion about which one is better:
A: keep the definition of scope-3 generic (+ possibly show the MPL
   case as an example), or
B: limit the definition to the MPL case for now (+ possibly extend it
   in future as we find more specific cases)

My comment was that assuming the choice of keeping it generic is
given, it would still be helpful if we give a specific example case.

But, on thinking about it now, I think I have a leaning to approach A,
because the concept of address scope itself is generic while the MPL
case seems too specific.  And, as long as the 6man-multicast-scopes
document shows a specific example (so the definition won't be too
vague) and states future cases should be defined in separate RFCs (as
it does in the first sentence of Section 2 of the 00 version), it
seems to address the concerns that approach B would try to address.

Still not a strong opinion anyway, though.

--
JINMEI, Tatuya