Subject: [netlmm] Pasi's DISCUSS and discussions thereof

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Apr 2008 23:14:06 -0700

All,
Attached are most of the email exchanges happening around Pasi's DISCUSS
on the document.  I've been experiencing some email issues - so, it is
possible that this is not an exhaustive capture of all the emails.
However, this should capture the bulk of the conversation. 

Thanks,
Vidya

Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Pasi Eronen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 26 Mar 2008 06:00:17 -0700

Discuss:
Early 3GPP specifications attempted to give phones just an IPv6
address from a single prefix. RFC 3314 describes why this isn't a
good idea, and in particular, why compliance with current and
future IPv6 standards really requires allowing multiple
prefixes. 3GPP fixed their specs based on this. It seems that if
3GPP starts using Proxy Mobile IPv6, this part would break again?
(At least it seems the document assumes that MN gets a single home
network prefix, not multiple.)

The specification seems to assume that MN has just _the_ link-local
address. This restriction is not present in the IPv6 Addressing
Architecture (or many common link layers for IPv6, such as 802.11),
and might not be true in e.g. some SEND configurations. Thus, it
seems enabling Proxy Mobile IPv6 here could break functionality
that would work without it? At the very least, the document should
explain what happens if the client (not knowing that Proxy Mobile
IPv6 is in use) configures more than one link-local address.

The specification is vague on what entity the MN-Identifier
identifies, or is required to identify. Section 6.6 suggests that
it could correspond to Chargeable-User-Identity RADIUS attribute --
but that attribute does not identify a node, it identifies a user
account that could be used from multiple nodes simultaneously.
(Some deployments may of course prohibit using the same user
account from multiple nodes, but in other cases, it's common:
consider an enterprise user with two laptops, but just a single
user account.)  The spec needs to say what the uniqueness
requirements for MN-Identifier are: in particular, is it OK to have
multiple MNs, connecting via the same MAGs/LMAs, with the same
MN-Identifier?  (And if this is OK, perhaps the name
"MN-Identifier" should be changed.)

I couldn't find text saying whether the MAG decrements the Hop
Limit field or not (for packets it forward to the LMA, from the
LMA, or between directly connected nodes if EnableMAGLocalrouting
is enabled). (I'm not sure whether LMA behavior is specified,
either?)

The spec seems to use the word "Interface Identifier" to describe
two completely separate things. First, there's the IPv6 Interface
Identifier, which is used as the lower N bits (usually 64) of some
IPv6 address. Second, there's the "Mobile Node Interface
Identifier", which -- it seems -- is not necessarily used in any
IPv6 address, and could be of any length (even longer than 128
bits). I'd strongly suggest using some other word for the latter
(maybe "link-layer identifier"?), as this is almost certain to
confusion (and possibly interoperability problems when implementors
assume that they're the same -- and in some networks, they actually
could be).

The statement "This specification [...] does not support Shared-Prefix
model" seems false, as Appendix B specifies how to support it.  (And
given that both LMA and MAG require code changes to support it in
interoperable fashion, I don't quite see how this appendix could be
called non-normative, either.) I'd suggest moving the specification
of Shared-Prefix model to a separate document.

Comment:
Current specs about Mobile IPv6/IPsec interaction specify also
payload packet protection (which is optional to use). Section 4
about Proxy Mobile IPv6/IPsec interaction seems to ignore this
topic entirely.  At least a statement that no payload packet
protection is provided (possibly with short rationale why not)
should be there.

Section 5.3.2, step 3, is unclear about whether the LMA is allowed
to ignore the prefix "hint" or not. The text seems to say that if
the hint cannot be respected, the LMA must return an error -- but
then calling it "hint" is slightly misleading.

