Pete,
See my comments inline:
On Apr 14, 2011, at 10:23 PM, Pete McCann wrote:
> Major issues:
>
> Section 5.4:
> You should add a paragraph on the possibility of loops in the
> LMA assignment operation and specify that the MAG must
> take some action to detect and terminate such loops, such
> as a maximum redirection count or tracking the IP addresses
> of the LMAs it has been assigned so far and looking for duplicates.
Section 3 says:
...
functionality. MAGs and LMAs implementing the runtime LMA assignment
functionality MUST support the runtime LMA assignment during the
initial PBU/PBA exchange which creates a new mobility session. A
mid-session LMA assignment may make use of [RFC5142]
I thought this was clear enough already. However, I am OK to add a new
configuration knob for maximum number of consecutive assignments. How about:
In Section 5.4.2:
Each time the MAG receives a PBA with the Status Value set to
Rejected_but_Redirected, it MUST check whether the
maximum runtime assignment count value (initialized to the
MaxRedirectCount when a new mobility session establishment
starts) is greater than zero. If the counter value is greater
than zero, it is decreased by one and the MAG can proceed with
the runtime assignment. If the counter value is zero, then the
MAG MUST treat the PBU was rejected by the LMA and log the event.
In Section 7:
MaxRedirectCount
This configuration variable is available in a MAG and tells
the maximum number of allowed consecutive runtime assignments.
When the EnableLMARedirectFunction is TRUE, the MaxRedirectCount
MUST be set to one or more. When the EnableLMARedirectFunction
is FALSE, the MaxRedirectCount MUST be zero.
>
> Section 6: (Multi-Homing)
> This section makes a major assumption that all of the MN's
> sessions are somehow able to be correlated and that all MAGs
> will direct their tunnels back to the same LMA. In fact this may
This is how real deployments plan to do stuff..
> not be possible when the MN has interfaces on multiple different
> technologies with multiple different network operators and different
> subscriber credentials. There is no way to enforce that all sessions
Ok. My assumption was that there is one subscriber identity (but possibly
multiply credentials) that maps/leads to a single "home network". This would be
e.g. how things get done in real world.
> go to the same LMA. Besides, why is this even necessary? The
> section does not give a concrete justification for why all the sessions
> need to go through the same LMA.
Justification is rather simple. Inter-technology handovers become impossible if
different accesses are hosted in different LMAs.
How about the following clarification to Section 6:
Old text:
A MN can be multi-homed. A single LMA entity should have the control
over all possible multi-homed mobility sessions the MN has. All
mobility sessions a multi-homed MN may have SHOULD be anchored in the
single LMA entity. Therefore, once the MN has established one
mobility session with one LMA, the subsequent mobility sessions of
the same MN SHOULD be anchored to the LMA that was initially
assigned.
One possible solution already supported by this specification is
applying the runtime LMA assignment only for the very first initial
attach a multi-homed MN does towards a PMIPv6 domain. After the
initial attach, the assigned r2LMA Address has been stored in the
policy profile. For the subsequent mobility sessions of the multi-
homed MN, the same assigned r2LMA Address would be used and there is
no need to contact the rfLMA.
New text:
A MN can be multi-homed i.e. have network connectivity over multiple
interfaces connected one or more accesses). A single LMA entity SHOULD
have the control over all possible multi-homed mobility sessions the MN
has or otherwise handovers between different accesses and interfaces
become challenged, if not impossible. All mobility sessions a
multi-homed MN may have SHOULD be anchored in the single LMA entity.
Therefore, once the MN has established one mobility session with one LMA,
the subsequent mobility sessions of the same MN SHOULD be anchored to the
LMA that was initially assigned.
One possible solution already supported by this specification is
applying the runtime LMA assignment only for the very first initial
attach a multi-homed MN does towards a PMIPv6 domain. After the
initial attach, the assigned r2LMA Address has been stored in the
policy profile. For the subsequent mobility sessions of the multi-
homed MN, the same assigned r2LMA Address would be used and there is
no need to contact the rfLMA. Discovering the same r2LMA each time
has an assumption that the MN has an identity that can always point
to the same policy profile independent of the used access.
>
> Minor issues:
>
> Section 5.2:
> Otherwise, the rfLMA MUST act as a normal RFC 5213
> defined LMA for the MAG.
> The sentence just prior talks about rejecting the PBU with
> a PBA 130 Insufficient resources. I think you need an extra
> if clause here:
> If the rfLMA is able to make the assignment to an r2LMA,
> it returns a PBA with the Redirect extension as defined
> below. Otherwise, the rfLMA MUST act as a normal RFC 5213
> defined LMA for the MAG.
OK.
>
> You need a paragraph at the end of Section 5.2 that describes
> what is about to happen in the document:
> We next describe two models for the runtime assignment of
> the LMA. In Section 5.3, we describe a model where the
> assignment by the rfLMA and the binding at the r2LMA are
> created at the same time. This scenario is optimized for
> the case where the rfLMA and r2LMA are co-located or
> integrated by a "proxy MAG" protocol which is described
> in Section 5.3.4. In Section 5.4, we describe a mode where
> the assignment by the rfLMA takes place first, and then the
> binding at the r2LMA is created by a separate PBU/PBA
> exchange that happens in a second round-trip.
Sound good. Thanks.
> When I first read Section 5.3 I thought it was the only model
> being supported and was quite concerned.
>
>
> Nits/editorial comments:
>
> Section 1:
> reasons, why
> SHOULD BE:
> reasons why
>
> practise
> SHOULD BE:
> practice
>
> in-line what
> SHOULD BE:
> in-line with what
>
> Section 3:
> domain, is not
> SHOULD BE:
> domain is not
>
> assignment, unless
> SHOULD BE:
> assignment unless
>
> Section 4.1:
> There can zero
> SHOULD BE:
> There can be zero
>
> Section 5.1:
> the of the
> SHOULD BE:
> the
>
> Section 5.2:
> a reason or other
> SHOULD BE:
> some reason
Above NITs are OK.
>
> The rfLMA MUST only assign the MAG with a new r2LMA that it knows the
> MAG has a SA with or the MAG and the r2LMA are able to create it
> dynamically.
> SHOULD BE:
> The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
> the MAG has an SA or with which it knows the MAG can establish an SA
> dynamically.
Ok.
>
> and the r2LMA, are again deployment
> SHOULD BE:
> and the r2LMA are again deployment
>
> transport, if the MAG
> SHOULD BE:
> transport if the MAG
>
> Section 5.3.1:
> Address where the PBU was sent to
> SHOULD BE:
> Address to which the PBU was sent
>
> Section 5.3.2:
> considerations has to taken
> SHOULD BE:
> considerations have to be taken
>
> BUL to correspond the r2LMA address
> SHOULD BE:
> BUL to contain the r2LMA address
>
> Section 5.3.4:
> then the proceeds as mentioned in Section 5.2),
> SHOULD BE:
> then the PBU is processed as described in Section 5.2,
>
> Section 5.4.1:
> Address where the PBU was sent to
> SHOULD BE:
> Address to which the PBU was sent
Above are OK.
Thanks,
Jouni
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
