Subject: RE: [Pana] Issue 143: CTP and PANA editorial clarification

From: Alper Yegin <[email-masked]>
Date: Fri, 03 Dec 2004 14:33:25 -0800

> >
> > So, if we want to remove the specifics from the text, let's remove
all.
> > Leaving some parts does not help, it only leaves more unanswered
> > questions behind.
> 
> The members who came up with the proposed text discussed this also as
> an alternative.  The conclusion among them was that once we remove the
> entire section, then it would be difficult to add the functionality of
> mobility optimization later, since it affects the PANA protocol
> behavior (it is not just adding some optional AVP, it also defines
> optimized PANA message sequence).  Especially from the state machine
> perspective, I think it is better to keep the framework mobility
> optimization solution in the base PANA specification.

I don't think we have to worry about that. Even if we have no mention of
an optimization in the base spec, we should be able to add new AVPs on
existing messages, update the flow, and come up with an updated state
machine accordingly. We can do this right and not break anything.

Putting a sketch of a solution without the matching details in the spec
is problematic in my opinion. First of all, it raises many questions
which are only answered in the full-solutions (now we'll have to deal
with those during reviews). Secondly, fixing a framework may
unintentionally limit the solution space down the road. 

Three options we have are:
1- Proceed with an instance of a full mobility optimization (current
text --  does not limit the solutions to that one)
2- Provide a framework but not a full solution
3- Remove mobility optimization from the spec completely, and produce a
separate document on that. 

I recommend we do either 1 or 3, but not 2.

Alper

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 06 Dec 2004 10:10:42 -0500

> I recommend we do either 1 or 3, but not 2.

If we will have a good chance to modify the base specification as well
as the state machine to support mobility optimization in a future (my
original impression was that it would be less likely to do that), I
would go with option 3.  I don't agree with option 1 for which
significant issues were already raised.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Dec 2004 15:31:35 -0800

> would go with option 3.  

The mobility optimization would be in another spec. Hence, the base spec
would not be modified (it does not have to be modified...).

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 06 Dec 2004 15:38:18 -0500

> would not be modified (it does not have to be modified...).

I see.  Thank you for the clarification.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 07 Dec 2004 19:11:04 +0100

Hi Alper,

>would not be modified (it does not have to be modified...).
I have a doubt here: let suppose we remove this section then PANA spec 
does not know anything about that. Then we add in another document, for 
example, solution exposed in the current PANA spec. Here we would be 
introducing new AVPs (session Id ) and a change of  PaC and PAA 
behaviour  and their state machines... If I understand well, this 
mobility optimization would not be valid because we are changing PANA 
spec (behaviour and new AVPs) (is this your thought?) ... or there would 
not be problem by adding this new AVPs and changing state machines in 
the new spec?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 8 Dec 2004 16:42:40 +0100

Hi,

> not be problem by adding this new AVPs and changing state machines in 

I think that the only problem that we add while deleting this section is
about the fact that we may need to add AVPs. In the current mobility optimization section we
do not talk about modify state machines. 

regards,

-- 
[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Dec 2004 15:28:56 -0500

Hi Julien,

The state machines of the base specification will be more simplified
than the currently defined in draft-ohba-pana-statemachine when we
remove the mobility section.  In other words, changing state machines 
will be needed when we add mobility feature later.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 08 Dec 2004 21:07:16 +0100

Hi Julien, please see inline

>do not talk about modify state machines. 
What I mean is : if we remove current mobility optimization section , we 
remove PaC and PAA behaviour described in this section:
PaC behaviour

"Upon changing its point of attachment, a PaC that wants to quickly 
resume its ongoing PANA session without running EAP MAY send its 
unexpired PANA session identifier in its PANA-Start-Answer message. "

In a new mobility optimization spec I think apart from we need an 
additional AVP (Session-Id) and a new MAC AVP,  we should say that PaC 
is able to receive a PBR or PAR. Without this section in PANA base spec, 
I think PaC would be only able to receive PAR after PSR but not PBR so I 
think it would imply a modification in the state machine in the future.

PAA behaviour

"In case the current PAA can retrieve the on-going PANA session 
attributes from the previous PAA, the PANA session continues with a 
PANA-Bind exchange."

Removing the section, PAA could not send a PBR after PSR. This feature 
should be included in mobility optimization spec but I still think it 
would change PAA state machine in a PANA base spec without mobility section.

Comments?

Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 08 Dec 2004 21:10:08 +0100

Hi all

I think so too.

Regards

---

From: Alper Yegin <[email-masked]>
Date: Wed, 08 Dec 2004 12:58:05 -0800

Hi Rafa,

I don't see a problem. If you do, please let us know.

We can specify this optimization such that, when a PaC requests it and
PAA does not support it, the standard (unoptimized) flow is executed --
i.e., no impact on the base specification. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Dec 2004 18:34:40 -0500

If the "Mobility" section is removed, then we can also remove section
"11.9 Mobility Optimization".

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 09 Dec 2004 02:58:57 +0100

Hi Alper...

>i.e., no impact on the base specification.
(*)In this case,  PaC would send PSA with Session-Id AVP becuase it 
implements  mobility optimization spec but I think PAA would send a 
PANA-Error-Request with PANA_AVP_NOT_ALLOWED because a Session-Id AVP 
would not make sense in a PSA.

In any case I think I get your point. The idea would be we can have PaCs 
and PAAs based on PANA base  WITHOUT mobility section spec and PaCs and 
PAAs that implements PANA base spec + Mobility Optimization Spec. 
Interactions between these "different" PaCs and PAAs could be described 
in the Mobility Optimization Spec. For example in * , in Mobility 
Optimization Spec could include:

"If PaC receives a PANA-Error-Request with PANA_AVP_NOT_ALLOWED,  would 
send again a PSA without Session-Id in order to run standard process" 
....more or less.

is it your general idea?

Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 09 Dec 2004 03:07:20 +0100

Hi Yoshi

>"11.9 Mobility Optimization".
Also

PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
{ Nonce }
->>>>>>>>> [ Session-Id ] <<<<<<<<<--
[ Cookie ]
[ EAP-Payload ]
[ ISP-Information ]
* [ AVP ]
0*1 < MAC >

and Figure 10.

>>>does not know anything about that. Then we add in another document,
>>>      
>>>
>>for
>>    
>>
>>>spec (behaviour and new AVPs) (is this your thought?) ... or there
>>>      
>>>
>>would
>>    
>>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 08 Dec 2004 18:21:54 -0800

Rafa,

> would not make sense in a PSA.

That should not happen. If you look at the definition of PSA:

                       [ Session-Id ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ ISP-Information ]
                    *  [ AVP ]
                   0*1 < MAC >

"* [AVP]" allows inclusion of other AVPs. If we didn't have that, or the
spec explicitly disallowed Session-ID AVP, that error would have been
generated.

> in the Mobility Optimization Spec. 

Yes.

Alper

> For example in * , in Mobility

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 09 Dec 2004 04:28:39 +0100

Hi Alper...

>spec explicitly disallowed Session-ID AVP, that error would have been
Yes true. I agree.

>  
>
>>In any case I think I get your point. The idea would be we can have
>>    
>>
>PaCs
>  
>
>>and PAAs based on PANA base  WITHOUT mobility section spec and PaCs
>>    
>>
>and
>  
>
>>Interactions between these "different" PaCs and PAAs could be
>>    
>>
>described
>  
>
OK. In this case, option 3 is good for me.

Thanks.

>>"If PaC receives a PANA-Error-Request with PANA_AVP_NOT_ALLOWED,
>>    
>>
>would
>  
>

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 9 Dec 2004 11:38:35 +0100

Hi all,

> will be needed when we add mobility feature later.

basically, I don't say that we won't need to change the state machine. I
just think that for the moment we don't know what would be needed for
the state machine (I guess that it will depend on the chosen solution).
Thus, even if we let the mobility section in the pana specification, we
may need to modify the state machine. So, the "state machine
modification" isn't (in my mind) an argument to let a Mobility Section.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Dec 2004 19:03:32 -0500

Hi Rafa,

> ->>>>>>>>> [ Session-Id ] <<<<<<<<<--

I agree.  Session-Id should be removed from the PSA definition.

> and Figure 10.

Agreed.

Yoshihiro Ohba