Subject: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 4 (last)

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Jan 2008 15:46:10 +0200

This is the last batch of my comments. My next step is to look at some
of the discussion resulting from my comments and respond to the e-mails.
I will also send a summary.

I have set the document state in tracker to Revised ID Needed, and
will expect a revision as soon as we work out what the correct
fix is to the issues that were identified (or agree that it was
not an issue after all).

Technical:

> 7.3. IPv6 Host Protocol Parameters
>    Lower Default-Router List Cache Time-out:

Which specific behaviour in the *host* implementation this
section asks to do? It is obvious that the router side
lifetime value can be adjusted to a lower one, is that
what you are recommending? In that case it is in a wrong
section. If not, what are you recommending?

>     Access Technology Type (Acc Tech)
> 
> ...
> 
>         0x00: Reserved
>         0x01: Virtual
>         0x02: PPP
>         0x02: 802.3 (Ethernet)
>         0x03: 802.11a
>         0x04: 802.11b
>         0x05: 802.11g
>         0x06: 802.16e

The access type is used in the decision of whether a particular
movement is a handoff or a new interface from the same NAI. It
is unclear to me whether 11a/b/g differences should be visible
in such a case; in my experience a single card supports these
different types transparently and with the same MAC address.

Note that the contents of this attribute should be very different
if we were using for accounting purposes (such as in certain
RADIUS attribute); then we'd want as much detail as possible. Now
we would merely want to get exactly the right granularity of
information.

>      Interface Identifier
> 
>          A variable length field containing the mobile node's interface
>          identifier.

This is underspecified. Please specify what the contents should be
for each supported interface type.

> 11. Security Considerations

Well written and complete. Thanks.

Editorial:

>    If the mobile node is IPv4 enabled and if the network permits, it
>    will be able to obtain the IPv4 address configuration for the
>    connected interface by using DHCP [RFC-2131].  The details related to
>    IPv4 support is specified in the companion document [ID-IPV4-PMIP6].

I would prefer to write this as "If the mobile node is IPv4 enabled and
if the network permits, it will be able to obtain an IPv4 address and
configuration as  specified in the companion document [ID-IPV4-PMIP6]."
(Shorter, less duplication)

> The Router Lifetime field in the received
>    Router Advertisement defines the life of this entry.

s/life/lifetime/

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 Jan 2008 09:40:20 -0800 (PST)

Hi Jari,

Please see inline ..

Thanks
Sri

> section. If not, what are you recommending?

This can be in the MAG section as the control is over the RA
fields or can be taken out, as it is just per 2461. I think this
comment came from John Zhao some time back and some how I missed
this comment. Will move it from this section.

> different types transparently and with the same MAC address.

We are currently using the IID and HI as the main hints for
handoff/new attachment decisions. The use of ATT is just an
additional hint for the case "HI=Unknown", "IID=0" and for
the LMA to wait for dereg or just assign a new prefix.

This really depends on how the drivers are written on the host
for supporting such cards. If the MAG can present a single
type when using any of these bands, and the host as well
presents a single interface in its stack, sure, we dont need
this granularity. May be we can define a composite type,
802.11a/b/g. The WiFI card in my system shows up as "3945ABG Network
connection. There are some cards that support integrated WiFI and
cellular interfaces. Ex: Vendor "option.com". The way I see it is
as if there are multiple interfaces on the host and just that the radio
is shared. There we cant consolidate. May be we should define a
new type 802.11a/b/g ???

> we would merely want to get exactly the right granularity of

Sure.
Probably the ATT type will be used for other purposes as well, once
its there.

> for each supported interface type.

Need some help here. Should we talk about IEEE MAC-48, EUI-48
or EUI-64 formats ?  The identifier as long as it is unique
and fixed for a given interface, its transparent to the protocol
operation. Wondering, if we should go into the details. Also,
just checked the LLA option format in 4068 and does not seem to
talk about the formats. We can discuss about the formats, if
you think that is required.

