backbone for a
multilink subnet.
Cheers,
Pascal
-Original Message-
From: 6lo-boun...@ietf.org [mailto:6lo-boun...@ietf.org] On Behalf Of Michael
Richardson
Sent: lundi 26 août 2013 02:37
To: 6...@ietf.org; 6...@ietf.org
Subject: [6lo] 6lowpan-backbone-router-03
Pascal Thubert (pthubert) wrot
août 2013 22:56
To: Samita Chakrabarti; 6...@ietf.org; 6...@ietf.org
Cc: Erik Nordmark (nordm...@acm.org); Pascal Thubert (pthubert)
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted
Hi,
I haven't had a chance to do a thorough read though, however I haven't been
ab
Thubert (pthubert)
Subject: New Version Notification for
draft-thubert-6lowpan-backbone-router-03.txt
A new version of I-D, draft-thubert-6lowpan-backbone-router-03.txt
has been successfully submitted by Pascal Thubert and posted to the IETF
repository.
Filename:draft-thubert-6lowpan
+1
Cheers,
Pascal
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
George, Wes
Sent: mardi 11 octobre 2011 21:34
To: Brian Haberman; IPv6 WG Mailing List
Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac
Support adoption
Thanks,
Hi Thomas:
I've seen different requirements depending on where the utilization
would be.
a) Close to the source of the source or destination, the flow label
could be used in an application-aware fashion, for instance to influence
the routing of the packet in VRFs. We'll note that we do not have a
Hi Daniel:
Thanks for the heads up.
The text in RPL assumes that the node receives a packet, processes the
RH (swaps the destination) and then forwards to the new next hop. If
that fails, it seems easier to pass the resulting packet as it now
stands than to recomputed the packet as it was receive
Hi Brian:
RPL made a pass to clean up the interface with the HbH spec whereby:
- RPL defines the bits and bytes that need to be transported, and when
the information needs to be transported in a packet
- HbH (this spec) defines how the RPL packet information is placed in
and obtained from the pac
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
> Pascal Thubert (pthubert)
> Sent: Tuesday, November 16, 2010 3:58 PM
> To: Brian Haberman; IPv6 WG Mailing List
> Cc: Bob Hinden
> Subject: RE: 6MAN WG Last Call:draft-ietf-6man-rpl-option
>
> Hi Brian:
nto a label that we commonly do today.
Pascal
http://www.xtranormal.com/watch/7011357/
> -Original Message-
> From: Rémi Després [mailto:remi.desp...@free.fr]
> Sent: Tuesday, September 21, 2010 5:10 PM
> To: Pascal Thubert (pthubert)
> Cc: JP Vasseur; IPv6 WG; ROLL WG
>
here 1:1 vlans apply today.
Take care,
Pascal
> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: Tuesday, September 21, 2010 4:18 PM
> To: Michael Richardson
> Cc: Pascal Thubert (pthubert); ROLL WG; IPv6 WG
> Subject: Re: [Roll] Flow Label
ecial silicon for that
operation, which current routers obviously do not have. Etc...
Pascal
> -Original Message-
> From: Rémi Després [mailto:remi.desp...@free.fr]
> Sent: Tuesday, September 21, 2010 2:28 PM
> To: Pascal Thubert (pthubert)
> Cc: JP Vasseur; IPv6 WG; R
Hi Rémi:
It would not.
We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL being layer 2
agnostic cannot depend on 6LoWPAN.
Header and IP in IP insertion is problematic on any network, be it for the MTU
issues only.
The FL for RPL discussion illustrates that there can be multip
le.com]
> Sent: Thursday, September 16, 2010 6:44 PM
> To: Pascal Thubert (pthubert)
> Cc: Philip Levis; Carsten Bormann; r...@ietf.org; ipv6@ietf.org;
> m...@sandelman.ca; Brian E Carpenter
> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
>
> On 09/16/
r 15, 2010 4:36 AM
> To: Philip Levis
> Cc: Pascal Thubert (pthubert); Carsten Bormann; r...@ietf.org;
ipv6@ietf.org;
> m...@sandelman.ca; Brian E Carpenter
> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
>
> On 08/11/10 04:41 PM, Philip Levis wrote:
>
>
Hi Brian and Rémi:
This set of rules recognizes that the flow label can be overridden to be used
locally in a network according to the rules and policies that apply to this
network. I'm all for it.
OTOH, the proposal assumes that the rules in place in that network are
necessarily related to loa
Hi Pekka:
Redirect is almost useless on non-transitive links (NBMA) at large, not
only P2P.
Radios being non-transitive, you'll see more and more of those beasts.
And a radio router usually uses only radios. So there's a whole family
of routers that have strictly no use of redirect.
If we decide t
the information we need in the Flow
Label should it be mutable.
Pascal
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Rémi Després
> Sent: Thursday, August 12, 2010 2:55 PM
> To: Pascal Thubert (pthubert)
> Cc: ipv6
> >>
> >>Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable
> > bits.
> >>
> >>Pascal> They are used as an in-band control plane that checks
the
> >>Pascal> consistency of routing states along a path. Those states
> > can
> >>Pascal> easily get out of sync due to the nat
Hi Brian:
The Hop by Hop is certainly the clean solution.
The trouble is that it requires additional bytes in every packet for the
header and for the IP-in-IP encapsulation that goes with it; yet RPL
operates in a domain where devices can be strictly constrained in energy
and frames can be very
>
> Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable
bits.
>
> Pascal> They are used as an in-band control plane that checks the
> Pascal> consistency of routing states along a path. Those states
can
> Pascal> easily get out of sync due to the nature of the links, bu
Salut Rémi,
Please see below:
Pascal
> -Original Message-
> From: Rémi Després [mailto:remi.desp...@free.fr]
> Sent: Monday, August 09, 2010 1:50 PM
> To: Pascal Thubert (pthubert)
> Cc: 6man 6man; Michael Richardson; r...@ietf.org; Carsten Bormann
> Subject: Re: F
Hi Brian:
> On 2010-08-09 22:17, Pascal Thubert (pthubert) wrote:
> > Hi Michael:
> >
> > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I
> > tried to stay within the lines of RFC 3697 as you also defend in your
> > mail.
> >
>
table bits are
enough for the sensible usages envisioned so far?
Pascal
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
> Michael Richardson
> Sent: Wednesday, August 04, 2010 4:05 AM
> To: r...@ietf.org; Carsten Bormann
or destination subnet or
global).
Cheers,
Pascal
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Thursday, July 29, 2010 11:35 PM
> To: Michael Richardson
> Cc: Pascal Thubert (pthubert); ipv6@ietf.org
> Subject: Re: Flow
to post a small draft soon.
Pascal
> -Original Message-
> From: Mohacsi Janos [mailto:moha...@niif.hu]
> Sent: Thursday, July 29, 2010 3:28 PM
> To: Pascal Thubert (pthubert)
> Cc: Aleksi Suhonen; ipv6@ietf.org; m...@sandelman.ca
> Subject: RE: Flow Label: 12 bits mut
Hi Aleksi:
I think that the premise in the discussion was that the network egress
is incapable of restoring zero.
This taken into account we observe that:
- there is a clear and documented need for the network to tag the
packet. This happens for load balancing reasons, but also for routing
reas
Hi Mark:
A new ND registration model is being developed at 6LoWPAN to enable a
proactive population of the ND cache - table, really -. Applying the ND
registration to the P2P link case, the endpoint routers would need to
register to one another prior to delivering packets on that link. Any
packet
+1 on adopting the two RPL drafts. And starting the work on the 3rd !
Pascal
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
> Don Sturek
> Sent: Monday, June 14, 2010 10:55 PM
> To: 'Brian Haberman'; 'IPv6 WG Mailing List'
> Subject: RE: Co
interface, then we have to formalize what
an interface ID is. That might be going too far for a spec like this?
Thanks a bunch Vishwas,
Pascal
> On Fri, Jun 11, 2010 at 12:57 AM, Pascal Thubert (pthubert)
> wrote:
> > Hi:
> >
> > This is additional work linked to t
Tool [mailto:idsubmiss...@ietf.org]
Sent: Thursday, June 10, 2010 3:21 PM
To: Pascal Thubert (pthubert)
Subject: New Version Notification for
draft-thubert-6man-reverse-routing-header-00
A new version of I-D, draft-thubert-6man-reverse-routing-header-00.txt has been
successfully submitted by Pascal Thuber
Hi Kris:
I would adhere to your idea but not that it applies to 6LoWPAN ND.
We are not rewriting IP from scratch. We are not even reinventing ND.
We are adding another mechanism to the NDP suite, which already counts a
number of them (3122, 4861, 4862...).
It is a surprise for nobody that we h
Hi Zach:
A useful (informational) reference.
I understood that we now call the whole LoWPAN the link though we still
restrict the use of link local for the radio range.
Autoconf still uses the radio range as link. Also it is has:
"
o There is no mechanism to ensure that IPv6 link-local ad
Hi:
Version 01 of the 3122-bis proposal for inverse ND is now available. The
draft generalizes the use of Inverse-ND to a number of interfaces and in
particular as a helper for first hop security. It also fixes some format
error from the original RFC and suggests a way to provide SeND in
Inverse N
008 15:50
>To: Pascal Thubert (pthubert)
>Cc: Eric Levy- Abegnoli (elevyabe)
>Subject: New Version Notification for draft-thubert-3122bis-00
>
>
>A new version of I-D, draft-thubert-3122bis-00.txt has been successfuly
submitted by Pascal Thubert
>and posted to the IETF reposi
draft?
Thanks,
Pascal
>-Original Message-
>From: patent-administrators(mailer list)
>Sent: mardi 4 novembre 2008 14:14
>To: Patrick Wetterwald (pwetterw); Pascal Thubert (pthubert)
>Cc: Laurie Mintz (lamintz)
>Subject: [CPOL 443213] "Arrangement for reaching IPv4 public
Hi Jim:
Please see inline:
>> ISA100.11a is defining a simple transport level security above UDP
>> that is based on the AES encryption engine in the CCM mode
>(in reality
>> CCM* as defined by 802.15.4, annex B, which refers to CCM as defined
>> by ANSI X9.63-2001 as well as NIST Pub 800-38
Hi Jim:
All I can say is that at least one Wireless Sensor Network standard under
development will not use IPSec. ISA100.11a
(http://www.isa.org/MSTemplate.cfm?MicrositeID=1134&CommitteeID=6891) has
decided to endorse - and extend when necessary - the work done at 802.15.4 and
6LoWPAN, which m
So we can see that as a migration technique too: when you have a
plurality of IPv4 networks that you do not want to migrate immediately,
this might actually provide a way to migrate at your own rhythm. As you
point out it is easy to define the double-mapped format using a mix of
mapped address and
> If you have followed the discussion closely, you should have
> noticed that ARP is a lot better than ND in a typical
> environment where WLANs are used as leaf of the Internet.
>
> So, as a short term solution, I'd like to suggest to use ARP,
> not ND, over WLAN.
>
> As a long term solution, I
>
> I think that the Point-to-Point idea has some merits,
> but the applicability is not general.
>
> I think that if we're going to keep the ethernet-like
> nature of WLAN (it is a deployed base) then the
> hosts which are aware of their performance issues
> need to respond to them.
>
> I'll se
> In any discovery this is going to be a problem, since
> any discovery will require multicast at the MAC layer.
Note that if the hub and spoke quality of the 802.11 (enterprise mode)
network was not lost on the way of emulating ethernet, then the
discovery could happen in an alternate fashion, a
>
> >>Broadcast over the domain is a lot less reliable than unicast.
>
> > I'm not sure that the question is whether ND is good or poor, OSPFv3
is
> > good or poor, etc... All these protocols have proven their qualities
in
> > the context they were designed for.
>
> Though OSPF has its own probl
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Masataka Ohta
> Sent: mardi 15 juin 2004 06:06
> To: Ignatios Souvatzis
> Cc: Jari Arkko; Pascal Thubert (pthubert); IPv6 WG; Pekka Savola; Greg
Daley
> Subject: Re: WLAN (was Re: IPv6
> Hi,
> unreliable flooding of control/routing packets is a long
standing
> problem in the MANET working group [1]. Recently the MANET working
group
> formed a design team that will tackle this problem among others that
arise
> when extending OSPF for wireless media. AFAIK, their design wil
Interestingly, part of this pain comes from the decision to provide
Ethernet emulation for 802.11, while some practical use cases do not
actually require a broadcast medium.
In particular, in the case of public access points, the desired effect
is a point to point connectivity with the access poin
>
> -Original Message-
> From: Soliman Hesham [mailto:[EMAIL PROTECTED]
> Sent: mercredi 17 mars 2004 09:38
> To: Pascal Thubert (pthubert); Jari Arkko
> Cc: [EMAIL PROTECTED]
> Subject: RE: Multiple DRs on a link
>
>
> > => There are many di
MRs on different links?
>
> => There are many different reasons. I sent a verly long
> email about this to nemo (monet back then). One simple
> scenario is that you might be walking around with a PAN
> that happens to have 2 MRs on a single link (e.g. a laptop
> and a mobile phone). The two MRs c
Hi Hesham:
In case that helps, we've found practical in some experimentations to
allow a MR to autoconf addresses on its ingress interfaces, and install
the associated connected routes. Note that if a MR listens to itself
from a different interface, it will not install the prefix.
Anyway, once th
Hi Nick:
If more voices can help, you have my full support as well :)
Pascal
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick 'Sharkey' Moore
> Sent: jeudi 19 février 2004 09:52
> To: [EMAIL PROTECTED]
> Subject: Optimistic DAD _again!_
>
> Hi IP
nt: mercredi 26 novembre 2003 06:45
> To: Pascal Thubert (pthubert)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
> Subject: Re: "ROUTERS" vs. "routers"
>
> On Tue, 25 Nov 2003 15:22:43 -
> "Pascal Thubert (p
Hi Havard
I believe it's worth opening the Pandora's box. I agree with Fred that things and
usages have changed.
On top of the MANET based examples that Fred proposed, I have in mind an other 'Half
and half' case. That's the concept on "Network in node" which is a basically a host
with a netwo
51 matches
Mail list logo