Section 4 would have been lot easier to understand if it had said
in the beginning that PBUs don't have the Home Address destination
option (and PBAs don't have the Type 2 RH with home address).

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Sri Gundavelli" <[email-masked]>
To: "Pasi Eronen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 00:53:54 -0700

Hi Pasi,

Thanks for the review. Please see inline.

Sri

> -----Original Message-----
> From: Pasi Eronen [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2008 6:00 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Discuss:
> Early 3GPP specifications attempted to give phones just an IPv6
> address from a single prefix. RFC 3314 describes why this isn't a
> good idea, and in particular, why compliance with current and
> future IPv6 standards really requires allowing multiple
> prefixes. 3GPP fixed their specs based on this. It seems that if
> 3GPP starts using Proxy Mobile IPv6, this part would break again?
> (At least it seems the document assumes that MN gets a single home
> network prefix, not multiple.)
> 

The base spec definition allows a single prefix to be assigned to
a given interface. Extending this to support multiple prefix 
assignment is not an issue. But, attempting to cover that in this
document would be bit extreme from the specification point of view
and specially when we add multi-homing to the mix. We suggest doing
this in an extension document and that will have no impact on this
specification. To ensure we can extend this and with minimal changes,
we can modify the HNP option and provide the container for carrying
multiple prefixes. The subsequent spec that the authors will work
will address this issue.

> The specification seems to assume that MN has just _the_ link-local
> address. This restriction is not present in the IPv6 Addressing
> Architecture (or many common link layers for IPv6, such as 802.11),
> and might not be true in e.g. some SEND configurations. Thus, it
> seems enabling Proxy Mobile IPv6 here could break functionality
> that would work without it? At the very least, the document should
> explain what happens if the client (not knowing that Proxy Mobile
> IPv6 is in use) configures more than one link-local address.
> 

The same comment as above. As Jari pointed out, the idea of 
carrying the interface-identifier is to ensure there is no address
collision, when a DNAv6 enabled mobile node after handoff skips
the DAD procedure on the link-local address. In the SDO deployments
where this protocol is extected to be deployed, there is context
transfer mechanims in place (such as R4 interface in WiMAX) and the
serving MAG would know the link-local address of the mobile on the
link and so address collision is not an issue. However, for
completeness, we went ahead and also defined mechanisms to store this
identifier in the MN's BCE on the LMA. We assume there is a single
link-local address identifier. 

All though, extending the link-local address option to support
multiple addresses and fixing the related text is not a a big
deal,  I suggest we address the above two issues in the new spec.
We can post a companion document on this topic. But, solving this
here would add to the document size. (On a lighter note, people are
expecting this document to be as readable as a Harry Potter Novel
and expect to understand every bit in one shot and when remembering
it took few iterations for me to understand any of the base MIP
specs :)). So, I suggest we handle the above two items of mutiple
prefix assignment and multiple link-local address configuration in
a new document.

> The specification is vague on what entity the MN-Identifier
> identifies, or is required to identify. Section 6.6 suggests that
> it could correspond to Chargeable-User-Identity RADIUS attribute --
> but that attribute does not identify a node, it identifies a user
> account that could be used from multiple nodes simultaneously.
> (Some deployments may of course prohibit using the same user
> account from multiple nodes, but in other cases, it's common:
> consider an enterprise user with two laptops, but just a single
> user account.)  The spec needs to say what the uniqueness
> requirements for MN-Identifier are: in particular, is it OK to have
> multiple MNs, connecting via the same MAGs/LMAs, with the same
> MN-Identifier?  (And if this is OK, perhaps the name
> "MN-Identifier" should be changed.)
> 

Section 6.6 talks about the identifiers used for access authentication
(fast reauth ..etc) and the relation to the MN-Identifier. There is
only one identifier that the mobility entities use in the signaling
messages for identifying  a mobile node and it is the MN-Identifier.
However, there are multiple ways in which a MAG can discover this
identifier and one mechanism is the use of CUI. 

We require the MN-Identifier to be unique within a Proxy Mobile IPv6
domain. The below text,

"All the network entities in a Proxy Mobile IPv6 domain MUST be able
 to identify a mobile node, using its MN-Identifier.  This identifier
 MUST be stable across the Proxy Mobile IPv6 domain and the entities
 must be able to use this identifier in the signaling messages."

We can add a line on the uniqueness requirement to this.

> I couldn't find text saying whether the MAG decrements the Hop
> Limit field or not (for packets it forward to the LMA, from the
> LMA, or between directly connected nodes if EnableMAGLocalrouting
> is enabled). (I'm not sure whether LMA behavior is specified,
> either?)
> 

For local routing or for reverse tunneling, the standard IP forwarding
or tunneling semantics apply. The MIP functions are not in the
switching path. I dont think, we can really specify any thing related
to forwarding behavior.

> The spec seems to use the word "Interface Identifier" to describe
> two completely separate things. First, there's the IPv6 Interface
> Identifier, which is used as the lower N bits (usually 64) of some
> IPv6 address. Second, there's the "Mobile Node Interface
> Identifier", which -- it seems -- is not necessarily used in any
> IPv6 address, and could be of any length (even longer than 128
> bits). I'd strongly suggest using some other word for the latter
> (maybe "link-layer identifier"?), as this is almost certain to
> confusion (and possibly interoperability problems when implementors
> assume that they're the same -- and in some networks, they actually
> could be).
> 

I see your point. But, If-Id generally refers to the MAC address.
we will think bit more on this and can change it.

> The statement "This specification [...] does not support Shared-Prefix
> model" seems false, as Appendix B specifies how to support it.  (And
> given that both LMA and MAG require code changes to support it in
> interoperable fashion, I don't quite see how this appendix could be
> called non-normative, either.) I'd suggest moving the specification
> of Shared-Prefix model to a separate document.
> 

Text specified in Appendex section should be just informative and
an implemention claiming compliance to this spec, need not implement
this part. Its purely informational purposes and I dont know if this
gets any validity beyond that. A future spec can support this
configuration and define the specification and this approach may
provide some hints for that spec and thats all to it.

> Comment:
> Current specs about Mobile IPv6/IPsec interaction specify also
> payload packet protection (which is optional to use). Section 4
> about Proxy Mobile IPv6/IPsec interaction seems to ignore this
> topic entirely.  At least a statement that no payload packet
> protection is provided (possibly with short rationale why not)
> should be there.
> 

Ok. 

> Section 5.3.2, step 3, is unclear about whether the LMA is allowed
> to ignore the prefix "hint" or not. The text seems to say that if
> the hint cannot be respected, the LMA must return an error -- but
> then calling it "hint" is slightly misleading.
> 

I'd check the DHCP spec and the term that is normally used for
prefix hints/requests, will fix it.

> Section 4 would have been lot easier to understand if it had said
> in the beginning that PBUs don't have the Home Address destination
> option (and PBAs don't have the Type 2 RH with home address).
> 

hmm.... we chose the term PBU/PBA for the messages and it has
its own format and the rules on what options are carried in these
messages. I wonder if that is not an indication that it may not have
the traditional MIP6 PBU elements. 

Thanks a lot Pasi for your review.

Regards
Sri

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 12:59:42 -0700

Hi Sri,

Thanks for a quick response. Please see inline.

<snip>

> > The specification seems to assume that MN has just _the_
> > link-local address. This restriction is not present in the IPv6
> > Addressing Architecture (or many common link layers for IPv6, such
> > as 802.11), and might not be true in e.g. some SEND
> > configurations. Thus, it seems enabling Proxy Mobile IPv6 here
> > could break functionality that would work without it? At the very
> > least, the document should explain what happens if the client (not
> > knowing that Proxy Mobile IPv6 is in use) configures more than one
> > link-local address.
> > 
> 
> The same comment as above. As Jari pointed out, the idea of carrying
> the interface-identifier is to ensure there is no address collision,
> when a DNAv6 enabled mobile node after handoff skips the DAD
> procedure on the link-local address. In the SDO deployments where
> this protocol is extected to be deployed, there is context transfer
> mechanims in place (such as R4 interface in WiMAX) and the serving
> MAG would know the link-local address of the mobile on the link and
> so address collision is not an issue. However, for completeness, we
> went ahead and also defined mechanisms to store this identifier in
> the MN's BCE on the LMA. We assume there is a single link-local
> address identifier.
> 
> All though, extending the link-local address option to support
> multiple addresses and fixing the related text is not a a big deal,
> I suggest we address the above two issues in the new spec.  We can
> post a companion document on this topic. But, solving this here
> would add to the document size. (On a lighter note, people are
> expecting this document to be as readable as a Harry Potter Novel
> and expect to understand every bit in one shot and when remembering
> it took few iterations for me to understand any of the base MIP
> specs :)). So, I suggest we handle the above two items of mutiple
> prefix assignment and multiple link-local address configuration in a
> new document.

