Re: [Roll] Hosts part of the RPL instance? Re: definition of "RPL Domain"

[Emmanuel Baccelli <[e-mail]>]

I also agree with Ulrich, i.e. to keep the usual definitions of hosts,
routers and routing domain. An RPL routing domain would then naturally be a
routing domain where the routing protocol in use is RPL. Thus, is there a
need for any particular new definition?
cheers
Emmanuel

On Thu, Nov 17, 2011 at 5:13 PM, Yvonne-Anne Pignolet <
[e-mail]> wrote:

> I fully agree with Ulrich
>   *Yvonne-Anne Pignolet*
> Dr. Sc. ETH
> ABB Schweiz AG
> Segelhofstrasse 1K
> 5400 Baden-Dättwil, Switzerland
> Phone: [phone]
> Mobile: [phone]
> email: *[e-mail]* <[e-mail]>
>
>
> [e-mail] wrote on 17.11.2011 02:00:06:
>
> > From: Ulrich Herberg <[e-mail]>
> > To: Mukul Goyal <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>
> > Date: 17.11.2011 01:59
> > Subject: Re: [Roll] Hosts part of the RPL instance? Re: definition
> > of "RPL Domain"
> > Sent by: [e-mail]
> >
> > My 2cts on the various terminology discussions:
> >
> > - An "RPL host" seems contradictory to me. Either it is a host, in
> > which case it does not know anything about RPL, or it is an RPL
> > router (leaf node or not, it still remains a router). We should
> > allow for hosts (or be prepared to fight with the IAB for the next
> > years why we think that we should break the IP architecture).
> >
> > - A question that comes to my mind: Is it specified anywhere how to
> > add the RPL IP headers for the traffic direction to a data packet
> > from a host received by an RPL router?
> >
> > - "RPL domain"; We should just stick to official terminology, i.e,
> > "Routing Domain" in this case. I think it has been specified in RFC1136.
> >
> > - RPL traffic: I don't like the term. I would stick to either
> > control traffic or data traffic. Everyone understands these terms.
> > No need to invent new terms.
> >
> > Regards
> > Ulrich
> >
> > On Nov 17, 2011, at 2:38, Mukul Goyal <[e-mail]> wrote:
> >
> > > I guess the desired behavior would be:
> > >
> > > A host sends out a message to its RPL router. The router adds RPL
> > SRH or RPL option to the IPv6 header and forwards the message
> > further. No need for IP-in-IP tunneling. Any error message comes
> > back to the router and the router handles the message. The host just
> > sends and receives messages.
> > >
> > > Thanks
> > > Mukul
> > >
> > > ----- Original Message -----
> > > From: "Mukul Goyal" <[e-mail]>
> > > To: "Don Sturek" <[e-mail]>
> > > Cc: [e-mail]
> > > Sent: Wednesday, November 16, 2011 12:29:59 PM
> > > Subject: Re: [Roll] definition of "RPL Domain"
> > >
> > > Hi Don
> > >
> > > I dont want hosts to know about RPL. I just want the RPL routers
> > to consider the hosts as part of the RPL instance so that the RPL
> > router does not have to do IP-in-IP tunneling to forward packets
> > generated by a host.
> > >
> > > Thanks
> > > Mukul
> > >
> > > ----- Original Message -----
> > > From: "Don Sturek" <[e-mail]>
> > > To: "Mukul Goyal" <[e-mail]>, "Sébastien Dawans"
> > <[e-mail]>
> > > Cc: [e-mail]
> > > Sent: Wednesday, November 16, 2011 12:22:55 PM
> > > Subject: Re: [Roll] definition of "RPL Domain"
> > >
> > > Hi Mukul,
> > >
> > > I guess my view on this is the opposite of yours.  I would like to see
> > > host-only devices not need to know anything about RPL.  Here is why:
> > > 1)  Code savings.   Removing RPL from these host only devices would
> allow
> > > for deployment on smaller footprint devices
> > > 2)  Battery operated devices.   Some host only devices are deployed on
> > > non-mains powered devices.  It would be nice for these devices to not
> have
> > > to listen for any RPL control messages yet still support transmission
> into
> > > a RPL routing domain.
> > >
> > > Don
> > >
> > >
> > >
> > > On 11/16/11 10:07 AM, "Mukul Goyal" <[e-mail]> wrote:
> > >
> > >> Hi Sebastien
> > >>
> > >> First, I would like to clarify that the need to define "RPL domain"
> arose
> > >> because draft-ietf-6man-rpl-option and
> draft-ietf-6man-rpl-routing-header
> > >> were using the term. Now, these drafts use the term "RPL instance" and
> > >> hence there is no real need to define the term "RPL domain" any more.
> I
> > >> will change draft-ietf-roll-p2p-measurement so that all references to
> > >> "RPL domain" are changed to "RPL Instance".
> > >>
> > >> Now returning to the question whether hosts should be considered part
> of
> > >> the RPL Instance, the benefit of doing so is that there is no need to
> use
> > >> IP-in-IP tunneling when a host sends out some data. If a host is not
> > >> considered part of the RPL Instance, its default RPL router is
> obliged to
> > >> use IP-in-IP tunneling to forward the packet further. IP-in-IP
> tunneling
> > >> means an extra IPv6 header and thus less space for payload if you
> want to
> > >> avoid fragmentation. Also, if the packet is traveling along a DAG, the
> > >> encapsulation/decapsulation needs to be done at every hop, which
> sounds
> > >> fairly heavy duty processing to me.
> > >>
> > >> So, I would like to explore if there is a way we could consider hosts
> to
> > >> be a part of the RPL Instance.
> > >>
> > >> Regards,
> > >> Mukul
> > >>
> > >>> On what ground would you assume that a non-RPL aware host connected
> to a
> > >>> RPL-router (in this case I would call it a border router) is in a/the
> > >>> RPL Domain?
> > >>
> > >>> From what I've seen in the drafts, the term "RPL Domain"'s primary
> > >>> purpose it to differentiate the limits of "RPL-aware" nodes for IP
> > >>> traffic that needs to transit to or from a set of RPL-aware hosts
> (for
> > >>> example, to define where to add/remove the RPL IPv6 Hop-by-Hop
> Option if
> > >>> used).
> > >>
> > >>> To me, this interpretation of RPL Domain is thus only useful in a
> local
> > >>> context and not to meant to designate one or more bounded set of
> nodes.
> > >>> That's the role of DODAGs and Instances.
> > >>
> > >>> Best Regards,
> > >>
> > >>> Sébastien Dawans
> > >>
> > >> On 11/16/2011 02:20 PM, Mukul Goyal wrote:
> > >>> So, the revised doubts are as follows:
> > >>>
> > >>> 1. It is clear that RPL routers are within an RPL domain but what
> about
> > >>> the RPL-unaware IPv6 hosts attached to an RPL router? I would imagine
> > >>> that such hosts are also within an RPL domain.
> > >>>
> > >>> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a
> set
> > >>> of RPL instances in the LLN? Can multiple RPL domains exist within an
> > >>> LLN? Or is it that an RPL domain is same as an LLN using RPL as a
> > >>> routing protocol?
> > >>>
> > >>> THanks
> > >>> Mukul
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Mukul Goyal"<[e-mail]>
> > >>> To: "Thomas Heide Clausen"<[e-mail]>
> > >>> Cc: "roll"<[e-mail]>
> > >>> Sent: Wednesday, November 16, 2011 7:15:59 AM
> > >>> Subject: Re: [Roll] definition of "RPL Domain"
> > >>>
> > >>>
> > >>>> Now that we are at it: what is an RPL host? Or rather, why is this
> > >>>> even a conceivable thing to define? Afaik, RPL is a routing
> protocol,
> > >>>> and as such should concern only routers - not hosts?
> > >>>>
> > >>> My bad. By RPL host, I actually meant an RPL leaf node. I think this
> > >>> term "RPL host" was in use at one point in time but I cant find a
> > >>> reference to it in current spec.
> > >>>
> > >>> THanks
> > >>> Mukul
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Thomas Heide Clausen"<[e-mail]>
> > >>> To: "Mukul Goyal"<[e-mail]>
> > >>> Cc: "JP Vasseur"<[e-mail]>, "roll"<[e-mail]>
> > >>> Sent: Wednesday, November 16, 2011 6:25:31 AM
> > >>> Subject: Re: [Roll] definition of "RPL Domain"
> > >>>
> > >>> Now that we are at it: what is an RPL host? Or rather, why is this
> even
> > >>> a conceivable thing to define? Afaik, RPL is a routing protocol, and
> as
> > >>> such should concern only routers - not hosts?
> > >>>
> > >>> I worry if this is inventing an entire ecosystem which "pretends to
> be
> > >>> just like the Internet, except it is not", as it needs entirely new
> > >>> stacks, protocols, translators/gateways everywhere, and with no real
> > >>> traces of IP as we know it remaining?
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> Roll mailing list
> > >> [e-mail]
> > >>
> https://www.ietf.org/mailman/listinfo/roll
>
> > >> _______________________________________________
> > >> Roll mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/roll
> > >
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>