Subject: [MEXT] new dsmip draft

From: Julien Laganier <[email-masked]>
Date: Thu, 6 Mar 2008 10:07:23 +0100

Folks, I'm forwarding an email from Pasi regarding remaining issues with 
the last DSMIP draft. See below.

----------  Forwarded Message  ----------

Subject: RE: new dsmip draft
Date: Wednesday 05 March 2008
From: [email-masked]
To: [email-masked]

Some remaining issues:

Section 2.1, QNAME for SRV lookups is *still* wrong.

Section 4.1, identifying the tunneling format (Sebastien
Decugis's comment on mailing list 2008-02-29)

Section 4.1, does not discuss all tunneling formats.

Section 4.1, TLV type value "3" (IPsec), not clear whether
this is ESP or AH (can't detect from packet!).

Section 5, text about switching to port 4500 needs improvement
(so that it's clear at what point switching is done). Also,
I'm not sure if it matters whether the MN is in IPv4 or IPv6
network when the IKE_SA is created -- we need to handle 
movements either way later.

Section 5, "When located in an IPv4-only network, the mobile node 
MUST NOT negotiate a security association that uses the following 
tunnel formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6)"
IPv4/IPvx (without IPsec) is not really a security association;
and if it must not be negotiated, then the concept of "forcing"
UDP encapsulation (in rest of the document) needs to be removed.
And "MUST NOT negotiate IPv4/ESP/IPvx" is not as simple as that
(it's not really negotiated, but set based on result of NAT 
detection).

Section 5.1, I suggested showing packets (both before and after
IPsec processing) would improve readability, but this is not
absolutely required.

The discussion about care-of address mismatch between DSMIPv6
module and IPsec module suggests (incorrectly) that the issue
is just NAT allocating different ports -- like we discussed
earlier, it can also occur later.

Idnits has some errors which look like real errors (not false
positives) to me.

The draft specifies IP-in-something tunneling, but does not 
mention words like "fragment", "MTU", or "ECN" (or have any
references which would discuss those) -- that's 100% sure way 
to get DISCUSSes from transport ADs. (But if you prefer, you
can wait for the DISCUSSes, too...)

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 6 Mar 2008 11:56:06 +0100

> can wait for the DISCUSSes, too...)

FWIW the PMIPv6 draft has received such DISCUSSes after Alison Mankin's 
tsvdir review. I copy the relevant part of her review below for your 
convenience.

--julien

------------------------------------------------------------------------

1. MTU - the mobile node (MN) receives its traffic through a tunnel.
   The local mobile anchor to mobile access gateway encapsulations are
   varied (Section 6.10.2: v6-in-v6, v6-in-v4, v6-in-v4-udp).  While 
   tunnels lead to a generic problem for MTUs (RFC 4459), the problems 
   are intensified in this design because the MN's moves may result in
   successive differently encapsulated tunnels, at short enough
   intervals that transport sessions survive across them and end up
   transmitting data with problematic MTUs. 

   Please discuss the MTU issue.  Suggestion - recommend the state of
   the art initial MTU detection, PLMTUD (RFC 4821), which also allows
   connections that can't start new probes to learn of MTU changes from
   other connections with more recent probe information.

2. Tunnel and Explicit Congestion Notification (ECN) - with transport 
traffic that uses ECN (RFC 3168) - most transports - provision is made 
for tunnels by transferring ECN information between the outer and inner 
IP(v#) headers at the tunnel endpoints. Something like this procedure 
is also provided for maintaining the ECN signal through an MPLS 
network. I suggest that this document should call for applying the ECN 
for tunnels procedure from RFC 3168 on behalf of the MN and its 
correspondent nodes. More motivation: far from having no congestion in 
the highly engineered wireless/wireline deployments, measurements often 
find serious pressure on resources such as the wireline backhaul. Good 
to make sure the congestion avoidance system is well in place. Please 
get ECN into the local mobility anchor to mobility access gateway 
tunnel if possible Question: it's clear that forming a new tunnel 
 requires ECN to zero out and start over and only the local mobility 
anchor knows this. Doable?
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 11 Mar 2008 05:09:58 +1000

> Section 2.1, QNAME for SRV lookups is *still* wrong.

=> I don't know how this is still not changed, my bad.

I think all of the following comments are new except for one that we agreed
to add with AD comments. I hope we're not requiring another rev before AD
comments because none of the comments below require significant technical
changes. 

Thanks,
Hesham

 > > -----Original Message-----
 > > From: julien laganier [mailto:[email-masked]] On 
 > > Behalf Of ext Julien Laganier
 > > Sent: 05 March, 2008 12:00
 > > To: Eronen Pasi (Nokia-NRC/Helsinki)
 > > Cc: [email-masked]; marcelo bagnulo braun
 > > Subject: new dsmip draft
 > > 
 > > Pasi, Hesham,
 > > 
 > > Have all the outstanding issues been solved? If not we could 
 > > use some of 
 > > the next meeting time to finish resolving them.
 > > 
 > > Best,
 > > 
 > > --julien
 > > 
 >

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Mar 2008 11:11:23 +0100

Hi Hesham,

On Monday 10 March 2008, Hesham Soliman wrote:
> I think all of the following comments are new except for one that we
> agreed to add with AD comments. I hope we're not requiring another
> rev before AD comments because none of the comments below require
> significant technical changes.

Since it's almost sure that the draft in its current form will get 
DISCUSSes from TSV DIR or ADs, may I suggest you address them now in a 
revision of the I-D so that we avoid couple of DISCUSSes in IESG which 
is never a bad thing. 

And as part of that update may I also suggest you also address other 
comments from Pasi's (below) before they get an opportunity to morph 
into SEC AD DISCUSSes ;-)

Thanks. 

Best Regards,

--julien

one more round trip fixing them later. As part of the current