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

["Premec, Domagoj" <domagoj.premec at siemens.com>]

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.

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