You are correct, Carsten:

This also relates to the concept that was evoked earlier in the thread
to allow an implicit format on a RPL link. There's no such thing as a
RPL link. As you say, RPL control itself does not exhibit the HbH header
since most of it is 1 hop - link local. And then a link upon which RPL
is active can be shared with other activities that are not RPL related
at all. If the HbH is present, then the route lookup will be done along
a VRF that is indexed by the instanceID. Other tagging might come in the
future. And then there's the default RIB when the router has no better
indication in the packet.

I like your vlan analogy. It is quite usual in practice to map vlans
onto vrfs. Since we are doing route over, we are quite naturally
integrating the concepts. For the time being and considering the
constraints that apply to RPL, we found that one octet was the right
trade off to represent an instance. We'll probably see a day, though,
where the concept generalizes, and at that time we'll probably need 4
octets at least. In particular, RPL or something very much like RPL
would probably be very interesting in hierarchical access domains like
DSL where 1:1 vlans apply today.

Take care,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:[email protected]]
> Sent: Tuesday, September 21, 2010 4:18 PM
> To: Michael Richardson
> Cc: Pascal Thubert (pthubert); ROLL WG; IPv6 WG
> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
> 
> On Sep 21, 2010, at 15:48, Michael Richardson wrote:
> 
> >    Pascal> We'll be very glad that 6LoWPAN compresses RPL
> >    Pascal> optimally. But RPL being layer 2 agnostic cannot depend
on
> >
> > Only when the security is provide by the layer 2 can the layer 2 do
any
> > compression.   Otherwise, the encryption of the RPL messages renders
the
> > compression useless.
> 
> I think Pascal was talking about the encapsulation RPL provides for
data packets
> (RPL option, draft-ietf-6man-rpl-option-00.txt), not about actual RPL
messages.
> Do you think the encapsulation information will be encrypted?
> 
> Gruesse, Carsten

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to