[16NG] Re: Review of the ipv6-over-ipv6cs draft

[Basavaraj Patil <[e-mail]>]

Hi Pekka,

Reponses inline:

On 2/1/07 12:47 AM, "ext Pekka Savola" <[e-mail]> wrote:

> Some responses inline,
> 
> On Wed, 31 Jan 2007, Basavaraj Patil wrote:
>>> The design implications of raising RA intervals (intead of, say, filtering
>>> extra RAs out) may not be fully understood.  How are other protocols (e.g.,
>>> periodic MLD reports, Neighbor Solicitations due to port scanning or
>>> pinging
>>> the all nodes multicast address, etc.) handled?
>> 
>> Filtering extra RAs is not an option. The MS expects an RA at
>> MaxAdvIntervals and filtering them would disrupt MS behavior.
> 
> Which implementations expect this?  Is this behaviour related to
> DNA? 

DNA for example. For DNA, a host relies on prefixes which were received
within 3 * Maximum of MaxRtrAdvInterval.
Well, the problem also is the fact if the MaxRtrAdvInterval as per RFC2461
is fairly small, the AR will send the periodic RAs and this would
cause the MS being paged causing it to transition from Idle
mode. Discussion on increasing the value of this parameter in the bis
version of RFC2461 (during IETF LC) concluded that the value can be
specified  depending on the link or in specific IPv6 over foo
documents. 

> At least I have not seen this kind of dependency but I have a very
> limited view of fixed hosts only.  Host implementations that I'm aware
> of just look at the lifetimes of PIO options (can be long) for address
> lifetimes and AdvDefaultLifetime (max 9000sec) for default route
> lifetime.

But the Max value of MaxRtrAdvInterval as per RFC2461 is 1800
secs. And this is not long enough. Hence the reason to increase the
value of this parameter.

> 
> Even if a default route would be lost while in suspend, I don't see
> this as an issue as immediately when the host gets woken up, the
> default route could be re-obtained by a) specific RA (if wake up call
> was sent by the AR -- at the same time or 20ms later) or b) a RS (if
> host decided to wake up).  Later you also said that when a host gets
> paged it needs to establish the link, implying that in fact there is
> some delay before link can be used after paging.

Well... If the AR is configured to send periodic RAs at regular
intervals (MaxRtrAdvInterval), the AR would end up paging the host and
waking it up to deliver an RA which is essentially not very useful
to the host. In fact we had an I-D
(draft-madanapalli-ipv6-periodic-rtr-advts-00.txt)  proposing that it
should be possible to not send RAs at all on certain links. But
because of backward compatibility issues this has not
progressed. Since a host can always send a Rtr solicitation whenever
it needs to, why send periodic RAs at all? If movement detection is
not based on RAs as an example..
The delay in establishing the link after the MS is paged is fairly
small and there is buffering capability in the network to manage the
delay. 

> 
>> The MS and AR are connected via a PtP link which is created via a
>> combination of the transport connection over the air interface and a
>> corresponding GRE tunnel between the BS and AR. Are there specific
>> issues w.r.t MLD reports etc. on a PtP link that you believe need to
>> be clarified?
> 
> I don't see PtP specific issues, except that MLD specifications expect
> that hosts send periodic MLD reports about the groups they have joined
> (including the solicited-node link local addresses).  Similarly,
> router is required to send MLD queries periodically on the link to
> check the multicast group memberships.  How are you going to deal with
> this scenario?  Will it require a protocol modification as well?

No. The draft only increases the Max value of MaxRtrAdvInterval. It doesn't
change any standard w.r.t. periodic MLD report.

> 
> Are there other protocols similar to ND and MLD which require
> periodical messaging that may be relevant in this scenario (I can't
> recall from the top of my head, but I'd suspect there may be, whether
> standardized or proprietary)?
> 

Cant think of any.

>>> ==> However, if the MS is a router, RA is basically ignored in this kind of
>>> context.  Hence, this approach of non-default MTU configuration seems
>>> applicable between host and a router only.
>> 
>> Okay... Do you have any suggestion or text that would help in this
>> context?
> 
> I'm not sure which specific text would be most helpful here, but you
> should probably point out that the proposed approach is only
> applicable in host-router scenarios so you can't depend on it for all
> cases.  In other scenarios, other mechanisms (unfortunately, the only
> option I can think of is manual configuration at both ends) needs to
> be used.

Okay. I can add some text to this effect.

> 
>>> How do you deal with periodic MLD reports, for
>>> example?
>> 
>> So what would break if periodic MLD reports are not sent.
> 
> If there is MLD snooping (to restrict multicast flooding) along the
> path, it will break.  I'm not sure how applicable this is in this
> context; if each MS (from the perspective of AR) has a separate link
> so that 10 multicast recipients of the same group would require 10 GRE
> tunneled packets (no optimization), this is maybe not an issue except
> for expandability.

Yes. Because of the p2p link model, it won't break even in presence
of MLD snooping.

> 
> I think this is more of a procedural issue, i.e., what steps are
> required to standardize a mechanism that breaks existing standardized
> mechanisms?  Do all the existing mechanisms need to be changed (first)
> or something else?  Should this approach be reviewed by the people who
> standardized the old mechanisms?
> 
>>> How do you prevent frequent port scanning from waking up the host
>>> every 5 minutes when the router wants to do Neighbor Solicititation for the
>>> address?
>> 
>> It does not make sense to do wake up the host every 5 mins. Is there a
>> reason for the AR to do NS periodically?
> 
> No -- unless AR has packets to send to the MS.

The AR does not do NS at all in the case of 802.16 because 802.16
doesn't use MAC address for traffic forwarding.
The AR simply sends the packet destined to the MS to its virtual
interface and if the MS is in idle mode, it is paged. If not the
packet is delivered.


> 
>>> 3) The text above seems technically incorrect.  The key point here is what
>>> is the MTU on the wired link between BS and AR.  If it supports MTUs higher
>>> than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
>>> could
>>> possibly still be used.
>> 
>> True... But the fact is that for WiMAX, the profile specifies a MAX
>> SDU of 1522 octets. So the packets on the air-interface cannot be
>> greater than 1522 bytes. So the existence of links with higher MTU
>> capability on the link between the BS<->AR does not matter.
> 
> We may be talking past each other, because I don't see what
> air-interface has to do with this (I'm assuming that the interface
> between AR and BS is _not_ air-interface but I may be wrong).  A
> 1500-byte packet on AR-BS interface could be encapsulated in GRE
> (resulting in ~1550 byte packet or something like that) between AR and
> BS.  If AR-BS interface supports MTU higher than about 1550, this
> should be no problem.

Ahh... The BS<->AR link is what you were refering to..
I agree... But in general MTU size of 1500 on links is assumed or
expected. And hence the recommendation.

-Raj



_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng