Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Apr 2013 13:32:56 +0000

Hi all:

The authors have requested a call for adoption by the WG for draft-bhandari-dhc-access-network-identifier-04.

This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on May 2nd, 2013.

Note that the 04 draft was just published and has redesigned options to better follow the option guidelines.

The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04.

Regards,

Tomek & Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 14:59:41 +0000

When we talked about this earlier, I said that it might be better to have this work done in DHC rather than forcing it to find a new working group because it seemed to be something that was being asked for by other SDOs.   However, the authors never said anything about that over and above what they've already said in meetings, so I don't actually have a clear picture of who is asking for this.   Looking in the data tracker, I don't find any liaison statement requesting that this work be done.

The authors have expressed a great deal of urgency about this work, and I don't want to delay it any further, so I will state that as a participant, I'm in favor of the working group taking on the work.   However, with my AD hat on, I would like to get some kind of actual request for help from the SDOs who want this functionality before the end of the call for adoption.   Otherwise I think Bernie's concern that the DHC working group really isn't qualified to evaluate the validity of the option contents will remain unaddressed, and I think it's a valid concern.

The request from the SDOs should be of the form "we need DHCP options to deliver the following bits of functionality," and should briefly describe the functionality that's needed, and refer to the documents that the SDO is working on that support this need.

If this need is not really coming from these SDOs, but rather from some IETF working group, then perhaps Bernie's original observation was correct, and this work should be done in that working group instead.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 17 Apr 2013 15:47:29 +0000

Hi Ted,

Thanks for your comments.

This requirement is not coming from any SDO. We believe this is a generic
requirement for IETF based IP architectures.

As you are aware, many operators are deploying large scale SP WiFI
networks. These deployments are based on standard IETF protocols and
architectures (tunneling, mobility, Routing, AAA protocols ...). In many
of these deployments the subscriber services are tied to the access
network, for example, the initial portal page may be different based on
the user location (SSID, AP Mac address ..). These parameters are
typically carried on DHCP option-82, and are coded in a vendor basis.
There is no standard encoding that a backend system can reliably depend on
for learning these parameters. In the past when WiFI was largely contained
to enterprises, with single vendor solutions, this worked fine. But, now
in many deployments there are multi-vendor systems and interop is
required. The draft is trying to attempt to fix that gap. We want to drive
this work in DHC, not using a liaison statement, but as a gap in IETF
protocols, to solve a practical deployment issue and improve
interoperability.

I'm copying Hui Deng, CMCC. They are deploying large scale SP WIFI
networks and he can comment on this.

Regards
Sri

On 4/17/13 7:59 AM, "Ted Lemon" <[email-masked]> wrote:

>When we talked about this earlier, I said that it might be better to have
>this work done in DHC rather than forcing it to find a new working group
>because it seemed to be something that was being asked for by other SDOs.
>  However, the authors never said anything about that over and above what
>they've already said in meetings, so I don't actually have a clear
>picture of who is asking for this.   Looking in the data tracker, I don't
>find any liaison statement requesting that this work be done.
>
>The authors have expressed a great deal of urgency about this work, and I
>don't want to delay it any further, so I will state that as a
>participant, I'm in favor of the working group taking on the work.
>However, with my AD hat on, I would like to get some kind of actual
>request for help from the SDOs who want this functionality before the end
>of the call for adoption.   Otherwise I think Bernie's concern that the
>DHC working group really isn't qualified to evaluate the validity of the
>option contents will remain unaddressed, and I think it's a valid concern.
>
>The request from the SDOs should be of the form "we need DHCP options to
>deliver the following bits of functionality," and should briefly describe
>the functionality that's needed, and refer to the documents that the SDO
>is working on that support this need.
>
>If this need is not really coming from these SDOs, but rather from some
>IETF working group, then perhaps Bernie's original observation was
>correct, and this work should be done in that working group instead.
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Apr 2013 16:22:42 -0500

Hi Sri,

I think that Client/Server behaviour (Section 7 & 9) in the draft needs
some clarification.

Please check Bernie's mail:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg11144.html
on draft-ietf-dhc-80211-option-01.txt.

Also please check the operation described in Li's draft:
http://tools.ietf.org/html/draft-xue-dhc-location-option-01

Regards,

Behcet
On Wed, Apr 17, 2013 at 10:47 AM, Sri Gundavelli (sgundave) <

---

From: "Florin Baboescu" <[email-masked]>
Date: Wed, 17 Apr 2013 23:05:25 +0000

Hi,

I would like to express my support for this work as it addresses a practical deployment issue.
Thank you.

-Florin Baboescu

From: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 17, 2013 6:32 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013

Hi all:

Regards,

Tomek & Bernie

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Thu, 18 Apr 2013 03:40:29 +0000

I read/reviewed this document earlier and I do support this document to get adopted as WG document.

-Gaurav

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 17, 2013 7:03 PM
To: [email-masked]
Subject: [dhcwg] WG Adoption Call - draft-bhandari-dhc-access-network-identifier-04 - Ends May 2, 2013

Hi all:

Regards,

Tomek & Bernie

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 09:16:56 +0300

On Apr 18, 2013, at 12:22 AM, Behcet Sarikaya <[email-masked]> wrote:

> Hi Sri,
> 
> I think that Client/Server behaviour (Section 7 & 9) in the draft needs some clarification.

I could agree on that. The current text is 'slightly' thin ;-)

- Jouni

> On Wed, Apr 17, 2013 at 10:47 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> Hi Ted,
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 10:06:00 +0300

Ted,

> When we talked about this earlier, I said that it might be better to have this work done in DHC rather than forcing it to find a new working group because it seemed to be something that was being a…

Echoing what Sri already said. We are not directly tasked by
other SDOs. There are activities in other SDOs that are
parallel (but not orthogonal) to this and they can use or
choose not to use the IETF solutions. Nevertheless, we need
the DHCP protocol support to complete what has already been
done e.g. in RFC6757.

> The authors have expressed a great deal of urgency about this work, and I don't want to delay it any further, so I will state that as a participant, I'm in favor of the working group taking on the…

I would say we have the required skillset in the room to
evaluate the DHCP option content validity. Actually, as 
long as it complies with RFC6757, we are mostly fine.

I find quite a bit similarities between this work and 
RFC6603. The work was done entirely in IETF and one (but
not the only) of the driving use cases was indeed deployment
in other SDO defined network architecture. RFC6603 was
later adopted as a solution by the "other" SDO once IETF
had done its work. Same could happen here but there is
no guarantees. Even in the latter case, the protocol
extension is usable in vendor products.

> If this need is not really coming from these SDOs, but rather from some IETF working group, then perhaps Bernie's original observation was correct, and this work should be done in that working grou…

Going to Netext is not, imho, desirable. There is nothing
specific to do on the PMIP6 side anymore. This is purely
about DHCP and the expertise is supposed to be in DHC WG,
right?

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Apr 2013 13:30:58 -0500

I agree that Netext is not the right place.
It could be fmc.

I can say that 3GPP will not support because they don't use DHCPv6.

BBF in the context of fmc follows 3GPP.

Maybe IEEE 802.11?

Regards,

Behcet

On Thu, Apr 18, 2013 at 2:06 AM, Jouni Korhonen <[email-masked]>wrote:

> > When we talked about this earlier, I said that it might be better to
> have this work done in DHC rather than forcing it to find a new working
> group because it seemed to be something that was being asked for by other
> SDOs.   However, the authors never said anything about that over and above
> what they've already said in meetings, so I don't actually have a clear
> > The authors have expressed a great deal of urgency about this work, and
> I don't want to delay it any further, so I will state that as a
> However, with my AD hat on, I would like to get some kind of actual request
> for help from the SDOs who want this functionality before the end of the
> call for adoption.   Otherwise I think Bernie's concern that the DHC
> working group really isn't qualified to evaluate the validity of the option
> contents will remain unaddressed, and I think it's a valid concern.
>
> the functionality that's needed, and refer to the documents that the SDO is
> working on that support this need.
> >
> IETF working group, then perhaps Bernie's original observation was correct,
> and this work should be done in that working group instead.
>

---

From: Rajat Ghai <[email-masked]>
Date: Fri, 19 Apr 2013 09:16:24 -0400

Tend to agree with Sri here ..  Not only this Access-Network-Info be used
in the Wi-Fi domain ; but in some cases be further transported to the
mobile packet core (EPC) in case the user happens to be registered user of
a mobile operator and the IP address is eventually allocated from the EPC.
Current definition of Option 82 is not enough to carry all the required
information.

Rajat Ghai
CTO
Benu Networks

-- 
Best Regards
Rajat Ghai
CTO
Benu Networks (www.benunets.com)

---

From: Rajat Ghai <[email-masked]>
Date: Fri, 19 Apr 2013 09:16:24 -0400

Rajat Ghai
CTO
Benu Networks

---

From: Hui Deng <[email-masked]>
Date: Fri, 19 Apr 2013 21:51:46 +0800

Hello all,

Historically Wifi access network architecture is not standardized in any
SDOs, WBA may need to do this, but still not yet ready. I would agree not
so many telecom opeartors are really deploying SP Wifi except for chinese
operator. Unfortunatelly that is also the reason CAPWAP which is invented
by IETF not yet really used by telecom operator today except for chinese
operator. Chinese operators have deployed more than millions of Wifi APs to
support IETF protocol.

Because APs has been deployed by SP are all using the same ESSID like CMCC,
AT&T-WIFI. This draft is useful for SP wifi when user login, SP need to
identfy which AP this user has been connected with, based on this draft
network access information could be carrier back to the gateway (Access
Controller).

Regarding to review of this draft, I would recommend the real user like SPs
could help to review this draft for the user case, for the technical part,
maybe DHC expert could help,

thanks

-Hui

2013/4/17 Sri Gundavelli (sgundave) <[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Apr 2013 10:27:43 -0500

Hi Hui,

Please see inline.

Regards,

Behcet
On Fri, Apr 19, 2013 at 8:51 AM, Hui Deng <[email-masked]> wrote:

> operator.

There is a new activity in BBF called *
Public Wi-Fi Access in Multi-service Broadband Networks

*and a document number has been assigned which is very relevant to Wi-Fi
access architecture because defining public Wi-Fi access architecture
inline with BBF access architecture is part of this activity.

 Unfortunatelly that is also the reason CAPWAP which is invented by IETF
> not yet really used by telecom operator today except for chinese
> Because APs has been deployed by SP are all using the same ESSID like
> CMCC, AT&T-WIFI. This draft is useful for SP wifi when user login, SP need
> to identfy which AP this user has been connected with, based on this draft
> Regarding to review of this draft, I would recommend the real user like
> SPs could help to review this draft for the user case, for the technical
> part, maybe DHC expert could help,
>
>

BBF in the context of new activity should also be considered.

---

From: "Prashant Jhingran (pjhingra)" <[email-masked]>
Date: Sat, 20 Apr 2013 07:23:37 +0000

I am in favor for adoption of this draft.

-
Regards,
Prashant Jhingran
NOSTG TME - SP Wi-Fi

http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/
http://wwwin.cisco.com/ios/tech/broadband

Hi all:

Regards,

Tomek & Bernie