One of the environments described in NETLMM goals document (RFC 4831)
is WLAN switches. In this environment, the client may not be aware
that Proxy Mobile IPv6 is being used, and may attempt to configure
multiple link-local addresses (which is a perfectly fine thing to do
in WLAN).

Given the goal of working with unmodified MNs, at the very least the
document needs to describe what happens in this case. (I'm not quite
sure what exactly does happen, though.)

> > The specification is vague on what entity the MN-Identifier
> > identifies, or is required to identify. Section 6.6 suggests that
> > it could correspond to Chargeable-User-Identity RADIUS attribute --
> > but that attribute does not identify a node, it identifies a user
> > account that could be used from multiple nodes simultaneously.
> > (Some deployments may of course prohibit using the same user
> > account from multiple nodes, but in other cases, it's common:
> > consider an enterprise user with two laptops, but just a single
> > user account.)  The spec needs to say what the uniqueness
> > requirements for MN-Identifier are: in particular, is it OK to have
> > multiple MNs, connecting via the same MAGs/LMAs, with the same
> > MN-Identifier?  (And if this is OK, perhaps the name
> > "MN-Identifier" should be changed.)
> > 
> 
> Section 6.6 talks about the identifiers used for access authentication
> (fast reauth ..etc) and the relation to the MN-Identifier. There is
> only one identifier that the mobility entities use in the signaling
> messages for identifying  a mobile node and it is the MN-Identifier.
> However, there are multiple ways in which a MAG can discover this
> identifier and one mechanism is the use of CUI. 
> 
> We require the MN-Identifier to be unique within a Proxy Mobile IPv6
> domain. The below text,
> 
> "All the network entities in a Proxy Mobile IPv6 domain MUST be able
>  to identify a mobile node, using its MN-Identifier.  This identifier
>  MUST be stable across the Proxy Mobile IPv6 domain and the entities
>  must be able to use this identifier in the signaling messages."
> 
> We can add a line on the uniqueness requirement to this.

I'd recommend explicitly pointing out the differences between MN
identifier and user/account identifier -- I've understood that this
distinction has not been obvious in some other SDOs that are planning
to use this document (even when they explicitly support using the
same user identity from multiple hosts). And it may not be obvious
to e.g. enterprises wanting to use this with WLAN switches.

> > I couldn't find text saying whether the MAG decrements the Hop
> > Limit field or not (for packets it forward to the LMA, from the
> > LMA, or between directly connected nodes if EnableMAGLocalrouting
> > is enabled). (I'm not sure whether LMA behavior is specified,
> > either?)
> 
> For local routing or for reverse tunneling, the standard IP
> forwarding or tunneling semantics apply. The MIP functions are not
> in the switching path. I dont think, we can really specify any thing
> related to forwarding behavior.

I'm not quite sure I understand. Certainly *some* document (either
this one, or one of its normative references) needs to say when the
Hop Limit is decremented and when not? (And if it's one of the
normative references, at least a pointer would be very helpful
here.)

<snip>

> > The statement "This specification [...] does not support
> > Shared-Prefix model" seems false, as Appendix B specifies how to
> > support it.  (And given that both LMA and MAG require code changes
> > to support it in interoperable fashion, I don't quite see how this
> > appendix could be called non-normative, either.) I'd suggest
> > moving the specification of Shared-Prefix model to a separate
> > document.
> > 
> 
> Text specified in Appendex section should be just informative and
> an implemention claiming compliance to this spec, need not implement
> this part. Its purely informational purposes and I dont know if this
> gets any validity beyond that. A future spec can support this
> configuration and define the specification and this approach may
> provide some hints for that spec and thats all to it.

The appendix contains technical specification text (which describes
how some node should behave to achieve interoperability); whether
it's a mandatory or optional feature doesn't really change
the situation.