> (Shorter, less duplication)

Ok.

>>    Router Advertisement defines the life of this entry.

Ok.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 16:46:52 +0200

Sri,

> this comment. Will move it from this section.

OK, good.

> the LMA to wait for dereg or just assign a new prefix.

Hmm. This seems wrong. First of all, I would expect ATT to
be used even when IIDs are supplied, because that makes
certain that two IIDs from different link technologies do
not collide, even if they happen to be of the same length.

> is shared. There we cant consolidate. May be we should define a

I think you should consolidate the entries, and not have
more than the ones that you know you truly need (you can
get more by expert review).

Note that card != interface in all cases.

> Probably the ATT type will be used for other purposes as well, once

The important thing is to get it to working for our purpose, which
in this case is the multihoming algorithm. It really should not be
built to be useful for other things.

> you think that is required.

Perhaps I assumed that the 4068bis would be using the same
format as in ND documents, so that is why I did not pay attention
to the same issue there. In any case, RFC 4861 says this
about its link layer address option:

The content and format of this field (including
byte and bit ordering) is expected to be specified
in specific documents that describe how IPv6
operates over different link layers. For instance,
[IPv6-ETHER].

You have to specify what the format is. How would implementors
otherwise know in which order I put the bytes, etc? You could though
say that the same format is employed as in RFC 4861 field "Link-Layer
Address" in Section 4.6...

Jari

---

From: Nicolas Dichtel <[email-masked]>
Date: Mon, 14 Jan 2008 16:08:40 +0100

Hi all,

>>     Access Technology Type (Acc Tech)
Maybe this was already noticed, but PPP and 802.3 have the same value (0x02).
Is this intentional ? If yes, can I have more details ?

Regards,
Nicolas

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 19:57:38 +0200

I'm summarizing what we have here: Overall, the spec is in relatively
good shape. There were a number of technical and editorial issues,
things that we need to fix or we would otherwise get problems in the
IESG and and Last Call phases -- but no show stoppers as  far as I can see.

Some more work is needed, though. We need to revise the  spec in order
to address each issue and/or determine that  it is not an issue after
all. This is going to need help from  the group and the authors, and I'm
very happy that people have already responded so promptly.

I think a good goal for us would be to get these issues resolved and a
new spec out before the end of this month, so that we can start an IETF
Last Call.

Some of the technical issues that were brought up include:

- Need for more explicit authorization rules on what MAGs can do, and
for what mobile nodes. This should be easy.

- Clarification for the role of the MN-HoA concept, which is very
different from a similar concept in RFC 3775.

- Cleaning-up/reorganizing the mobile node's identity rules and concepts
so that it becomes simple and well defined. This will require some
thinking, and this is the issue which is least clear in my head.
However, I'm not looking for a fundamental change. I expect a different
way of organizing the identification fields would probably give us what
we want.

- Potential changes/simplifications with respect to DNA and link local
address usage. We will need Suresh' help here to understand where DNA is
going and whether a change would be possible or needed.

- Some of the processing steps need to be reordered to make it clear
that MH-specific behaviour happens after messages have correctly been
verified by IPsec.

- We need a better specification of what MAG does for incoming traffic
at the time when it has asked for binding to be removed.

- A number of clarifications to make it clear that host changes are not
needed. They are not, but some areas of the document could be clearer
about this.

- Clarity with respect to the changes this specification introduces to
some RFC 3775 behaviours (e.g. retransmission rules).

- A number of editorial and smaller technical issues that should be
straightforward to address.

I'm expecting a revised ID and will work with you to make sure the
revision does the right thing.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 13:41:12 -0800

> Is this intentional ? If yes, can I have more details ?

Thats a typo. Will be fixed.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 Jan 2008 00:31:48 -0800

Hi Jari,

inline .. 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, January 14, 2008 6:47 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD review of draft-ietf-netlmm-proxymip6, batch 4 (last)
> 
> Sri,
> 

