|
»
« Return to Thread: AD review of draft-ietf-mipshop-transient-bce-pmipv6
Re: AD review of draft-ietf-mipshop-transient-b
by Marco Liebsch
::
Rate this Message:
Hi Jari,
please see below and in-line for our response to the remaining comments.
Jari Arkko schrieb:
> I have reviewed this draft. The draft is generally well written and
> easy to read. With the exception of two major issues and a number of
> smaller issues its in very good shape. I need to hear your explanation
> first for the two major issues before I can say anything about how we
> should move forward. Hopefully the fix, if needed, is small.
>
> Please respond to the issues below and revise the document accordingly.
>
> Technical:
>
> *Host effect*:
>
> I failed to understand what the effect to hosts is, and what is
> expected from the host implementation when two interfaces are active
> at the same time. Or do you assume this can happen? Are the
> requirements the same as those in RFC 5213 or do they go beyond it?
> For instance, presumably the host could be switching interface 1 to
> interface 2 in an atomic fashion, but some packets could still be in
> flight from the first MAG to the LMA, so the ability to accept those
> packets is important. But it would be a very different situation if
> you assumed the host should be able to keep alive two different
> interfaces, using the same IP address on both, and be able to accept
> traffic to them and/or send traffic to the right outgoing interface.
>
> Please explain this to me first and then we can see if the document
> needs changes because of this.
>
> *Corner cases*:
>
> The specification needs to include a description of what happens in
> cases where you move on from the nMAG to a (n+1)MAG while in the
> transient states. There may be other corner cases as well; the loss of
> PBUs is well handled already, but I'm concerned about other sequences
> of events that the orderly movement from one place to another. You
> move from A to B and while that movement is still in progress, you
> move back to A. And so on.
>
> *Single HNP*:
>> The aforementioned problem is illustrated in Figure 1, which assumes
>> that the HNP will be assigned under control of the LMA.
> Please go through the specification and ensure that it does not assume
> there's a single HNP -- RFC 5213 assumes a set.
The transient BCE extension and description focuses on the HNP
of the relevant interface. Of course the LMA can handle a set of
HNPs, which does not conflict with the transient BCE extension.
If you think this needs clarification, we could add such as statement
to the draft.
>
> *Inconsistency*:
>> 4.6.2. Activation of a transient BCE
>>
>>
>> When the LMA receives a PBU from an MN's nMAG which has no Transient
>> Binding option included, the LMA should check whether the MN's BCE is
>> in any of the specified transient states. If the MN's BCE is not
>> transient, the LMA processes the PBU and updates the MN's BCE
>> according to the PMIPv6 protocol [RFC5213].
>
> Isn't this in conflict with Figure 4, which allowed the LMA to decide
> that it wants to set up a transient BCE even if no transient option
> was included?
The case where the LMA decides to enter a transient BCE is
covered in 4.6.1, where we describe the “Initiation of a Transient BCE”.
The section you refer to describes solely activation of an existing
transient state. Adding the case you describe could somehow mix
the steps. Do you agree?
>
> *Alignment*:
>> The format of the Transient Binding option is as follows.
>
> Please specify alignment rules, too.
As the option meets a 32-bit boundary alignment, we don’t
see any additional alignment rule here. But we can add a statement
that the Transient Binding option has no alignment requirement.
>
> *References*:
>
>> [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>> "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861
>> <http://tools.ietf.org/html/rfc4861>,
>> September 2007.
>>
>> [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>> Address Autoconfiguration", RFC 4862
>> <http://tools.ietf.org/html/rfc4862>, September 2007.
> In my opinion, these references do not need to be normative. They form
> a part of the rationale and explanation of the environment, but they
> are not required reading for implementing this in proxy MIP nodes.
We agree and will move these RFCs to informative references.
>
> *Editorial*:
>
All your editorial comments are valid and very much appreciated.
We’ll expand all abbreviation on first use and will shorten and clarify
the paragraph you pointed to.
Thanks and best regards,
marco
>> In order to eliminate the risk of lost packets, this
>> document specifies an extension to PMIPv6 that utilizes a new
>> mobility option in the Proxy Binding Update (PBU) and the Proxy
>> Binding Acknowledgement (PBA) between nMAG and LMA.
> You need to expand references to nMAG and LMA on first use. Please go
> over the other abbreviations from the document as well.
>
>>
>> The aforementioned problem is illustrated in Figure 1, which assumes
>> that the HNP will be assigned under control of the LMA.
>>
> I don't think HNP term has appeared before in the document.
>
>> the
>> forwarding entry of the pMAG is removed from the MN's BCE, the
>> Transient-L state is left and the BCE state changes to active.
>
> Maybe ".... MN's BCE, the BCE state changes to active."
>
>> nMAG enters the MN's data, such as the assigned HNP, into its BUL and
>
> BUL term has not appeared before
>
>> experienced by MNs, which have multiple network interfaces
>
> MN term has not appeared before
>
>> AAA messages. This document specifies advanced binding cache control
>
> AAA term has not appeared before
>
>> the PBA, such as the MN's HNP and the link local address to be used
>
> HNP term has not appeared before
>
>> Thus it is not possible that due to the loss of
>> signaling or due to a failure of the nMAG to initiate turning a
>> transient BCE into an active BCE the transient state may not get
>> terminated, i.e. stable operation of the PMIPv6 protocol [RFC5213
>> <http://tools.ietf.org/html/rfc5213>]
>> has reliably recovered.
> Lengthy sentence. Please see if you can make it clearer.
>
>> TIMEOUT_1 expires. . After TIMEOUT_1 seconds, the protocol
>
> Two dots.
>
> Jari
>
> _______________________________________________
> Mipshop mailing list
> Mipshop@...
> https://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@...
https://www.ietf.org/mailman/listinfo/mipshop
please see below and in-line for our response to the remaining comments.
Jari Arkko schrieb:
> I have reviewed this draft. The draft is generally well written and
> easy to read. With the exception of two major issues and a number of
> smaller issues its in very good shape. I need to hear your explanation
> first for the two major issues before I can say anything about how we
> should move forward. Hopefully the fix, if needed, is small.
>
> Please respond to the issues below and revise the document accordingly.
>
> Technical:
>
> *Host effect*:
>
> I failed to understand what the effect to hosts is, and what is
> expected from the host implementation when two interfaces are active
> at the same time. Or do you assume this can happen? Are the
> requirements the same as those in RFC 5213 or do they go beyond it?
> For instance, presumably the host could be switching interface 1 to
> interface 2 in an atomic fashion, but some packets could still be in
> flight from the first MAG to the LMA, so the ability to accept those
> packets is important. But it would be a very different situation if
> you assumed the host should be able to keep alive two different
> interfaces, using the same IP address on both, and be able to accept
> traffic to them and/or send traffic to the right outgoing interface.
>
> Please explain this to me first and then we can see if the document
> needs changes because of this.
>
> *Corner cases*:
>
> The specification needs to include a description of what happens in
> cases where you move on from the nMAG to a (n+1)MAG while in the
> transient states. There may be other corner cases as well; the loss of
> PBUs is well handled already, but I'm concerned about other sequences
> of events that the orderly movement from one place to another. You
> move from A to B and while that movement is still in progress, you
> move back to A. And so on.
>
> *Single HNP*:
>> The aforementioned problem is illustrated in Figure 1, which assumes
>> that the HNP will be assigned under control of the LMA.
> Please go through the specification and ensure that it does not assume
> there's a single HNP -- RFC 5213 assumes a set.
The transient BCE extension and description focuses on the HNP
of the relevant interface. Of course the LMA can handle a set of
HNPs, which does not conflict with the transient BCE extension.
If you think this needs clarification, we could add such as statement
to the draft.
>
> *Inconsistency*:
>> 4.6.2. Activation of a transient BCE
>>
>>
>> When the LMA receives a PBU from an MN's nMAG which has no Transient
>> Binding option included, the LMA should check whether the MN's BCE is
>> in any of the specified transient states. If the MN's BCE is not
>> transient, the LMA processes the PBU and updates the MN's BCE
>> according to the PMIPv6 protocol [RFC5213].
>
> Isn't this in conflict with Figure 4, which allowed the LMA to decide
> that it wants to set up a transient BCE even if no transient option
> was included?
The case where the LMA decides to enter a transient BCE is
covered in 4.6.1, where we describe the “Initiation of a Transient BCE”.
The section you refer to describes solely activation of an existing
transient state. Adding the case you describe could somehow mix
the steps. Do you agree?
>
> *Alignment*:
>> The format of the Transient Binding option is as follows.
>
> Please specify alignment rules, too.
As the option meets a 32-bit boundary alignment, we don’t
see any additional alignment rule here. But we can add a statement
that the Transient Binding option has no alignment requirement.
>
> *References*:
>
>> [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>> "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861
>> <http://tools.ietf.org/html/rfc4861>,
>> September 2007.
>>
>> [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>> Address Autoconfiguration", RFC 4862
>> <http://tools.ietf.org/html/rfc4862>, September 2007.
> In my opinion, these references do not need to be normative. They form
> a part of the rationale and explanation of the environment, but they
> are not required reading for implementing this in proxy MIP nodes.
We agree and will move these RFCs to informative references.
>
> *Editorial*:
>
All your editorial comments are valid and very much appreciated.
We’ll expand all abbreviation on first use and will shorten and clarify
the paragraph you pointed to.
Thanks and best regards,
marco
>> In order to eliminate the risk of lost packets, this
>> document specifies an extension to PMIPv6 that utilizes a new
>> mobility option in the Proxy Binding Update (PBU) and the Proxy
>> Binding Acknowledgement (PBA) between nMAG and LMA.
> You need to expand references to nMAG and LMA on first use. Please go
> over the other abbreviations from the document as well.
>
>>
>> The aforementioned problem is illustrated in Figure 1, which assumes
>> that the HNP will be assigned under control of the LMA.
>>
> I don't think HNP term has appeared before in the document.
>
>> the
>> forwarding entry of the pMAG is removed from the MN's BCE, the
>> Transient-L state is left and the BCE state changes to active.
>
> Maybe ".... MN's BCE, the BCE state changes to active."
>
>> nMAG enters the MN's data, such as the assigned HNP, into its BUL and
>
> BUL term has not appeared before
>
>> experienced by MNs, which have multiple network interfaces
>
> MN term has not appeared before
>
>> AAA messages. This document specifies advanced binding cache control
>
> AAA term has not appeared before
>
>> the PBA, such as the MN's HNP and the link local address to be used
>
> HNP term has not appeared before
>
>> Thus it is not possible that due to the loss of
>> signaling or due to a failure of the nMAG to initiate turning a
>> transient BCE into an active BCE the transient state may not get
>> terminated, i.e. stable operation of the PMIPv6 protocol [RFC5213
>> <http://tools.ietf.org/html/rfc5213>]
>> has reliably recovered.
> Lengthy sentence. Please see if you can make it clearer.
>
>> TIMEOUT_1 expires. . After TIMEOUT_1 seconds, the protocol
>
> Two dots.
>
> Jari
>
> _______________________________________________
> Mipshop mailing list
> Mipshop@...
> https://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@...
https://www.ietf.org/mailman/listinfo/mipshop
« Return to Thread: AD review of draft-ietf-mipshop-transient-bce-pmipv6
| Free embeddable forum powered by Nabble | Forum Help |
