RE: [16NG] ipv6 over ipv6cs document approval

["John.zhao" <[e-mail]>]

Hi,Alex
	Thanks for comments.See my reply inline.
	Best Rgds,
Thanks,
John.zhao

> -----邮件原件-----
> 发件人: Alexandru Petrescu [mailto:[e-mail]]
> 主题: Re: [16NG] ipv6 over ipv6cs document approval
> Just some thoughts on these issues...
> 
> John.zhao wrote:
> > Hi,all
> >
> >          I have ever stated this problem in prague.  It’s Very glad to
> > see it is discussed again. The periodic RA will force those idled MS out
> > from sleep/idle state.
> 
> I think we'd need to get in more detail about the levels of sleep and
> idle.  I think many handheld devices have more than just two states
> (normal vs standby).  For example a handheld device could run at its
> fullest but have the screen and the wifi interface turned off.  Is this
> 'sleep'?  Other devices have various clocking strategies, based on the
> application being run: if this application is run then this clock speed
> should be used.
> 
> Other devices have two processors each with its own powering
> architecture.  RA will probably wake up only one.
> 
> So... what do we mean by "idle/sleep" state?
> 
> It may be that the periodic RA will not provoke more battery consumption
> than the other periodic link-layer messages.
> 
> Is battery the worry.
> 
> (I'm not saying at all that this is not a problem.)
> 
> Alex
> 
[John.zhao] I understand. Just as you have said that to a MN, there are
difference action or status around sleep/idle what we have said. But I think
what we has discussed is mainly about the definition in IEEE802.16 about
sleep/idle state and mode. 
	Just for reference.
	As to the detail state of MN behavior. That will be decided by
vendor it self I think.
	Best Rgds,
Thank,

John.zhao
> 
> > So to those cases, we didn’t need the unsolicited
> > NAs come from ARs. But I think only in this case.
> >
> >          Back to this draft, I suggest we have three choice:
> >
> > 1)       Didn’t take care of this, and exclude it out side of this
draft.
> >
> > 2)       Specify this requirement , for example:
> >
> > a)         Those SS/MS in sleep/idle state shouldn’t  receive those
> > periodic RA aimed to them.
> >
> > And leave the details to others , such as wimax nwg , to handle it.
> >
> > 3)       Specify a detail implementation in this detail. Maybe … wait
> > for the input from this wg.
> >
> >
> >
> > My two cents.
> >
> > Best Rgds,
> >
> > Thanks,
> >
> > John.zhao
> >
> > 2007-11-24
> >
> > ------------------------------------------------------------------------
> >
> > *发件人:* Junghoon Jee [mailto:[e-mail]]
> > *发送时间:* 2007年11月24日 12:45
> > *收件人:* Syam Madanapalli
> > *抄送:* [e-mail]
> > *主题:* Re: [16NG] ipv6 over ipv6cs document approval
> > *重要性:* 高
> >
> >
> >
> > Yes, the major problem comes from the periodic RA.
> >
> >
> >
> > I was thinking about the case when AR sends neighbor discovery
> > packets to the SS which is in the sleep/idle state.
> >
> > The AR's sending the unsolicited NAs to SS can be a case for that which
> > is described in the section 7.2.6 of RFC 4861.
> >
> >
> >
> > Maybe we need not allow that optional behavior in the case of IPv6CS?
> >
> > Junghoon
> >
> >
> >
> > 2007/11/23, Syam Madanapalli <[e-mail]
> > <mailto:[e-mail]>>:
> >
> >     Hi Junghoon,
> >
> >     On the IPv6 CS link, there will be two nodes: MS and AR.
> >     ND packets from one MS will never reach other MS.
> >     Problem may arise from periodic RAs, which may require
> >     increasing the periodic RA interval.
> >
> >     Thanks,
> >     Syam
> >
> >
> >
> >     On Nov 23, 2007 5:35 PM, Junghoon Jee <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >     >  Hi Syam,
> >     >
> >     >  Then, what can we do not to wake up the idle/sleep SSs?
> >     >
> >     >  Junghoon
> >     >
> >     >
> >     >  2007/11/23, Syam Madanapalli < [e-mail]
> >     <mailto:[e-mail]>>:
> >     >
> >     >  > ND just runs normally on IPv6CS, similar to any p2p link.
> >     >  >
> >     >  > -Syam
> >     >  >
> >     >  > On Nov 23, 2007 3:25 PM, Junghoon Jee < [e-mail]
> >     <mailto:[e-mail]>> wrote:
> >     >  > > Hi Raj,
> >     >  > >
> >     >  > > >One of the reasons for choosing a PtP link model is to avoid
> >     the issues
> >     >  > > related to ND.
> >     >  > >
> >     >  > > Multilink subnet issues are the main reason of that.
> >     >  > >
> >     >  > > >Because of the PtP link type there is no question about an
MS
> >     being
> >     >  > > transitioned out of Idle mode because of ND.
> >     >  > >
> >     >  > > So, we should not send neighbor discovery packets in case of
> >     the IPv6CS?
> >     >  > >
> >     >  > > >The document does not need to specify anything further
> >     regarding ND.
> >     >  > >
> >     >  > > Junghoon
> >     >  > >
> >     >  > > 2007/11/23, Basavaraj Patil <[e-mail]
> >     <mailto:[e-mail]> >:
> >     >  > >
> >     >  > > >
> >     >  > > >
> >     >  > > > One of the reasons for choosing a PtP link model is to
avoid
> the
> >     >  issues
> >     >  > > related to ND.
> >     >  > > > Because of the PtP link type there is no question about an
> >     MS being
> >     >  > > transitioned out of Idle mode because of ND.
> >     >  > > > The document does not need to specify anything further
> >     regarding ND.
> >     >  > > >
> >     >  > > > -Raj
> >     >  > > >
> >     >  > > >
> >     >  > > >
> >     >  > > > On 11/22/07 3:01 AM, "ext Junghoon Jee" <
> >     [e-mail] <mailto:[e-mail]>>
> >     >  wrote:
> >     >  > > >
> >     >  > > >
> >     >  > > >
> >     >  > > > Hi Jari,
> >     >  > > >
> >     >  > > > I agree to apply the suggested changes.
> >     >  > > >
> >     >  > > > Let me share my unsolved question regarding how to deal
with
> >     neighbor
> >     >  > > discovery packets for IPv6CS case.
> >     >  > > >
> >     >  > > > Do we have to block neighbor discovery packets not to wake
up
> >     >  idle/sleep
> >     >  > > SSs ? Or,
> >     >  > > > Do we have to let them delivered in that p2p link not to
> >     break the NUD
> >     >  > > model?
> >     >  > > > Is there no need to specify about that in this document?
> >     >  > > >
> >     >  > > > BR,
> >     >  > > > Junghoon
> >     >  > > >
> >     >  > > >
> >     >  > > > 2007/11/22, Jari Arkko <[e-mail]
> >     <mailto:[e-mail]>>:
> >     >  > > >
> >     >  > > >
> >     >  > > >
> >     >  > > > We're trying to close the remaining issues and approve
> >     >  > > > the current document.
> >     >  > > >
> >     >  > > > The current proposal is what we have in the draft, with
> >     >  > > > the following changes. If there is any concern with
> >     >  > > > these changes, let me know as soon as possible.
> >     >  > > >
> >     >  > > > There are a few editorial changes. The substantive
> >     >  > > > changes are clarifying MTU rules in the presence
> >     >  > > > of tunneling on the BS side, and strengthening
> >     >  > > > the requirements related to interoperability.
> >     >  > > >
> >     >  > > > ----
> >     >  > > >
> >     >  > > > Please change in Section 8.1:
> >     >  > > >
> >     >  > > > OLD:
> >     >  > > >    The use of router advertisements as a means for movement
> >     detection
> >     >  is
> >     >  > > >    not recommended for MNs connected via 802.16 links as
the
> >     frequency
> >     >  > > >    of periodic router advertisements can be high.
> >     >  > > > NEW:
> >     >  > > >    The use of router advertisements as a means for movement
> >     detection
> >     >  is
> >     >  > > >    not recommended for MNs connected via 802.16 links as
the
> >     frequency
> >     >  > > >    of periodic router advertisements would have to be high.
> >     >  > > >
> >     >  > > > Please add new text at the end of Section 4 (just before 4.
1),
> >     >  > > > these are the new paragraphs:
> >     >  > > >
> >     >  > > >    In any case, the MS and BS MUST negotiate at most one
> >     >  > > >    convergence sublayer for IPv6 transport on a given link.
> >     >  > > >
> >     >  > > >    In addition, to ensure interoperability between devices
that
> >     >  > > >    support different encapsulations, it is REQUIRED that BS
> >     >  > > >    implementations support all standards track
encapsulations
> >     >  > > >    defined for 802.16 by the IETF. At the time of writing
this
> >     >  > > >    specification, this is the only encapsulation, but
> additional
> >     >  > > >    specifications are being worked on. It is, however, not
> >     >  > > >    required that the BS implementations use all the
> >     encapsulations
> >     >  > > >    they support; some modes of operation may be off by
> >     >  > > >    configuration.
> >     >  > > >
> >     >  > > > Change in Appendix D:
> >     >  > > >
> >     >  > > > OLD:
> >     >  > > >    It is
> >     >  > > >    recommended that the default MTU for IPv6 be set to 1400
> >     octets for
> >     >  > > >    the MS in WiMAX networks.
> >     >  > > > NEW:
> >     >  > > >    It is recommended that the MTU for IPv6 be set to 1400
> >     octets in
> >     >  > > >    WiMAX networks, and this value (different from the
default)
> >     >  > > >    be communicated to the MS.
> >     >  > > >
> >     >  > > > Change Section 6.3 to:
> >     >  > > >
> >     >  > > >   The MTU value for IPv6 packets on an 802.16 link is
> >     configurable.
> >     >  > > >   The default MTU for IPv6 packets over an 802.16 link
> >     SHOULD be 1500
> >     >  > > >   octets.
> >     >  > > >
> >     >  > > >   The 802.16 MAC PDU (Protocol Data Unit) is composed of a
6
> >     byte
> >     >  > > >   header followed by an optional payload and an optional
CRC
> >     covering
> >     >  > > >   the header and the payload.  The length of the PDU is
> >     indicated by
> >     >  > > >   the Len parameter in the Generic MAC Header.  The Len
> >     parameter has
> >     >  a
> >     >  > > >   size of 11 bits.  Hence the total MAC PDU size is 2048
> >     bytes.  The
> >     >  > > >   IPv6 payload size can vary.  In certain deployment
> >     scenarios the MTU
> >     >  > > >   value can be greater than the default.  Neighbor
Discovery
> >     for IPv6
> >     >  > > >   [RFC4861] defines an MTU option that an AR MUST
advertise,
> via
> >     >  router
> >     >  > > >   advertisement (RA) if a value different from 1500 is
used.
> >     >  > > >   If an AR advertises an
> >     >  > > >   MTU via the RA MTU option, the MN SHOULD use the MTU from
> >     the RA.
> >     >  > > >   Nodes that implement Path MTU discovery [RFC1981] MAY use
the
> >     >  > > >   mechanism to determine the MTU for the IPv6 packets.
> >     >  > > >
> >     >  > > > In the abstract:
> >     >  > > >    s/fxed/fixed/
> >     >  > > >
> >     >  > > > In section 6.1:
> >     >  > > >    s/it is recommended that a tunnel is established/it is
> >     recommended
> >     >  > > >    that a tunnel be established/
> >     >  > > >
> >     >  > > >
> >     >  > > >
> >     >  > > > _______________________________________________
> >     >  > > > 16NG mailing list
> >     >  > > > [e-mail] <mailto:[e-mail]>
> >     >  > > > https://www1.ietf.org/mailman/listinfo/16ng  <
> >     >  > > https://www1.ietf.org/mailman/listinfo/16ng >
> >     >  > > >
> >     >  > > >
> >     >  > > > ________________________________
> >     >  > > _______________________________________________
> >     >  > > > 16NG mailing list
> >     >  > > > [e-mail] <mailto:[e-mail]>
> >     >  > > > https://www1.ietf.org/mailman/listinfo/16ng
> >     <https://www1.ietf.org/mailman/listinfo/16ng>
> >     >  > > >
> >     >  > > >
> >     >  > >
> >     >  > >
> >     >  > > _______________________________________________
> >     >  > > 16NG mailing list
> >     >  > > [e-mail] <mailto:[e-mail]>
> >     >  > > https://www1.ietf.org/mailman/listinfo/16ng
> >     >  > >
> >     >  > >
> >     >  >
> >     >
> >     >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 16NG mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/16ng





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