Subject: Re: [netext] Clarifications regarding the runtime LMA assignment

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 03 Aug 2009 10:36:23 +0900

Hi Rajeev,

Koodli, Rajeev wrote:
>  
> Hello Yokota-san.
>  
> 
> 
>> We don't necessarily have to make 2) as a special case. It's just one
>> 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.

I agree that 1) and 2) are separate things, but handling 1) and 2) at
the same time doesn't have to be considered as special.

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

I agree with that order of resolution since 2) won't happen without 1).

Regards,
-- 
Hidetoshi

> Regards,
> 
> -Rajeev
> 
> 
> Regards,
> --
> Hidetoshi
> 
>> 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,
>>
>> 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
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>>
>>
>>
> 
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
> 
> 
>