RE: [16NG] ipv6 over ipv6cs document approval

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

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. 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]>:

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]> 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] >:
> > >
> > > > 
> > > >
> > > > 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]>
> 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]>:
> > > >
> > > >
> > > >
> > > > 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]
> > > > https://www1.ietf.org/mailman/listinfo/16ng  <
> > > 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
> > >
> > >
> >
>
>

 

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