re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs

Hello folks,
       Sorry for the following code, because my outlook is Chinese version,
please see inline straight.
Thanks
Alice

> 发件人: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> 发送时间: 2007年3月15日 19:15
> 收件人: Basavaraj Patil
> 抄送: ext Alexandru Petrescu; ipv6@ietf.org; ietf@ietf.org; IETF-Announce;
> 16ng@ietf.org
> 主题: Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs
> 
> Basavaraj Patil wrote:
> > Alex,
> >
> >
> > On 3/14/07 11:47 AM, "ext Alexandru Petrescu" <alexandru.petrescu@gmail.
com>
> > wrote:
> >
> >> Basavaraj Patil wrote:
> >>> Hello,
> >>>
> >>> A slightly revised version of the I-D is now available at:
> >>>
> http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
> >>>
> >>> This revision incorporates changes based on some of the comments made
by
> the
> >>> directorate. It will be submitted to the ID repository as soon as the
gates
> >>> are opened.
> >> Raj, is there a plan to deal with the interoperability issue where the
> >> AP tells the Station to auto-configure statelessly and the AR tells it
> >> statefully?
> >>
> >> The AP may send REG-RSP telling the Station to use DHCP.
> >>
> >> The AR may send an RA telling the Station to use SLAAC.
> >
> > The issue arises when we consider managed and unmanaged hosts as defined
by
> > 802.16. Managed hosts are the ones that may use the secondary management
> > connection. Secondary management connection is optional and as we have
> > discussed in the past this is an option in the .16 specs that exists but
> > very likely unused. I can tell you that in the case of Mobile WiMAX the
> > secondary management connection is not used.
> 
> Ok.  I'm wondering whether IEEE can mention to Mobile WiMax that the
> secondary management connection seems mandatory.  Sure that's not IETF
> matter, but IETF does IPv6, and for IEEE IPv6 config happens only on the
> SMC (secondary management connection)... complicated.
> 
[qinxia] SMC is used for network management in 16d, we may ignore it in 16e,
RA could be transported over general connection. 

> > I agree that a BS and the AR should be synchronized in terms of what
method
> > is indicated to the MS for address configuration.
> >
> >> There may be an interoperability issue, if the two indicators are
different.
> >
> > Yes.
> >
> >> This issue can of course be considered as a network management issue,
> >> where advice could be given to network deployers of AR and AP to
> >> configure their networks correctly.
> >
> > Correct. A deployment should be able to ensure that the indication to
the
> MS
> > in the REG-RSP and RA are synchronized. I can add some text in the I-D
to
> > ensure that this issue is noted in the address configuration section.
> 
> Right, this is what I meant.  I think it's a good way forward for the
> IPv6-CS draft until Mobile WiMax and IEEE figure out.
> 
[qinxia]  It is odd to indicate address configuration via REG-RSP such Layer
2 signaling, IMHO, I do not think that there is any requirement to adopt
other method to inform address configuration. RA is enough.

> >> And this is a time when both 802.16 is changing (Corrigendum 2 under
> >> discussion but still allows AP to indicate to MN what autoconf method
to
> >> use) and the RA definition is changing (draft-2462bis indicates 'M'
flag
> >> may not be used, but an 'autonomous' flag instead).
> >>
> >> What do you think?  Do I get this issue correctly?  Or is the issue
> >> important, less important, etc.
> >
> > This is a valid issue but I think it can be clarified in the I-D itself
by
> > recognizing it and recommending that the indication by the BS and AR are
> > synced. We can also mention it to IEEE but that is about the scope of
things
> > that we can do.
> 
> I agree.  I have a list of such issues that could be mentioned to IEEE.
>   I'm not talking put requirements to IEEE, just mention the potential
> issues.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng