[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01
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. 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?
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