Subject: [netext] Clarifications regarding the runtime LMA assignment

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Jul 2009 19:45:46 +0300

Hi all,

To follow up and clarify the questions from Rajeev, here is something  
that hopefully makes things clearer. The "proxied" case can be  
represented as below. The assumption is that the rfLMA and the r2LMA  
can exchange information between each other, and that the MAG has SAs  
with both rfLMA and the r2LMA. We do not define how and what goes  
between the rfLMA and the r2LMA. That is internal to the "LMA system",  
whatever that "LMA system" constitutes of (that would imply a single  
vendor within a "LMA system" but I guess it would reflect the reality  
anyway). We need to state in the draft, though, that a MAG can be sure  
the r2LMA has a binding setup when it receives a PBA with both  
redirection information and a successful result code. There is both  
vendor and operator interest in this approach, so I consider it  
important.

      MAG     rfLMA    r2LMA
       |        |        |
       |--PBU-->|- - - - | (redirection takes place,
       |<--PBA--| - - - -|  PBA contains rfLMA & r2LMA
       |        |        |  information)
       |        |        |
       |<=====data======>|
       |        |        |
       |-------PBU------>| (lifetime extension,
       |<------PBA-------|  de-registration, etc
       |        |        |

I don't mind nuking the "direct" solution in the draft. Actually I  
would be happy to do that ;) If folks are fine with options, we could  
add a variation of the "proxied" case, where another roundtrip of PBU/ 
PBA is needed between a MAG and a r2LMA before data can flow. This  
would, of course, be runtime negotiated.

Cheers,
	Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 Jul 2009 11:54:13 -0700

Hi Jouni,

On 7/30/09 9:45 AM, "jouni korhonen" wrote:

> anyway). 

It is NOT ok to say that the rfLMA-r2LMA interactions are implementation
specific, if the LMA assignment mechanism is going to be used between
multiple physical LMAs in a cluster. Tying the cluster to one vendor, using
an IETF specification, does not make sense.

> We need to state in the draft, though, that a MAG can be sure

I would strongly be in favor of standardizing just one mechanism. No
optional stuff, no variations, no runtime negotiation, please...

Vijay

> 
> 
> Cheers,
> Jouni
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 30 Jul 2009 16:09:26 -0400

Hi Jouni,
 
as I mentioned during the meeting, there are two separate issues here: 1) runtime LMA selection, which is simply LMA-1 informing MAG to use LMA-2, and 2) establishing BCE at LMA-2 at the same time that LMA-1 informs MAG.
 
As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is set up at LMA-2.
 
We can consider 2) as a special case which MAY be allowed under specific conditions. But, we need to spell out those conditions clearly and agree. In any case, 2) cannot be the general-purpose protocol. 
 
Regards,
 
-Rajeev

________________________________

From: [email-masked] on behalf of jouni korhonen
Sent: Thu 7/30/2009 9:45 AM
To: [email-masked]
Subject: [netext] Clarifications regarding the runtime LMA assignment

Hi all,

      MAG     rfLMA    r2LMA
       |        |        |

Cheers,
        Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Jul 2009 23:47:17 +0300

Hi Rajeev,

On Jul 30, 2009, at 11:09 PM, Koodli, Rajeev wrote:

>
> Hi Jouni,
>
> as I mentioned during the meeting, there are two separate issues  
> here: 1) runtime LMA selection, which is simply LMA-1 informing MAG  
> to use LMA-2, and 2) establishing BCE at LMA-2 at the same time that  
> LMA-1 informs MAG.
>
> As a baseline protocol, we need 1), i.e., LMA-1 informs MAG about  
> LMA-2, and MAG then contacts LMA-2 with PBU/PBA; only then BCE is  
> set up at LMA-2.

Ok. Fine. The case 1) where LMA1 informs MAG about LMA2, is what we  
all agree on.

>
> We can consider 2) as a special case which MAY be allowed under  
> specific conditions. But, we need to spell out those conditions  
> clearly and agree. In any case, 2) cannot be the general-purpose  
> protocol.

For the case 2) would you be OK if we, for example:
   o Add a flag in the response mobility option, which indicates  
whether there is already a BCE setup in LMA2.
   o Describe the conditions required for the above to be possible.

Cheers,
	Jouni

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 31 Jul 2009 05:49:27 -0400

Hi,

Rajeev:> I would start with the second bullet. Once we agree on that, it would be trivial to add a flag IMO.

-Rajeev

Cheers,
        Jouni

---

From: jouni korhonen <[email-masked]>
Date: Fri, 31 Jul 2009 13:57:17 +0300

On Jul 31, 2009, at 12:49 PM, Koodli, Rajeev wrote:

> Rajeev:> I would start with the second bullet. Once we agree on  
> that, it would be trivial to add a flag IMO.'

Righty, I'll work for that.

Cheers,
	Jouni

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 01 Aug 2009 02:55:32 +0900

Hi Rajeev,

> We can consider 2) as a special case which MAY be allowed under specific conditions. But, we need to spell out those conditions clearly and agree. In any case, 2) cannot be the general-purpose prot…

We don't necessarily have to make 2) as a special case. It's just one
way of realization and can be treated equally.

Regards,
-- 
Hidetoshi

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 31 Jul 2009 16:37:33 -0400

Hello Yokota-san.

> way of realization and can be treated equally.

Well, redirecting MAG is to a different LMA and establishing BCE at the redirected LMA are two different things.

We need to solve the first part for sure, and we can consider allowing the second once we understand the picture clearly.

Regards,

-Rajeev

Regards,
--
Hidetoshi