Ok. Thanks. I missed that part about the IID collision across
access types. Will add this ATT check.

Ok.

> built to be useful for other things.

As mentioned above, Will add the ATT related checks.

> Address" in Section 4.6...

Will specify the formats. I see your point, about the ambiguity if
we dont specify the format.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 17 Jan 2008 16:46:10 +0100

Folks,

I have a question on the remaining access technology types:

>         0x07: CDMA2000 1xEV-DO Release 0
>         0x08: CDMA2000 1xEV-DO Revision A
>         0x09: CDMA2000 1xEV-DO Revision B
>         0x0a: 3GPP LTE

Why is the 3GPP access technology restricted to 3GPP Long Term Evolution 
(LTE)?

When PMIPv6 is used in the 3GPP Evolved Packet System (EPS, a.k.a. 
System Architecture Evolution) connectivity is not restricted to the 
EUTRAN (a.k.a LTE) radio access technology. 

Connectivity can also occur via older 3GPP access technologies such as 
UTRAN (the current 3G used in UMTS). Since the switch between different 
radio access technologies will be managed by the 3GPP system, including 
the user equipment (or MN in IETF terminology), AFAICS the different 
3GPP radio access technologies would/should not be visible to the IP 
layer, and thus to PMIPv6.

Thus, it seems to me that we should have simply defined:

>	0x0a: 3GPP

Along the same lines, I am also unclear whether or not differences 
betwen releases of CDMA2K should be visible at the IP layer and thus to 
PMIPv6. I don't know well enough CDMA2K to figure out -- For sure 
someone knows better :)

Cheers,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 09:07:41 -0800 (PST)

Hi Julien,

I think, we just define the registry and define the
values for the standard technologies such as WiFi
..etc and leave the 3GPP or CDMA specific types
definitions to the registry mgmt. We can let those
SDO's/domain experts register the correct values.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 17 Jan 2008 18:35:55 +0100

Hi Sri,

> SDO's/domain experts register the correct values.

All right, that makes sense. I understand you're going to specify that 
the policy of allocation in the Access Technology registry is First 
Come First Served, am I right?

--julien

> > Why is the 3GPP access technology restricted to 3GPP Long Term
> > Evolution (LTE)?
> >
> > System Architecture Evolution) connectivity is not restricted to
> > the EUTRAN (a.k.a LTE) radio access technology.
> >
> > Connectivity can also occur via older 3GPP access technologies such
> > as UTRAN (the current 3G used in UMTS). Since the switch between
> > different radio access technologies will be managed by the 3GPP
> > system, including the user equipment (or MN in IETF terminology),
> > AFAICS the different 3GPP radio access technologies would/should
> > not be visible to the IP layer, and thus to PMIPv6.
> >
> > betwen releases of CDMA2K should be visible at the IP layer and
> > thus to PMIPv6. I don't know well enough CDMA2K to figure out --
> > For sure someone knows better :)
> >
> > Cheers,
> >
> > --julien
> >
> >

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 10:29:41 -0800 (PST)

Hi Julien,

We specified the allocation per the "IANA Expert Review",
per Jari's recommendation. So, its not simple email that will
reserve an IANA type, but I guess the allocation is after a
review. I'm too familiar with this process.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 10:34:46 -0800 (PST)

> review. I'm too familiar with this process.

Typo. I'm *not* too familiar with this process rather :)

---

From: Julien Laganier <[email-masked]>
Date: Fri, 18 Jan 2008 11:41:15 +0100

Hi Sri,

On Thursday 17 January 2008, Sri Gundavelli wrote:
> > All right, that makes sense. I understand you're going to specify
> > that the policy of allocation in the Access Technology registry is
> > First Come First Served, am I right?
>
> Hi Julien,
>
> per Jari's recommendation.

I overlooked that in the draft, sorry. This is fine.

--julien