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.
> 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
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.
> IMO, routing domain is nicely defined in RFC 1136.
> 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)
> I translate a mesh subnet running RPL as a routing domain
> while an adminstrative domain can contain several interconnected RPL
domains
I don't think use of these terms helps define scope-3 at all.
peter van der Stok <stokc...@xs4all.nl> wrote:
> 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:
>> Michael...
>>
>> On Jul 24, 2013, at 6:37 PM 7/24/13, Michael Richardson
>> <mcr+i...@sandelman.ca> wrote:
>>
>>
>> Ralph Droms (rdroms) <rdr...@cisco.com> wrote:
>> 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?
>>
>> 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.
>>
>> 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.
>>
>> 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
>>
>>
>> Specific examples:
>> 1) two adjacent RPL domains, which do not share a prefix but are to be
>> 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.
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> r...@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> r...@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpOXpcp1UEkA.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
