Hi Hemant,
Sorry if I was not clear earlier.
Now that you agree that tunnelling/ transition mechanisms add headers
and the MTU problem is solved for them. Think of a similar solution
for the RH4 cases too.
Thanks,
Vishwas
On Mon, May 31, 2010 at 12:22 PM, Hemant Singh (shemant)
wrote:
>>-O
Hi Jonathan,
There are two cases, where a node knows about the header but does not
support its processing (Security or whatever reason). In that case we
can add information like you said. Also in case we assume all RPL
nodes have the stack as we define in the spec, we can assume the
behavior.
So
>-Original Message-
>From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
culler
>Sent: Monday, May 31, 2010 12:06 PM
>To: Erik Nordmark
>Cc: ipv6@ietf.org; culler Culler
>Subject: Re: I-D Action:draft-hui-6man-rpl-routing-header-00.txt
>Since we route WITHIN a RPL netwo
Hi Vishwas,
On May 31, 2010, at 12:05 PM, Vishwas Manral wrote:
This should be OK for our intended usage of RH4 since it is
constrained to a
RPL routing domain. The current RPL specification requires all RPL
routers
to implement the source routing mechanism we are trying to specify.
Thi
>-Original Message-
>From: Vishwas Manral [mailto:vishwas.i...@gmail.com]
>Sent: Monday, May 31, 2010 3:07 PM
>To: Hemant Singh (shemant)
>Cc: Erik Nordmark; ipv6@ietf.org; culler Culler
>Subject: Re: Fwd: I-D Action:draft-hui-6man-rpl-routing-header-00.txt
>Hi Hemant,
>When we do IP in
Hi Hemant,
When we do IP in IP tunneling, in that case too the packet size
increases at an intermediate node. It is no different than this case.
Thanks,
Vishwas
On Mon, May 31, 2010 at 12:03 PM, Hemant Singh (shemant)
wrote:
> Vishwas,
>
> It's not a question of what's optional or not. Erik ga
Hi Jonathan,
>> RFC2460 said:
>>
>> If, while processing a received packet, a node encounters a Routing
>> header with an unrecognized Routing Type value, the required
>> behavior of the node depends on the value of the Segments Left field,
>> as follows:
>>
>> - If Segments Left is non-zer
Vishwas,
It's not a question of what's optional or not. Erik gave a clear
example of an operational issue which is if a host sends a packet with
size equal to MTU of the link and if such a packet arrives at a router1
in such a network and router1 slaps its RH on the packet, the packet
size grows
Hi Vishwas,
On May 31, 2010, at 11:14 AM, Vishwas Manral wrote:
RFC2460 said:
If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required
behavior of the node depends on the value of the Segments Left field,
as follows:
Hi JP,
Besides the issues I have raised. Here is another thing I encountered
when I wrote the RH4 draft.
RFC2460 said:
If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required
behavior of the node depends on the value
Hi Erik,
The first thing is IPv6 MTU discovery is optional and the only
requirement is that the Minimum MTU is satisfied.
Also in cases like LLN the Routing paths may change so even after
discovery the Packet too big may come anyway. Besides PMTU issues you
mention are no different than a lot of
Since we route WITHIN a RPL network, rather than THROUGH a RPL
network, it would seem that the case mentioned does not arise. Right?
On May 30, 2010, at 7:56 AM, Erik Nordmark wrote:
The draft says:
A RPL Router MAY insert a Type 4 Routing header if one does not
already exist. The co
Hi Jonathan,
I just re-read the draft I had written about 3 years ago and tried to
figure out things we could further add to your draft.
Do you have any diameter in the RPL network? If so there are 2 questions:
1. Is 255 a good enough value? With your draft we can allow only a
maximum of 255 int
Hi Jonathan,
Thanks for pointing me to the other drafts.
Good to see you are heading the path that I once tried to. I have
added similar checks like Multicast and others to the headers.
Here are a few comments:
1. There is no check for any address appearing more than once. You can
use the algor
>-Original Message-
>From: Jonathan Hui [mailto:j...@archrock.com]
>Sent: Monday, May 31, 2010 12:38 AM
>To: Hemant Singh (shemant)
>Cc: Philip Levis; JP Vasseur; ipv6@ietf.org
>Subject: Re: New Version Notification for
draft-hui-6man-rpl-option-00.txt
>Hemant,
>Being able to change the
Dear co-chairs,
We would like to request two short slots for the next IETG meeting.
1) Topic
- Draft name: draft-hui-6man-rpl-routing-header
- Presenter: Jonathan Hui/ JP Vasseur
- Requested amount of presentation time: 10mn
2) Topic
- Draft name: draft-hui-6man-rpl-option
16 matches
Mail list logo