<snip>
> > Section 4 would have been lot easier to understand if it had said
> > in the beginning that PBUs don't have the Home Address destination
> > option (and PBAs don't have the Type 2 RH with home address).
> > 
> 
> hmm.... we chose the term PBU/PBA for the messages and it has
> its own format and the rules on what options are carried in these
> messages. I wonder if that is not an indication that it may not have
> the traditional MIP6 PBU elements. 

It was not obvious (at least to me), so adding a sentence or two
to beginning of Section 4 would probably help.

Best regards,
Pasi

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Narayanan, Vidya" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Sri Gundavelli" <[email-masked]>
Cc: "Pasi Eronen" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 02:52:38 -0700

Jari, Pasi, 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, March 27, 2008 2:02 AM
> To: Sri Gundavelli
> Cc: 'Pasi Eronen'; [email-masked]; 
> [email-masked]; 
> [email-masked]
> Subject: Re: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
> 
> Sri,
> 
> > The base spec definition allows a single prefix to be assigned to a 
> > given interface. Extending this to support multiple prefix 
> assignment 
> > is not an issue. But, attempting to cover that in this 
> document would 
> > be bit extreme from the specification point of view and 
> specially when 
> > we add multi-homing to the mix. We suggest doing this in an 
> extension 
> > document and that will have no impact on this 
> specification. To ensure 
> > we can extend this and with minimal changes, we can modify the HNP 
> > option and provide the container for carrying multiple 
> prefixes. The 
> > subsequent spec that the authors will work will address this issue.
> >   
> After considering this issue again now that Pasi brought it 
> up, I think we need to add the support now.
> 

I'm not sure I see the need to have this in the base spec at this time.
We did discuss this in the WG and decide that as long as the protocol is
extensible to support multiple prefixes, that is sufficient at this
time.  So, this is not a new issue that the WG did not consider.  I
don't see a substantial technical argument here that would make us
reconsider this decision.  

I agree with Sri here that it will be a rather non-trivial exercise to
add this to the base spec, given the implications of multiple interfaces
and also considerations of NEMO support we may want to think about.  We
would have to do the due diligence to ensure that we specify the
ingress/egress prefixes and the logic for multiple prefixes over a
single interface vs. different interfaces of the same host, etc.
correctly.  I don't think making the base spec bulkier in this aspect is
a good idea.  I think keeping it as an extension is good both from a
progress and specification standpoint. 

Regards,
Vidya

> Jari

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 15:55:45 -0700

Hi Pasi, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 27, 2008 1:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Hi Sri,
> 
> Thanks for a quick response. Please see inline.
> 
> <snip>
> 
> > > The specification seems to assume that MN has just _the_ 
> link-local 
> > > address. This restriction is not present in the IPv6 Addressing 
> > > Architecture (or many common link layers for IPv6, such 
> as 802.11), 
> > > and might not be true in e.g. some SEND configurations. Thus, it 
> > > seems enabling Proxy Mobile IPv6 here could break 
> functionality that 
> > > would work without it? At the very least, the document should 
> > > explain what happens if the client (not knowing that Proxy Mobile 
> > > IPv6 is in use) configures more than one link-local address.
> > > 
> > 
> > The same comment as above. As Jari pointed out, the idea of 
> carrying 
> > the interface-identifier is to ensure there is no address 
> collision, 
> > when a DNAv6 enabled mobile node after handoff skips the 
> DAD procedure 
> > on the link-local address. In the SDO deployments where 
> this protocol 
> > is extected to be deployed, there is context transfer mechanims in 
> > place (such as R4 interface in WiMAX) and the serving MAG 
> would know 
> > the link-local address of the mobile on the link and so address 
> > collision is not an issue. However, for completeness, we went ahead 
> > and also defined mechanisms to store this identifier in the 
> MN's BCE 
> > on the LMA. We assume there is a single link-local address 
> identifier.
> > 
> > All though, extending the link-local address option to support 
> > multiple addresses and fixing the related text is not a a 
> big deal, I 
> > suggest we address the above two issues in the new spec.  
> We can post 
> > a companion document on this topic. But, solving this here 
> would add 
> > to the document size. (On a lighter note, people are expecting this 
> > document to be as readable as a Harry Potter Novel and expect to 
> > understand every bit in one shot and when remembering it took few 
> > iterations for me to understand any of the base MIP specs 
> :)). So, I 
> > suggest we handle the above two items of mutiple prefix 
> assignment and 
> > multiple link-local address configuration in a new document.
> 
> One of the environments described in NETLMM goals document 
> (RFC 4831) is WLAN switches. In this environment, the client 
> may not be aware that Proxy Mobile IPv6 is being used, and 

The client (rather, MN) is never supposed to be aware that PMIPv6 is
being used on any link - at least, that is a fundamental goal of this
protocol. 

> may attempt to configure multiple link-local addresses (which 
> is a perfectly fine thing to do in WLAN).
> 

Sure, but, it is worth noting that this specification only supports the
prefix-per-interface model; shared prefixes on a link are not supported
here.  That said, in order to use the protocol in WLAN-like
environments, one either has to use VLANs or run a point-to-point
encapsulation on top of it.  

AFAIK, the goals document mentions WLAN switches as an analogy to
proprietary techonologies in the introduction and nowhere else.  I don't
think we are catering to the WLAN market at this point, with the base
spec (not in the traditional sense of WLAN anyway). 

