Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01

[Vijay Devarapalli <vijay at wichorus.com>]

On 10/14/08 1:49 AM, "Premec, Domagoj" <domagoj.premec at siemens.com> wrote:

> Vijay,
> 
>> First of all, RFC 5213 did not extend the binding cache entry
>> structure to store both the control plane and data plane
>> addresses. RFC 5213 does not specify that the LMA should
>> store both the source address of the PBU and the address in
>> the altCoA option in the binding cache.
> 
> This is not a problem from the perspective of RFC 5213 as the LMA does not
> send unsolicited messages to the MAG.

Well, one could use the HA Switch mechanism (RFC 5142) for the LMA to
re-direct the MAG to another LMA.

> In the context of RFC 5213 there is no
> need to store both the alt-CoA and the source IP of the PBU in the BCE, so I
> wouldn't expect RFC 5213 to specify any extensions to the BCE in this regard.
> 
>> Secondly, the above scenario is not realistic, IMHO. The
>> different IP addresses for the control plane blade and the
>> multiple data plane blades is typically not exposed to the
>> other network elements.
> 
> Well.. different designs are possible. I'm not going to argue that my
> interpretation of the intended alt-CoA usage is right. In fact, if I'm right
> then the mechanims for the other direction is missing (e.g. alt-CoA in PBAck)
> and we'd need to do something about it as this other direction is more
> important since the LMA has to deal with more load then the MAG.
> 
> So if I agree with you, then I'm confused about the purpose of the alt-CoA in
> the RFC 5213, what is the usage for it?

Coming back the discussion we were having, I think it is sufficient for the
binding revocation document to say that the binding revocation indication
message should be sent to the Proxy CoA.

Vijay

> 
> domagoj
>  
> 
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
>> Sent: 13. listopad 2008 20:10
>> To: Premec, Domagoj; Ahmad Muhanna
>> Cc: Netlmm; mext at ietf.org
>> Subject: RE: [netlmm] FW: comment
>> ondraft-ietf-mext-binding-revocation-01
>> 
>> Premec, Domagoj wrote:
>>> Hi Vijay,
>>> 
>>> RFC 5213 mentiones the usage of alt-CoA at several places, for
>>> example:
>>> 
>>>       However, when there is an Alternate Care-of Address option
>>> present
>>>       in the request, this address will be not be considered as the
>>>       Proxy-CoA, but the address in the Alternate Care-of Address
>>> option
>>>       will be considered as the Proxy-CoA.
>>> 
>>> I thought that the scenario in mind here is the MAG with
>> one control 
>>> plane blade and several data plane blades, and the alt-CoA would
>>> contain the address of the data plane.
>> 
>> First of all, RFC 5213 did not extend the binding cache entry
>> structure to store both the control plane and data plane
>> addresses. RFC 5213 does not specify that the LMA should
>> store both the source address of the PBU and the address in
>> the altCoA option in the binding cache. There is only one
>> address - the Proxy CoA, that is stored in the binding cache entry.
>> So trying to send the binding revocation indication message
>> to any other address, other than what is stored in the
>> binding cache (Proxy CoA), may not work.
>> 
>> Secondly, the above scenario is not realistic, IMHO. The
>> different IP addresses for the control plane blade and the
>> multiple data plane blades is typically not exposed to the
>> other network elements. Each blade acting as a separate MAG
>> is of course possible, but that is not relevant to what we
>> are talking about here.
>> 
>> Vijay
>> 
>> 
>> 
>>> 
>>> domagoj
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Vijay Devarapalli [mailto:vijay at wichorus.com]
>>>> Sent: 10. listopad 2008 23:30
>>>> To: Ahmad Muhanna; Premec, Domagoj
>>>> Cc: Netlmm; mext at ietf.org
>>>> Subject: RE: [netlmm] FW: comment
>>>> ondraft-ietf-mext-binding-revocation-01
>>>> 
>>>> Hi Domagoj, Ahmad,
>>>> 
>>>> In MIPv6, if the binding update is successful, the binding ack is
>>>> always sent to the CoA and not to the source address of the BU. If
>>>> the AltCoA option is used, then the binding ack would go
>> back to the 
>>>> address that appeared in the AltCoA option.
>>>> 
>>>> In PMIPv6, I don't believe there is a scenario where you
>> would want 
>>>> to use the AltCoA option. (if someone has a valid scenario, please
>>>> let me know).
>>>> 
>>>> netlmm-bounces at ietf.org wrote:
>>>>> **** Adding Mext mailing list. Also correcting the
>> subject. Comment
>>>>> is on binding revocation not GRE:) ***
>>>>> 
>>>>> Hi Domagoj,
>>>>> 
>>>>> I believe this is a valid concern. I guess either way
>> should work, 
>>>>> but I believe the cleaner solution is to have some text
>> to indicate 
>>>>> that if the alt-CoA included in the PBU, the revocation should be
>>>>> sent to the same address the PBA is sent to. In this case
>> the source 
>>>>> of the PBU.
>>>> 
>>>> *If* the AltCoA option is used, then the address that
>> appears in the 
>>>> AltCoA option would be stored as the proxy CoA in the
>> binding cache 
>>>> entry. When a binding revocation needs to be sent, it
>> would be sent 
>>>> to the proxy CoA in the binding cache entry. For the binding
>>>> revocation document, I think it is sufficient to say that the
>>>> revocation message is sent to the Proxy CoA. It shouldn't say
>>>> anything about the source address of the PBU or the address in the
>>>> AltCoA option. In other words, the binding revocation
>> document should 
>>>> not care about the use of AltCoA option.
>>>> 
>>>> Vijay
>>>> 
>>>>> 
>>>>> If people feels that is the best approach, we can add some
>>>>> clarification to the draft.
>>>>> 
>>>>> What do you think?
>>>>> 
>>>>> Regards,
>>>>> Ahmad
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Premec, Domagoj [mailto:domagoj.premec at siemens.com]
>>>>>> Sent: Friday, October 10, 2008 7:59 AM
>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
>>>>>> Cc: Netlmm
>>>>>> Subject: comment on draft-ietf-netlmm-grekey-option-01
>>>>>> 
>>>>>> Hi Ahmad,
>>>>>> 
>>>>>> I have a comment on the interactions between the binding
>> revocation 
>>>>>> mechanism and the alt-CoA usage as specified in RFC
>> 5213. According 
>>>>>> to
>>>>> 
>>>>>> the RFC 5213, the MAG is allowed to use the alt-CoA to
>> redirect the 
>>>>>> downlink traffic to an address different from the source
>> address of 
>>>>>> the PBU. In this case the Binding revocation will get
>> sent to the 
>>>>>> alt-CoA address, but I think it should actually be sent to the
>>>>>> source address of the PBU, as this is where the
>> signalling part of
>>>>>> the MAG is
>>>>> 
>>>>>> located. Is this is a valid concern or should we assume that the
>>>>>> MAG also accepts signalling messages at the alt-CoA?
>>>>>> 
>>>>>> domagoj
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> netlmm mailing list
>>>>> netlmm at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>> _______________________________________________
>>>>> netlmm mailing list
>>>>> netlmm at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>> 
>> 

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext