Hi Samita, On Nov 28, 2012, at 5:34 AM, Samita Chakrabarti wrote:
> Hi Jouni, > > Please the response in-line. > > -----Original Message----- > From: jouni korhonen [mailto:jouni.nos...@gmail.com] > Sent: Thursday, November 22, 2012 6:54 AM > To: Samita Chakrabarti > Cc: 6man Mailing List; Bob Hinden; Ole Trøan; Erik Nordmark > Subject: Re: Updated Efficient-nd posted > > Hi, > > I had a quick glance over the I-D. Since you are referring to LTE networks (I > assume this is the indirect assumption for cellular networks in the I-D). > > ==> Yes. It should just say 3GPP Cellular Networks. Looking at TS 23.060 and > TS 123.401 I see that the former allows periodic RA. Though TS 123.401 stays > silent about periodic RA, and it talks about RS->RA sequence and DAD not > being required for SLAAC. However, it is unclear if the RA is unicast or > multicast and does not prevent one implementation to send periodic RA. If these procedures are unclear, you should read RFC6459 and draft-ietf-v6ops-rfc3316bis. Anyway, 3GPP system sends periodic unsolicited RAs and state-3 also says to do so. Typically the router lifetimes are just set long, measured in hours. Whether the RA is multicast or unicast does not matter. The underlying 3GPP point-to-point link does not support userplane multicast anyway and each node will receive their (unicast) copy of the RA. Each link acts independently. > I wonder what kind of real & specific benefits you envision over, say the LTE > link? Those cellular links are already rather quiescent when it comes to ND > traffic. To me what to I-D proposes introduces more ND traffic than there is > today. Or am I missing something fundamental here? > > ===> The real benefit is that the SDO can directly refer to this IETF > document ( if published as a RFC) which clearly states the behavior of UE and > Address-assignment router/server. This will prevent multiple interpretation > of the SLAAC behavior ( multicast messages, periodic RA) from the 3GPP > documents. See RFC6459 and draft-ietf-v6ops-rfc3316bis. There are not really interpretation issues that this specification would make any clearer as far as I see it now. > Since 3GPP GGSN or PDN-GW already acting as a default router, the node > registration will be useful information to the Also SGW can be a default router in some cases. > operator for UE management. Today, in many cases, DHCP is used or some other > SDO specific registration is done to I really fail to see how it would be useful. Each UE will have their unique /64, the system does not really care about the IID. > provide the SLAAC service; this document will provide uniformity across > handsets/technologies. For example, a handset switching from Cellular to > wireless or vice-versa can maintain the same optimized behavior of address > assignment procedure. There could be something on the handover part that I have not digested yet. At least the scenario is not really described in Section 17. > The I-D does not add more ND traffic at all. The registration procedure is an > optional feature and it is also embedded in NUD like message and one can set > a long lifetime to avoid frequent registration. Ok. Thanks for pointing the optionality. Missed that. If the registration is optional, then what is the benefit? My point is that trying to optimize ND over 3GPP link any further is likely a wasted effort. As of today, there is no DAD or address resolution, router does not do NUD for global addresses and periodic RAs are seldom. Also, the optimization in the I-D seems to depend on an unique ID (EUI-64 or equivalent). That does not hold in 3GPP system, since such are not mandated from 3GPP UEs. There is also MUST for SLLA when ARO is used, however, 3GPP links do not have link-layer addressing. > Thanks for your input. Thanks. I am just trying to get my head around this. Current statements for usability in cellular just seem superficial at the moment. For example, currently I cannot agree Section 16.4. (when it comes to cellular). - Jouni > -Samita > > > > On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: > >> Hello All: >> >> As a follow-up from the IETF85 6man meeting presentation on >> Efficient-nd draft, we have posted a new version of the document which >> incorporated comments from Carsten Bormann in the list on editorial changes >> and some more clarification and editorial changes based on individual >> comments. >> >> More comments are welcome in improving the document. >> >> Regards, >> -Samita >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