> Given the goal of working with unmodified MNs, at the very 
> least the document needs to describe what happens in this 
> case. (I'm not quite sure what exactly does happen, though.)
> 

Given the above, I don't know if there is anything that needs to be
described here.  If it is not already clear, we can clarify that the
scope is limited to point-to-point link models.  

> > > The specification is vague on what entity the MN-Identifier 
> > > identifies, or is required to identify. Section 6.6 
> suggests that it 
> > > could correspond to Chargeable-User-Identity RADIUS 
> attribute -- but 
> > > that attribute does not identify a node, it identifies a user 
> > > account that could be used from multiple nodes simultaneously.
> > > (Some deployments may of course prohibit using the same 
> user account 
> > > from multiple nodes, but in other cases, it's common:
> > > consider an enterprise user with two laptops, but just a 
> single user 
> > > account.)  The spec needs to say what the uniqueness requirements 
> > > for MN-Identifier are: in particular, is it OK to have 
> multiple MNs, 
> > > connecting via the same MAGs/LMAs, with the same MN-Identifier?  
> > > (And if this is OK, perhaps the name "MN-Identifier" should be 
> > > changed.)
> > > 
> > 
> > Section 6.6 talks about the identifiers used for access 
> authentication 
> > (fast reauth ..etc) and the relation to the MN-Identifier. There is 
> > only one identifier that the mobility entities use in the signaling 
> > messages for identifying  a mobile node and it is the MN-Identifier.
> > However, there are multiple ways in which a MAG can discover this 
> > identifier and one mechanism is the use of CUI.
> > 
> > We require the MN-Identifier to be unique within a Proxy 
> Mobile IPv6 
> > domain. The below text,
> > 
> > "All the network entities in a Proxy Mobile IPv6 domain 
> MUST be able  
> > to identify a mobile node, using its MN-Identifier.  This 
> identifier  
> > MUST be stable across the Proxy Mobile IPv6 domain and the 
> entities  
> > must be able to use this identifier in the signaling messages."
> > 
> > We can add a line on the uniqueness requirement to this.
> 
> I'd recommend explicitly pointing out the differences between 
> MN identifier and user/account identifier -- I've understood 
> that this distinction has not been obvious in some other SDOs 
> that are planning to use this document (even when they 
> explicitly support using the same user identity from multiple 
> hosts). And it may not be obvious to e.g. enterprises wanting 
> to use this with WLAN switches.
> 

This distinction is not appropriate for this document.  In the world of
IP mobility (at least at the IETF), we have been using the term "MN ID"
and the reference (RFC4283) describes what it is.  This document
explains how it is used in the context of PMIP.  CUI is used as an
example of how the network might consider extracting an appropriate MN
ID.  It doesn't reflect anything beyond that.  To explain how an MN ID
is different from a user/account ID seems to be in the same boat of
"this document is about apples; let's describe how apples differ from
oranges, even though oranges have nothing to do with this document" :) 

Any assumptions the document is making about MN ID must be clear, as
Jari stated.  But, I don't believe the assumptions include
differentiation along the lines you suggest.  If you think the
assumptions themselves are unclear, please point that out and we can
work on better text. 

> > > I couldn't find text saying whether the MAG decrements 
> the Hop Limit 
> > > field or not (for packets it forward to the LMA, from the LMA, or 
> > > between directly connected nodes if EnableMAGLocalrouting is 
> > > enabled). (I'm not sure whether LMA behavior is specified,
> > > either?)
> > 
> > For local routing or for reverse tunneling, the standard IP 
> forwarding 
> > or tunneling semantics apply. The MIP functions are not in the 
> > switching path. I dont think, we can really specify any 
> thing related 
> > to forwarding behavior.
> 
> I'm not quite sure I understand. Certainly *some* document 
> (either this one, or one of its normative references) needs 
> to say when the Hop Limit is decremented and when not? (And 
> if it's one of the normative references, at least a pointer 
> would be very helpful
> here.)
> 

Yes, RFC2473 (a normative reference to this document) describes how IPv6
tunnel hop limits must be used.  We are not specifically describing any
tunneling behavior here (and we shouldn't).  All tunneling references in
this doucment should point to RFC2473 - if we have missed that
somewhere, please point that out and we'll fix it. 

Thanks,
Vidya

> <snip>
> 
> > > The statement "This specification [...] does not support 
> > > Shared-Prefix model" seems false, as Appendix B specifies how to 
> > > support it.  (And given that both LMA and MAG require 
> code changes 
> > > to support it in interoperable fashion, I don't quite see 
> how this 
> > > appendix could be called non-normative, either.) I'd 
> suggest moving 
> > > the specification of Shared-Prefix model to a separate document.
> > > 
> > 
> > Text specified in Appendex section should be just 
> informative and an 
> > implemention claiming compliance to this spec, need not 
> implement this 
> > part. Its purely informational purposes and I dont know if 
> this gets 
> > any validity beyond that. A future spec can support this 
> configuration 
> > and define the specification and this approach may provide 
> some hints 
> > for that spec and thats all to it.
> 
> The appendix contains technical specification text (which 
> describes how some node should behave to achieve 
> interoperability); whether it's a mandatory or optional 
> feature doesn't really change the situation.
> 
> <snip>
> > > Section 4 would have been lot easier to understand if it 
> had said in 
> > > the beginning that PBUs don't have the Home Address destination 
> > > option (and PBAs don't have the Type 2 RH with home address).
> > > 
> > 
> > hmm.... we chose the term PBU/PBA for the messages and it 
> has its own 
> > format and the rules on what options are carried in these 
> messages. I 
> > wonder if that is not an indication that it may not have the 
> > traditional MIP6 PBU elements.
> 
> It was not obvious (at least to me), so adding a sentence or 
> two to beginning of Section 4 would probably help.
> 
> Best regards,
> Pasi
> 

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Sri Gundavelli" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 16:40:36 -0700

Hi Pasi,

Please see inline. Thanks !

On Thu, 27 Mar 2008, [email-masked] wrote:

> Hi Sri,
>
> Thanks for a quick response. Please see inline.
>
> <snip>
>
>>> The specification seems to assume that MN has just _the_
>>> link-local address. This restriction is not present in the IPv6
>>> Addressing Architecture (or many common link layers for IPv6, such
>>> as 802.11), and might not be true in e.g. some SEND
>>> configurations. Thus, it seems enabling Proxy Mobile IPv6 here
>>> could break functionality that would work without it? At the very
>>> least, the document should explain what happens if the client (not
>>> knowing that Proxy Mobile IPv6 is in use) configures more than one
>>> link-local address.
>>>
>>
>> The same comment as above. As Jari pointed out, the idea of carrying
>> the interface-identifier is to ensure there is no address collision,
>> when a DNAv6 enabled mobile node after handoff skips the DAD
>> procedure on the link-local address. In the SDO deployments where
>> this protocol is extected to be deployed, there is context transfer
>> mechanims in place (such as R4 interface in WiMAX) and the serving
>> MAG would know the link-local address of the mobile on the link and
>> so address collision is not an issue. However, for completeness, we
>> went ahead and also defined mechanisms to store this identifier in
>> the MN's BCE on the LMA. We assume there is a single link-local
>> address identifier.
>>
>> All though, extending the link-local address option to support
>> multiple addresses and fixing the related text is not a a big deal,
>> I suggest we address the above two issues in the new spec.  We can
>> post a companion document on this topic. But, solving this here
>> would add to the document size. (On a lighter note, people are
>> expecting this document to be as readable as a Harry Potter Novel
>> and expect to understand every bit in one shot and when remembering
>> it took few iterations for me to understand any of the base MIP
>> specs :)). So, I suggest we handle the above two items of mutiple
>> prefix assignment and multiple link-local address configuration in a
>> new document.
>
> One of the environments described in NETLMM goals document (RFC 4831)
> is WLAN switches. In this environment, the client may not be aware
> that Proxy Mobile IPv6 is being used, and may attempt to configure
> multiple link-local addresses (which is a perfectly fine thing to do
> in WLAN).
>
> Given the goal of working with unmodified MNs, at the very least the
> document needs to describe what happens in this case. (I'm not quite
> sure what exactly does happen, though.)
>

W.r.t to home network prefix, the LMA can only send one prefix. So, the 
MAG should not be hosting mutiple prefixes on any of the access link and 
specifically the prefixes that are learnt thru PMIP signaling. Should not 
break any thing, but, if we want to support it, we have fix the text in 
some places and specially in multi-homing rules and also extend the
HNP option. Some processing rules will change.

On the multiplicity of link-local address configuration, I expect
deployments to use Context Transfer schemes and that would move the
whole link to a new MAG and so should not notice any changes w.r.t
Def-Router address etc. Or, allow a fixes link-local address(es) to
be configured on all MAG's MN-AR interfaces and assuming there is
no SEND. But, if both these approaches are not in place, with the
current text, there is a possibility of collision. We can extend
the option to carry multiple addresses and store it in MN's BCE.

>>> The specification is vague on what entity the MN-Identifier
>>> identifies, or is required to identify. Section 6.6 suggests that
>>> it could correspond to Chargeable-User-Identity RADIUS attribute --
>>> but that attribute does not identify a node, it identifies a user
>>> account that could be used from multiple nodes simultaneously.
>>> (Some deployments may of course prohibit using the same user
>>> account from multiple nodes, but in other cases, it's common:
>>> consider an enterprise user with two laptops, but just a single
>>> user account.)  The spec needs to say what the uniqueness
>>> requirements for MN-Identifier are: in particular, is it OK to have
>>> multiple MNs, connecting via the same MAGs/LMAs, with the same
>>> MN-Identifier?  (And if this is OK, perhaps the name
>>> "MN-Identifier" should be changed.)
>>>
>>
>> Section 6.6 talks about the identifiers used for access authentication
>> (fast reauth ..etc) and the relation to the MN-Identifier. There is
>> only one identifier that the mobility entities use in the signaling
>> messages for identifying  a mobile node and it is the MN-Identifier.
>> However, there are multiple ways in which a MAG can discover this
>> identifier and one mechanism is the use of CUI.
>>
>> We require the MN-Identifier to be unique within a Proxy Mobile IPv6
>> domain. The below text,
>>
>> "All the network entities in a Proxy Mobile IPv6 domain MUST be able
>>  to identify a mobile node, using its MN-Identifier.  This identifier
>>  MUST be stable across the Proxy Mobile IPv6 domain and the entities
>>  must be able to use this identifier in the signaling messages."
>>
>> We can add a line on the uniqueness requirement to this.
>
> I'd recommend explicitly pointing out the differences between MN
> identifier and user/account identifier -- I've understood that this
> distinction has not been obvious in some other SDOs that are planning
> to use this document (even when they explicitly support using the
> same user identity from multiple hosts). And it may not be obvious
> to e.g. enterprises wanting to use this with WLAN switches.
>

Sure. Will add this to Section 6.6.

>>> I couldn't find text saying whether the MAG decrements the Hop
>>> Limit field or not (for packets it forward to the LMA, from the
>>> LMA, or between directly connected nodes if EnableMAGLocalrouting
>>> is enabled). (I'm not sure whether LMA behavior is specified,
>>> either?)
>>
>> For local routing or for reverse tunneling, the standard IP
>> forwarding or tunneling semantics apply. The MIP functions are not
>> in the switching path. I dont think, we can really specify any thing
>> related to forwarding behavior.
>
> I'm not quite sure I understand. Certainly *some* document (either
> this one, or one of its normative references) needs to say when the
> Hop Limit is decremented and when not? (And if it's one of the
> normative references, at least a pointer would be very helpful
> here.)
>

I was trying to say, this is a general IP forwarding behavior and
nothing specific from PMIP perspective. But, as you suggested, we
should point to the specs that specify these forwarding aspects,
Ex: RFC-2473 for packet tunneling ... etc. Will add pointers.

> <snip>
>
>>> The statement "This specification [...] does not support
>>> Shared-Prefix model" seems false, as Appendix B specifies how to
>>> support it.  (And given that both LMA and MAG require code changes
>>> to support it in interoperable fashion, I don't quite see how this
>>> appendix could be called non-normative, either.) I'd suggest
>>> moving the specification of Shared-Prefix model to a separate
>>> document.
>>>
>>
>> Text specified in Appendex section should be just informative and
>> an implemention claiming compliance to this spec, need not implement
>> this part. Its purely informational purposes and I dont know if this
>> gets any validity beyond that. A future spec can support this
>> configuration and define the specification and this approach may
>> provide some hints for that spec and thats all to it.
>
> The appendix contains technical specification text (which describes
> how some node should behave to achieve interoperability); whether
> it's a mandatory or optional feature doesn't really change
> the situation.
>

Ok. We can take it out.

> <snip>
>>> Section 4 would have been lot easier to understand if it had said
>>> in the beginning that PBUs don't have the Home Address destination
>>> option (and PBAs don't have the Type 2 RH with home address).
>>>
>>
>> hmm.... we chose the term PBU/PBA for the messages and it has
>> its own format and the rules on what options are carried in these
>> messages. I wonder if that is not an indication that it may not have
>> the traditional MIP6 PBU elements.
>
> It was not obvious (at least to me), so adding a sentence or two
> to beginning of Section 4 would probably help.
>

Sure. Will do that.

Thanks again.

Regards
Sri

> Best regards,
> Pasi

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 1 Apr 2008 03:29:53 -0700

Vidya Narayanan wrote:

> > One of the environments described in NETLMM goals document 
> > (RFC 4831) is WLAN switches. In this environment, the client 
> > may not be aware that Proxy Mobile IPv6 is being used, and 
> 
> The client (rather, MN) is never supposed to be aware that PMIPv6
> is being used on any link - at least, that is a fundamental goal
> of this protocol.
> 
> > may attempt to configure multiple link-local addresses (which 
> > is a perfectly fine thing to do in WLAN).
> 
> Sure, but, it is worth noting that this specification only
> supports the prefix-per-interface model; shared prefixes on a
> link are not supported here.  That said, in order to use the
> protocol in WLAN-like environments, one either has to use VLANs
> or run a point-to-point encapsulation on top of it.

I was talking about the case where a single host attempts to
configure multiple link-local addresses on the WLAN -- this is
quite possible even point-to-point links.

> AFAIK, the goals document mentions WLAN switches as an analogy to
> proprietary techonologies in the introduction and nowhere else.
> I don't think we are catering to the WLAN market at this point,
> with the base spec (not in the traditional sense of WLAN anyway).

That's interesting; so do you think that this base spec doesn't
meet the goals in RFC 4831, or perhaps that the goals spec didn't
properly address the requirements of the WLAN switches?  Or just
that there isn't market interest for PMIPv6 from that industry?

> > Given the goal of working with unmodified MNs, at the very 
> > least the document needs to describe what happens in this 
> > case. (I'm not quite sure what exactly does happen, though.)
> 
> Given the above, I don't know if there is anything that needs to
> be described here.  If it is not already clear, we can clarify
> that the scope is limited to point-to-point link models.

As I said above, point-to-point links can have multiple link-local
addresses, too.

<snip>

> > I'd recommend explicitly pointing out the differences between 
> > MN identifier and user/account identifier -- I've understood 
> > that this distinction has not been obvious in some other SDOs 
> > that are planning to use this document (even when they 
> > explicitly support using the same user identity from multiple 
> > hosts). And it may not be obvious to e.g. enterprises wanting 
> > to use this with WLAN switches.
> 
> This distinction is not appropriate for this document.  In the world
> of IP mobility (at least at the IETF), we have been using the term
> "MN ID" and the reference (RFC4283) describes what it is.  This
> document explains how it is used in the context of PMIP.  CUI is
> used as an example of how the network might consider extracting an
> appropriate MN ID.  It doesn't reflect anything beyond that.  To
> explain how an MN ID is different from a user/account ID seems to be
> in the same boat of "this document is about apples; let's describe
> how apples differ from oranges, even though oranges have nothing to
> do with this document" :)

I disagree; I think distinction is important and especially
appropriate for this document. The document explicitly says that
the MN ID can be obtained during access authentication, and given
the fact that some other SDOs have already been confused by this
topic, it's important to explain that the identifier people usually
think about when talking about access authentication may not, in
all cases, be suitable for Proxy MIPv6 use.

<snip>
> > I'm not quite sure I understand. Certainly *some* document 
> > (either this one, or one of its normative references) needs 
> > to say when the Hop Limit is decremented and when not? (And 
> > if it's one of the normative references, at least a pointer 
> > would be very helpful
> > here.)
> > 
> 
> Yes, RFC2473 (a normative reference to this document) describes
> how IPv6 tunnel hop limits must be used.  We are not specifically
> describing any tunneling behavior here (and we shouldn't).  All
> tunneling references in this doucment should point to RFC2473 -
> if we have missed that somewhere, please point that out and we'll
> fix it.

Thanks for the explanation. I'd suggest adding explict text (along
the lines "tunnel encapsulation is performed as described in
[RFC2473]") to Sections 5.6.2 and 6.10.5. However, that RFC doesn't
explain the hop limit behavior when EnableMAGLocalRouting is true?

Best regards,
Pasi

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 1 Apr 2008 12:38:33 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 3:30 AM
> To: Narayanan, Vidya; [email-masked]; [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Vidya Narayanan wrote:
> 
> > > One of the environments described in NETLMM goals document (RFC 
> > > 4831) is WLAN switches. In this environment, the client 
> may not be 
> > > aware that Proxy Mobile IPv6 is being used, and
> > 
> > The client (rather, MN) is never supposed to be aware that 
> PMIPv6 is 
> > being used on any link - at least, that is a fundamental 
> goal of this 
> > protocol.
> > 
> > > may attempt to configure multiple link-local addresses 
> (which is a 
> > > perfectly fine thing to do in WLAN).
> > 
> > Sure, but, it is worth noting that this specification only supports 
> > the prefix-per-interface model; shared prefixes on a link are not 
> > supported here.  That said, in order to use the protocol in 
> WLAN-like 
> > environments, one either has to use VLANs or run a point-to-point 
> > encapsulation on top of it.
> 
> I was talking about the case where a single host attempts to 
> configure multiple link-local addresses on the WLAN -- this 
> is quite possible even point-to-point links.
> 

Are referring to configuration of multiple addresses on a single
interface or a single host over multiple interfaces?  

> > AFAIK, the goals document mentions WLAN switches as an analogy to 
> > proprietary techonologies in the introduction and nowhere else.
> > I don't think we are catering to the WLAN market at this 
> point, with 
> > the base spec (not in the traditional sense of WLAN anyway).
> 
> That's interesting; so do you think that this base spec 
> doesn't meet the goals in RFC 4831, or perhaps that the goals 
> spec didn't properly address the requirements of the WLAN 
> switches?  Or just that there isn't market interest for 
> PMIPv6 from that industry?
> 

No, I am saying that the goals document did not capture any targeted
markets or environments for this protocol.  In the introduction, it uses
an analogy of proprietary protocol deployment in the WLAN switches world
as an analogy of why we should be producing standards in the IETF - that
was probably a poor analogy, but, there is no "goal" in the document on
this protocol being developed for any specific environment.  

That said, I was talking about the fact that regular WLAN environments
use the shared subnet model and this protocol only supports the
point-to-point subnet model (where a prefix per MN interface is
assigned).  Hence, without a point-to-point encapsulation over WLAN,
this protocol will not apply to such environments. 

<snip>

> > 
> > This distinction is not appropriate for this document.  In 
> the world 
> > of IP mobility (at least at the IETF), we have been using 
> the term "MN 
> > ID" and the reference (RFC4283) describes what it is.  This 
> document 
> > explains how it is used in the context of PMIP.  CUI is used as an 
> > example of how the network might consider extracting an 
> appropriate MN 
> > ID.  It doesn't reflect anything beyond that.  To explain 
> how an MN ID 
> > is different from a user/account ID seems to be in the same boat of 
> > "this document is about apples; let's describe how apples 
> differ from 
> > oranges, even though oranges have nothing to do with this 
> document" :)
> 
> I disagree; I think distinction is important and especially 
> appropriate for this document. The document explicitly says 
> that the MN ID can be obtained during access authentication, 
> and given the fact that some other SDOs have already been 
> confused by this topic, it's important to explain that the 
> identifier people usually think about when talking about 
> access authentication may not, in all cases, be suitable for 
> Proxy MIPv6 use.
> 

We will never be aligned with terminology across all other SDOs that use
our protocols.  One means of obtaining the MN ID is during access
authentication.  One form of identity used in access authentication is
the NAI.  There may be other forms and any of those or something else
completely not tied to access authentication even can be used as the MN
ID.  The bottomline is that the MN ID is obtained via out-of-band
mechanisms and this protocol does not have procedures to obtain it.  I
don't see how we can exhaustively spell out the differences between the
MN ID and every other possible id that may be used to obtain the MN ID.
You have pointed out one such identity to distinguish from - the fact is
there are others and where do we stop? 

From the IETF's perspective, we can ensure we clearly state what the MN
ID is and any assumptions associated with it.  Unfortunately, we cannot
anticipate ensuing confusions in other SDOs and resolve all of those. 

> <snip>
> > > I'm not quite sure I understand. Certainly *some* 
> document (either 
> > > this one, or one of its normative references) needs to 
> say when the 
> > > Hop Limit is decremented and when not? (And if it's one of the 
> > > normative references, at least a pointer would be very helpful
> > > here.)
> > > 
> > 
> > Yes, RFC2473 (a normative reference to this document) describes how 
> > IPv6 tunnel hop limits must be used.  We are not specifically 
> > describing any tunneling behavior here (and we shouldn't).  All 
> > tunneling references in this doucment should point to 
> RFC2473 - if we 
> > have missed that somewhere, please point that out and we'll fix it.
> 
> Thanks for the explanation. I'd suggest adding explict text 
> (along the lines "tunnel encapsulation is performed as described in
> [RFC2473]") to Sections 5.6.2 and 6.10.5. 

Sure.  Sri, please include this in the document. 

>However, that RFC 
> doesn't explain the hop limit behavior when 
> EnableMAGLocalRouting is true?
> 

There is no tunneling when EnableMAGLocalRouting is true - the MAG just
acts as a router.  I don't see a need to define hop limit behavior for
routing in this document. 

Regards,
Vidya

> Best regards,
> Pasi

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 2 Apr 2008 03:53:24 -0700

Vidya Narayanan wrote:

> > > > may attempt to configure multiple link-local addresses (which
> > > > is a perfectly fine thing to do in WLAN).
> > > 
> > > Sure, but, it is worth noting that this specification only
> > > supports the prefix-per-interface model; shared prefixes on a
> > > link are not supported here.  That said, in order to use the
> > > protocol in WLAN-like environments, one either has to use VLANs
> > > or run a point-to-point encapsulation on top of it.
> > 
> > I was talking about the case where a single host attempts to 
> > configure multiple link-local addresses on the WLAN -- this 
> > is quite possible even point-to-point links.
> 
> Are referring to configuration of multiple addresses on a single
> interface or a single host over multiple interfaces?  

I'm referring to configuration of multiple addresses on a single
interface (with point-to-point WLAN using e.g. VLANs).

<snip>
> > I disagree; I think distinction is important and especially 
> > appropriate for this document. The document explicitly says 
> > that the MN ID can be obtained during access authentication, 
> > and given the fact that some other SDOs have already been 
> > confused by this topic, it's important to explain that the 
> > identifier people usually think about when talking about 
> > access authentication may not, in all cases, be suitable for 
> > Proxy MIPv6 use.
> 
> We will never be aligned with terminology across all other SDOs that
> use our protocols.  One means of obtaining the MN ID is during
> access authentication.  One form of identity used in access
> authentication is the NAI.  There may be other forms and any of
> those or something else completely not tied to access authentication
> even can be used as the MN ID.  The bottomline is that the MN ID is
> obtained via out-of-band mechanisms and this protocol does not have
> procedures to obtain it.  I don't see how we can exhaustively spell
> out the differences between the MN ID and every other possible id
> that may be used to obtain the MN ID.  You have pointed out one such
> identity to distinguish from - the fact is there are others and
> where do we stop?
> 
> From the IETF's perspective, we can ensure we clearly state what the
> MN ID is and any assumptions associated with it.  Unfortunately, we
> cannot anticipate ensuing confusions in other SDOs and resolve all
> of those.

My comment was that the current text does *not*, in my opinion,
sufficiently clearly state the requirements. Adding a couple of
sentences comparing this with access authentication identity
would go a long way in making it understandable to the document's
readers (not just the authors, or people receiving this email).

<snip>
> > However, that RFC doesn't explain the hop limit behavior when
> > EnableMAGLocalRouting is true?
> 
> There is no tunneling when EnableMAGLocalRouting is true - the MAG
> just acts as a router.  I don't see a need to define hop limit
> behavior for routing in this document.

Ok, I'd assume that the normal semantics (MAG decrements Hop Limit
by one) would apply. 

(BTW, this means that whether EnableMAGLocalRouting is enabled or not
is visible to the MNs -- doing a traceroute with EnableMAGLocalRouting
set to true would show one intermediate hop (MAG); otherwise, it would
show three intermediate hops (MAG, LMA, MAG again)).

Best regards,
Pasi
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm