Subject: [Pana] Network selection section, 5.10

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Sep 2006 11:37:54 +0200

I have read this paragraph again and again, and I still have a hard time 
making sense of it:
>    A PANA-Start-Request message sent from the PAA MAY contain zero or
>    one NAP-Information AVP, and zero or more ISP-Information AVPs.  The
>    PaC MAY indicate its choice of ISP by including an ISP-Information
>    AVP in the PANA-Start-Answer message.  The PaC MAY convey its ISP
>    even when there is no ISP-Information AVP contained in the PANA-
>    Start-Request message.  The PaC can do that when it is pre-configured
>    with ISP information.

I read this as saying that the PaC may send ISP selection information, 
or it may not, it doesn't really matter. This is really terrible 
guidance for an implementor, I wouldn't have a clue what to do with this 
if I were trying to write a PANA implementation.

MAY "convey" doesn't mean anything to an implementor. Normative language 
should be used when you are talking about protocol constructs, not 
abstract actions.

The next paragraph helps a little in trying to understand what "convey" 
means. I think it means that if the ISP information AVP doesn't exist, 
EAP can do the network selection within a method:

>    In the absence of an ISP explicitly selected and conveyed by the PaC,
>    ISP selection is typically performed based on the client identifier
>    (e.g., using the realm portion of an NAI carried in EAP method).  A
>    backend AAA protocol (e.g., RADIUS) will run between the AAA client
>    on the PAA and a AAA server in the selected ISP domain.
>   
Which suggests that EAP can do the network selection, but gets into 
specifics that are probably better left outside of this document.

Finally, this same section refers to RFC 4284 in its final paragraph, 
which seems to be yet another way to do network selection inside EAP 
(or, is this the same as referred to in the above paragraph?).

This section presents far too many ways to do the same thing, and 
without enough detail for an implementor to know what to do. This 
section either needs work to define the *PANA* way to do this (with 
normative language, preferably MUSTs or SHOULDs, referring to protocol 
constructs specific to PANA),  in the absence of an EAP method that does 
network selection. Or, network selection should be simply removed - it 
seems EAP does this anyway, so you could perhaps avoid this problem 
altogether by just letting EAP handle it (again, "Less is More").

- Mark

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 28 Sep 2006 23:30:49 -0400

> if I were trying to write a PANA implementation.

The meaning of the paragraph in terms of ISP selection is:

- The PaC may choose an ISP based on the information provided by PAA (using 
one or more ISP-Information AVPs in PSR) or pre-configured on the PaC.

- When the PaC chooses an ISP, then the choice is made based on
carrying one ISP-Information AVP in PSA.

> should be used when you are talking about protocol constructs, not 

I agree.  How about revising the last two sentences of the paragraph 
something like:

When the PaC is pre-configured with ISP information, it may choose an
ISP even when there is no ISP-Information AVP contained in the
PANA-Start-Request message.  In this case, the choice is communicated
to the PAA by containing an ISP-Information AVP in the
PANA-Start-Answer message.

> specifics that are probably better left outside of this document.

I think we can remove the above paragraph on NAI-based network
selection.

> altogether by just letting EAP handle it (again, "Less is More").

The functionality provided by PANA and provided by RFC 4284 is
different.  RFC 4284 does not allow an EAP peer to choose an ISP using
a single NAI such as [email-masked].  Also RFC 4284 has a limitation
in number of ISPs contained in EAP message due to EAP MTU.  I am
wondering if we can remove refernece to RFC 4284 from the PANA
specification.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 29 Sep 2006 12:31:40 +0300

> > if I were trying to write a PANA implementation.

Use of this feature is optional. That's the intent. So, the implementer
should implement this feature (AVP processing), and also implement a
configuration know to enable/disable its use. If we insert a text like
"Network discovery and selection is a feature that is optionally used."

> wondering if we can remove refernece to RFC 4284 from the PANA

To contrast PANA, RFC 4284, and NAI-based solutions, I think we should use
the term "network discovery and selection".

Network discovery is how the PaC learns the identifiers of the available
ISPs/NAP to connect to.

ISP/NAP-info AVPs in PANA-Start-Request achieves that.
RFC 4284 achieves that.

The latter was designed by/for 3GPP (see IESG note) in the absence of any
"discovery" support by EAP lower layers, which is considered the right layer
to achieve this functionality.  Hence, we provide that functionality in
PANA.

Network selection is how PaC tells the NAS its network selection (ISP to
connect to).

ISP-info AVP in PANA-Start-Answer achieves that.
Looking at realm of NAI can achieve that.

The latter has a limitation as it takes away the flexibility to connect to
an ISP other than the one indicated in the realm of the NAI.

Maybe, what we should do is, first describe the PANA solution in this
section, and at the end talk about the existing workarounds.

	In the absence of such network discovery support from existing EAP 
	lower layers, RFC 4284 defined a workaround by advertising ISP 
	information in-band with the ongoing EAP method execution. A similar

	workaround has been relying on the realm portion of NAIs as a
network 
	selection tool. It's a deployment decision which one of these 
	mechanisms is used in a PANA deployment. 

Does this make sense? 

Alper