Subject: [MEXT] GRE support in DSMIPv6 - AD review

From: Hesham Soliman <[email-masked]>
Date: Wed, 14 Jan 2009 23:23:10 +1100

Folks, 

Part of Pasi's review for DSMIPv6 was a comment on the lack of specification
for GRE support in the spec. He said it was vastly under-specified, no
details on the tunnelling, setting of different parts of the GRE header
...etc. 

I suggested that we don't explicitly mention GRE in the spec but we keep the
TLV tunnelling format and reserve the numbers for NETLMM to specify exactly
how it will be used in a separate document. I think you would agree that
this is largely driven by NETLMM needs and we shouldn't specify the details
in MEXT. Pasi was ok with that.

Please express your opinion on this soon because Pasi's comments are the
last comments for the draft and I want to handle them by Monday at the
latest. 

Please avoid discussing the merits of GRE....etc, the question is:

Are there any objections to removing explicit references to GRE while
reserving the numbers in the TLV header for it to be specified clearly in
NETLMM?

Thanks,

Hesham

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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 14 Jan 2009 10:19:17 -0800

Hi Hesham,

I am fine with your proposal.

Gerardo

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hesham Soliman [[email-masked]]
Sent: Wednesday, January 14, 2009 4:23 AM
To: [email-masked]
Cc: Pasi Eronen
Subject: [MEXT] GRE support in DSMIPv6 - AD review

Folks,

Thanks,

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Jan 2009 12:27:55 -0600

Hi Hesham,

I don't see a need for specifying GRE tunnelling in the current spec.

But I am at a loss to understand what Netlmm is expected to do to specify
GRE tunnelling for DSMIP6. It is best to simply say that the use of GRE
tunnelling in the context of DSMIP6 may be specified separately and leave it
at that.

I am fine with your proposed recommendation with the caveat that you do not
even mention which WG or document specifies the details of GRE tunnelling.

-Raj

---

From: <[email-masked]>
Date: Thu, 15 Jan 2009 13:53:58 +0200

Hesham,

I would strongly suggest moving the whole TLV header text to the
separate GRE document.

In particular, if you assign a number for GRE in this document,
you either need to describe how it works here, or have a normative
reference to the NETLMM spec.

Best regards,
Pasi

> -----Original Message-----
> From: ext Hesham Soliman [mailto:[email-masked]] 
> Sent: 14 January, 2009 14:23
> To: [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: GRE support in DSMIPv6 - AD review
> 
> Folks, 
> 
> Part of Pasi's review for DSMIPv6 was a comment on the lack of
> specification for GRE support in the spec. He said it was vastly
> under-specified, no details on the tunnelling, setting of different
> parts of the GRE header ...etc.
> 
> I suggested that we don't explicitly mention GRE in the spec but we
> keep the TLV tunnelling format and reserve the numbers for NETLMM to
> specify exactly how it will be used in a separate document. I think
> you would agree that this is largely driven by NETLMM needs and we
> shouldn't specify the details in MEXT. Pasi was ok with that.
> 
> Please express your opinion on this soon because Pasi's comments are
> the last comments for the draft and I want to handle them by Monday
> at the latest.
> 
> Are there any objections to removing explicit references to GRE
> while reserving the numbers in the TLV header for it to be specified
> clearly in NETLMM?
> 
> Thanks,
> 
> Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 16 Jan 2009 00:24:53 +1100

> I would strongly suggest moving the whole TLV header text to the

=> Personally, as everyone on the list knows, I was always against including
this in the draft, I think it's a really bad idea, but obviously it's not my
decision. So let's see what people say. I do agree with this suggestion.

> reference to the NETLMM spec.

=> My suggestion below was not to assign any numbers in the draft. It was
simply to have the TLV header unassigned and let someone else request the
assignment and describe how it's used. My ideal preference is the one above
(remove it completely) but the suggestion below was a compromise to speed
things up. 

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 15 Jan 2009 13:37:39 +0000

I think what Pasi suggests makes sense and will make things easier for
whoever defines GRE support.

Not assigning a number for the TLV essentially means that the TLV
header for GRE is undefined and thus nothing needs to be said about
it. The whole thing can then be defined in a different spec as needed.

Regards
George

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 16 Jan 2009 00:51:12 +1100

> whoever defines GRE support.

=> So are you agreeing with removing the TLV completely or with simply
removing the assignment of the GRE? They're two different things.

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 15 Jan 2009 14:02:27 +0000

How are they different? Maybe I am missing something. The only type
value defined currently on the TLV is for GRE. If you remove the GRE
value, what is the TLV for?

George

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 16 Jan 2009 01:06:30 +1100

Pasi mentioned in the first paragraph that he " would strongly suggest
moving the whole TLV header text to the separate GRE document."

This is different from keeping the TLV header and removing the assignment of
GRE values. Two very different approaches. It's not clear to me which one
you are asking for.

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 15 Jan 2009 14:13:06 +0000

> moving the whole TLV header text to the separate GRE document."

GT> This makes sense to me.

> GRE values.

GT> I am still trying to understand what this means in practice. If
you keep the TLV header and remove the GRE assigned value then the
draft will NOT have any valid Type values for the TLV header. What is
an implementation supposed to do with that?

> Two very different approaches. It's not clear to me which one
> you are asking for.
>

GT> If you can clarify the above I will tell you :-)

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 16 Jan 2009 01:16:07 +1100

> an implementation supposed to do with that?

=> Absolutely nothing until a number is assigned in another spec.

> GT> If you can clarify the above I will tell you :-)

=> Hope this helps :)

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 15 Jan 2009 16:12:35 +0000

I would remove the TLV completely.
George

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 15 Jan 2009 08:56:37 -0800 (PST)

Hi Pasi,

The specified GRE type value in the TLV header identifies the
payload that follows. Wondering, what more needs to be specified.
As the GRE format is specified in the respective specification,
here the purpose of TLV is only payload classification, with a
reference to that spec. Will a clarification help ?

The GRE key exchange draft in NETLMM is about defining an option
for GRE key exchange. It does not focus on the transport. Its only
deals with the key negotiation. The IPv4 support document in NETLMM
also does not focus on GRE transport, it falls back to the DSMIP spec
with normative reference.

So, if this is about a simple clarification, probably it can be fixed
here ? Also, there were long discussion threads on this topic a year
back.

Regards
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 15 Jan 2009 11:13:36 -0600

I agree with the recommendation to moving the TLV header to a separate
document (if somene feels there is a need for it at all).

This spec is unneccesarily encumbered with the TLV header details and is
better off without it.

-Raj

---

From: <[email-masked]>
Date: Thu, 15 Jan 2009 19:44:29 +0200

Hi Sri,

Adding GRE support to Mobile IPv6 needs a bit more than
a pointer to the GRE spec. Quoting from the IESG ballot:

- There's no text describing how GRE tunneling is actually done;
  for example, how the various parts of GRE header are set/used in
  the context of Mobile IPv6, how that interacts with RFC 4877, etc.

Also, the whole 'T' bit is problematic; from the IESG ballot:

- Apparently the 'T' bit does means only that MN supports the 
  general TLV format; it may not support any of the specific TLV 
  types, such as GRE (and new ones may be defined in the future). 
  How this is supposed to work?

Best regards,
Pasi

> From: ext Sri Gundavelli [mailto:[email-masked]] 
> Sent: 15 January, 2009 18:57
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review
> 
> Hi Pasi,
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 15 Jan 2009 13:32:17 -0500

Hi Pasi, Hesham,

The TLV header was specified in the DS-MIPv6 document after rather a
long and acrimonious debate on the former MIP6 mailing list. There were
atleast two consensus calls that were run at that time. Anytime you have
a UDP header with IPv4/IPv6/GRE header following it, you need the TLV
header. At that time, there were folks arguing for using GRE
encapsulation with MIPv6 also. PMIPv6 IPv4 support was not the only
scenario for the TLV header. We are overturning that consensus now.
Maybe folks who were arguing for the TLV header with DS-MIPv6, are
either busy/not looked at this thread yet/or not on the MEXT mailing
list/etc.. :)

Moving the TLV header into a separate document at this point would
impact draft-ietf-netlmm-pmip6-ipv4-support. I don't think the TLV
header document can be standardized fast enough for
draft-ietf-netlmm-pmip6-ipv4-support to advance. One option would be to
move the TLV header and the text that describes how to negotiate it, to
either draft-ietf-netlmm-pmip6-ipv4-support or
draft-ietf-netlmm-grekey-option. 

My suggestion would be to leave the TLV header in the DS-MIPv6 document.
Have some text that says the following. If UDP encapsulation is used
with DS-MIPv6 port, there could be IPv4, IPv6, GRE or some other header
that might follow the UDP header. If there is anything other than the
IPv4 or IPv6 header, the TLV header would be required. The use of GRE or
some other protocol after the TLV header is not specified and is out of
scope in the DS-MIPv6 document.

Vijay 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, January 15, 2009 3:54 AM
> To: [email-masked]; [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 15 Jan 2009 13:37:26 -0500

Hi Pasi, 

>   How this is supposed to work?

I don't see an issue. Today we have three types. IPv4, IPv6 and GRE.
IPv4 and IPv6 can be used without having to negotiate anything or figure
out if the other end has support for IPv4 and IPv6. For GRE, I expect a
separate document that adds some sort of GRE encapsulation option to the
binding update (similar to what is specified in
draft-ietf-netlmm-grekey-option-02). For other types we might define in
the future, there would be some sort of mobility option in the binding
update that tells the HA what the mobile node wants to use when
negotiating the TLV header. 

Vijay

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 15 Jan 2009 11:58:00 -0800 (PST)

Hi Vijay,
  I am sure you are right on this historic note. My concern is that in the draft GRE occurs only once as a possible value in the type field. If we are going to keep it maybe some more text is needed.

Regards,

Behcet

________________________________
From: Vijay Devarapalli <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Cc: Jari Arkko <[email-masked]>
Sent: Thursday, January 15, 2009 12:32:17 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review

Hi Pasi, Hesham,

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jan 2009 21:12:26 +0100

Hi,

> scope in the DS-MIPv6 document.

That would work for me.  I'd very much like to see the TLV header itself
kept; the reason is that if something else (GRE or whatever) than an IP
header follows the UDP header, there isn't a clear and obvious way of
dynamically distinguishing *what* that something else is, unless the
TLV header is there.  Ripping it out completely would leave the
specification less ready for extension than otherwise, which would be
unfortunate if we already know that there are needs for extension.

One thing in the -05 and -06 drafts which surprised me when looking at
them now was the value assignments for the TLV type field -- I'd expected
the use of already-defined protocol numbers here, in a similar manner to
what's in Section 3.3 of RFC 3519, rather than a new registry.  But there
are maybe things I've forgotten from our earlier discussion which makes
a new type number space necessary.

	Henrik

---

From: <[email-masked]>
Date: Thu, 15 Jan 2009 22:59:13 +0200

Henrik Levkowetz wrote:

> That would work for me.  I'd very much like to see the TLV header
> itself kept; the reason is that if something else (GRE or whatever)
> than an IP header follows the UDP header, there isn't a clear and
> obvious way of dynamically distinguishing *what* that something else
> is, unless the TLV header is there.  Ripping it out completely would
> leave the specification less ready for extension than otherwise,
> which would be unfortunate if we already know that there are needs
> for extension.

Right.. however, since the future extensions will include a
negotiation mechanism (some bit somewhere) to say "I support this
extension FOOBAR (which implies using TLV header)", do we need 
a separate "I support TLV header" bit in this spec?

(Since if you don't support any of the extensions, sending normal
IPv4/IPv6 using the TLV format seems a bit strange.)

BTW -- currently, the spec says that the packet has a *single* TLV
header (not a sequence of them), so the length field isn't
actually used for anything -- so it's really TV header :)

> One thing in the -05 and -06 drafts which surprised me when looking
> at them now was the value assignments for the TLV type field -- I'd
> expected the use of already-defined protocol numbers here, in a
> similar manner to what's in Section 3.3 of RFC 3519, rather than a
> new registry.  But there are maybe things I've forgotten from our
> earlier discussion which makes a new type number space necessary.

Even when TLV header is negotiated, some packets (at least BUs) are
sent without the TLV header (the IP header starts immediately after
UDP header).

Currently, the TLV Type field is just 4 bits (to align it with the IP
version number field), and obviously values 4 and 6 won't work
(for some reason, the current spec also forbids values 2, 3, 5,
and 7..15 -- I can't see why that couldn't be relaxed...).

If it was 8 bits, at least TLV types 0x40..0x4f and 0x60..0x6f would 
need to be reserved (and that would complicate using already-defined 
protocol numbers).

Best regards,
Pasi

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jan 2009 22:50:31 +0100

Hi Pasi,

> IPv4/IPv6 using the TLV format seems a bit strange.)

Agreed on not needing the TLV for normal IPv4/IPv6.  Not sure if that
means that it's a good idea to remove the TLV support bit, if we keep
the TLV.

> actually used for anything -- so it's really TV header :)

Agreed.  In 3519, the extra header has a different layout and no
length field, which is anyway needed if one wants to use it as a 'next
header' header.  More below.

> sent without the TLV header (the IP header starts immediately after

Agreed.

> and 7..15 -- I can't see why that couldn't be relaxed...).

Ah.  I see the TLV header layout has changed.  In order to do something
similar to 3519, I imagine it looking something like the following
(which seems to be somewhat in alignment with what you suggest below):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  |  Res. |  Next Header  |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This field is always 0 (zero) and distinguishes the TLV header
      from the IPv4 and IPv6 headers.

> need to be reserved (and that would complicate using already-defined 

Or we separate out the type and value ('next header', above) parts,
which removes the need to reserve some ranges).

But maybe I'm off in the woods here -- I haven't followed any recent
discussions on the TLV format, so I'm not aware of the background
for the layout in the current spec.

Best,

	Henrik

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 16 Jan 2009 12:00:13 +1100

> atleast two consensus calls that were run at that time.

=> I don't realy want to get into that, we all know there was no concensus
and we had to teleconference to come up with the existing method

Anytime you have
> header document can be standardized fast enough

=> Can't this be copied and pasted into the netlmm draft and of course
elaborated upon to add Pasi's request?

for
> scope in the DS-MIPv6 document.

=> This is what Pasi is objecting to.

Hesham

---

From: <[email-masked]>
Date: Fri, 16 Jan 2009 16:06:19 +0100

Hi all,

Just a naive question: during re-chartering discussion, it was proposed a work item for the use of GRE tunnelling mechanism in Mobile IPv6. But this item has not been included in the charter. So, I'm wondering if there is still some plan to work on (except draft-ietf-netlmm-grekey-option in NetLMM WG)? If yes, maybe it could solve the issue.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Hesham Soliman
> Envoyé : vendredi 16 janvier 2009 02:00
> À : Vijay Devarapalli; [email-masked]; [email-masked]
> Cc : Jari Arkko
> Objet : Re: [MEXT] GRE support in DSMIPv6 - AD review
> 
> 
> > Hi Pasi, Hesham,
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Jan 2009 09:27:09 -0800 (PST)

From: Hesham Soliman <[email-masked]>
To: Vijay Devarapalli <[email-masked]>; [email-masked]; [email-masked]
Cc: Jari Arkko <[email-masked]>
Sent: Thursday, January 15, 2009 7:00:13 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review

At that time, there were folks arguing for using GRE
> encapsulation with MIPv6 also. 
[behcet] I couldn't understand why MN would need to support GRE. Can someone explain the use case?
 
Thanks,
 
Behcet

Anytime you have
> header.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 17 Jan 2009 10:56:30 +1100

> [behcet] I couldn't understand why MN would need to support GRE. Can someone

=> It was done for NETLMM. Technically and practically speaking it will
never be used by the MN. And there is no reason for doing so. Whenever GRE
is used it's used within the network not from the host.

Hesham

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 11:22:05 +0100

Hi Behcet,

If relevant in MIP context: there is a proposal to use GRE key as a tunnel identifier to solve the tunnel loop issue (IETF73/ intarea open meeting/presentation of draft-ng-intarea-tunnel-loop-00).

Regards,
Pierrick
________________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Behcet Sarikaya
Envoyé : vendredi 16 janvier 2009 18:27
À : Hesham Soliman; Vijay Devarapalli; [email-masked]; [email-masked]
Cc : Jari Arkko
Objet : Re: [MEXT] GRE support in DSMIPv6 - AD review

Anytime you have

Thanks,
 
Behcet

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 14:32:05 +0100

Hesham Soliman wrote:

> => It was done for NETLMM. Technically and practically speaking it
> will never be used by the MN. And there is no reason for doing so.
> Whenever GRE is used it's used within the network not from the host.

If that's the case, why not specify it for PMIPv6 only?

(That would potentially simplify the specs -- you don't e.g. need to
think how "client MIPv6" IPsec (a messy area already) would work with
GRE. PMIPv6+IPsec is much simpler case, and might not need any new
text for GRE.)

Best regards,
Pasi

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 20 Jan 2009 00:45:22 +1100

> If that's the case, why not specify it for PMIPv6 only?

=> You're asking the wrong person :) I never wanted this. I fully support
moving this out of the draft.

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 10:09:25 -0800 (PST)

> [behcet] I couldn't understand why MN would need to support GRE. Can someone explain the use case?

This issue was discussed at length. Many reasons were cited as why the
GRE encapsulation mode may be needed in client-based mobility and why
it should not be restricted to network elements alone.

The LMA element in Proxy Mobile IPv6 is a feature extension to the
Mobile IPv6 home agent. They have a strong relation. If some one
implements home agent function, implements the data plane with all
the hardware support for GRE and it cant be leveraged when supporting
client-based mobile nodes ? Its the same home agent that serves both
types of nodes.

The options that we are standardizing NETLMM or MEXT, each should not
take a different path. Its not that we have one revocation option for
PMIP, one for NEMO and the other for MIP6. Keeping them together will
save implementors to leverage all these features and resources across.

GRE is another enapsulation mode, it exists with much richer semantics
than IPv6-in-IPv6. The ability to carry non IP traffic, I'm not saying
I support this for carrying IPX/AT traffic, but the point that its a
useful encapsation mode that exists in MIP4 and cant be ignored for
good reasons.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 19 Jan 2009 12:42:46 -0600

I still fail to really understand why GRE encapsulation is needed for host
based mobility (DSMIP6).
The only argument below is that it provides "richer semantics than
IPv6-in-IPv6". Can you provide an explicit example of how the richer
semantics are useful vs the IP-in-IP encapsulation for DSMIP6?

Cheers,
-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 11:01:22 -0800 (PST)

Raj,

We went over all this list year back. You asked the same question,
you got the same answers. There are no new arguments. If you want
to ignore the use of GRE key in NEMO use, for marking different MNP
flows for differential treatment on the HA, or the point of carrying
legacy payload traffic, or about a single integrated HA/LMA serving
mobile nodes and leveraging a common encap mode, you may so, but the
fact reamins. Its useful in PMIP, it may be useful in NEMO, or may not
be so useful in client-MIP, fine, lets not apply restrictions.  If we
have a home agent that can perform GRE switching in the hardware, its
a good reason for me to leverage for all mobile flows and not build one
more mode.

We really should not be re-opening converged cases. There is a AD
comment on lack of specification on the tunneling mode, we can
easily fix that, rather dug open the whole mountain. Hesham spent
lots of time on adding all the TLV and the related support, we
dont have to waste all that, if there is some thing minor missing.

Regards
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 19 Jan 2009 13:41:11 -0600

Sri,

For the resolution of the IESG comments regarding the TLV header, I have
said that this spec should get rid of it and if someone feels the need for
it to be specified, they can do so (potential docs suggested being the IPv4
support I-D or the GRE Keys I-D in Netlmm WG).

My comment was based on the reopening of the discussion regarding the need
for GRE encapsulation in the context of DSMIP6. I agree that nothing has
changed since we had this discussion a while ago and as you can tell neither
has my opinion regarding the need for GRE for host based mobility.
But I am fine with whatever is deemed as the consensus regarding the TLV
header and/or GRE encapsulation support in the DSMIP6 I-D.

-Raj

On 1/19/09 1:01 PM, "Sri Gundavelli" <[email-masked]> wrote:

>>>> [behcet] I couldn't understand why MN would need to support GRE. Can
>>>> someone
>>>> explain the use case?
>>>>  
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 12:06:33 -0800 (PST)

Ok. Thanks Raj.

However we do, fixing it in this doc as planned initially,
in a new doc, the mode should be available to both network-based
and client-based mobility, that will keep the initally agreed upon
consensus as reflected when the doc was sent to IESG by the WG. We
still need to adress the comment on the lack of text and IMHO this
doc is the right place as the mode is common to all.

Hope this one last comment gets resolved the right way.

Regards
Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Jan 2009 13:07:26 -0800 (PST)

Hi Sri,
  You are right, it exists in MIP4. For some reason it doesn't in MIP6. GRE key draft proposes to use it mainly for IPv4 traffic. 
  My suggestion is to move TLV text to the netlmm GRE key draft. This way we have everything related to GRE in one document. As you said that document does not disallow using it in (DS)-MIPv6. So a win-win case .

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Basavaraj Patil <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Pasi Eronen <[email-masked]>
Sent: Monday, January 19, 2009 2:06:33 PM
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review

Ok. Thanks Raj.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 19 Jan 2009 13:30:50 -0800 (PST)

Hi Behcet,

The issue would be that this spec needs to understand the payload 
qualifier, else we cant add themm later. Its the same DSMIP UDP flow,
one with the flows carried natively and the other with some format
that we will define some where else. As pointed out earlier and
also as a matter convention set by RFC-3519, we cant carry payloads
with out a proper header. All protocols have always provided some
form of thin header, which identifies the type of payload it carries.
Ignoring the GRE discussion, we need this TLV header even for that
reason.

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 20 Jan 2009 13:28:40 +1100

> qualifier, else we cant add themm later.

=> It's not true though. You can add the exact same thing that we have in
the draft now but specify it in a more complete manner and it will be
backward compatible and interoperable. The negotiation bit in the BU would
have to be included in the new draft of course.

Hesham

Its the same DSMIP UDP flow,
>>   You are right, it exists in MIP4. For some reason it doesn't in MIP6. GRE
>> key draft proposes to use it mainly for IPv4 traffic.
>>   My suggestion is to move TLV text to the netlmm GRE key draft. This way we
>> have everything related to GRE in one document. As you said that document
>> does not disallow using it in (DS)-MIPv6. So a win-win case .
> 
> 
> 
>> 
>> Regards,
>> 
>> Behcet
>> 
>> 
>> 
>> 
>> Cc: Behcet Sarikaya <[email-masked]>; Jari Arkko <[email-masked]>;
>> [email-masked]; Pasi Eronen <[email-masked]>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 20 Jan 2009 19:05:45 -0800 (PST)

> have to be included in the new draft of course.

Leaving the TLV header alone in this draft will provide the
necessary frame work. Else, defining outside and mapping the
pre-allocated v4/v6 types, will appear more like a hack. Since,
Pasi's comment was more specific to GRE, not sure if it was
about the TLV alone, as there is much text required for TLV
nego, or for describing the TLV format, thats already there in
the draft.

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 21 Jan 2009 15:04:01 +1100

> 
> 
> On Tue, 20 Jan 2009, Hesham Soliman wrote:
> 
>>> 
> necessary frame work.

=> You're not answering the comment I mentioned above Sri.

  Else, defining outside and mapping the
> about the TLV alone,

=> Let's not talk about hacks....Pasi strongly suggested that we remove the
TLV completely and do it for PMIPv6. I think there is enough people who
already agree with that and I don't see a reason for us to debate this
endlessly. This draft is long overdue. So, it's best to include this in a
specific PMIP draft.

as there is much text required for TLV
> nego, or for describing the TLV format, thats already there in

=> Right, you can easily copy and paste it.

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 20 Jan 2009 23:01:44 -0800 (PST)

> => You're not answering the comment I mentioned above Sri.

First, I really feel the pain you had to deal with this draft,
if that makes you feel any better. Its incredible, how many
issues hit this draft at each level. Totally understand your
efforts and that this needs to move.

On this specific issue, my point is that if GRE is underspecified,
lets not define the GRE type. But, I dont know why its any issue
to have to that TLV, just as 3519, CAPWAP or any tunnel have
headers, its just payload qualifier, for which you already have
the text. But, we dont have argue on this, I go with the consensus.

I'm only afraid, we take this out from here, this will never see
the day of the light. If there are some thoughts, on where it will
go and that there will be no issues moving it to the other draft,
that will help and will also not affect the long reached earlier
consensus, phone calls ..etc. Again, please reconsider keeping
the TLV, I dont see any reason how that will help moving it out,
moving GRE, I can understand, but TLV, not sure. My 2c.

Regards
Sri

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 21 Jan 2009 18:07:48 +1100

> efforts and that this needs to move.

=> Thanks. I just have to highlight two points:
- I'm expressing my opinion as a member of the WG. In this case I happened
to agree with the IESG review.
- It's not up to me to reconsider, you've seen the comments from Pasi in the
IESG review and you've seen other people's responses agreeing to remove
this. 

Again, I happen to agree with them, but it's not my decision to "reconsider"
even if I didn't agree. Also as you noted time is not on our side.

> consensus, phone calls ..etc.

=> I think it will be fine in NETLMM, you can add it to the IPv4 support
work if you like as an extension to DSMIPv6. I can't see why it will be
blocked in NETLMM, everyone there seems to be happy with it for PMIPv6.

Hesham

Again, please reconsider keeping

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 20 Jan 2009 23:17:09 -0800 (PST)

> IESG review and you've seen other people's responses agreeing to remove

May be Pasi/IESG can clarify on this. As I understood, he was more
concerned on the lack of specification on the GRE tunneling mechanism
and not specific to TLV related header, there is not much to specify
there.

Sri

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 17:25:20 +0100

Sri Gundavelli wrote:

> concerned on the lack of specification on the GRE tunneling
> mechanism and not specific to TLV related header, there is not much
> to specify there.

I believe moving all TLV header text to some other document would get
draft-ietf-mext-nemo-v4traversal published much faster.

This discussion thread has already revealed that the TLV format
probably isn't quite right. (For example, according to the current
text, the "Type" field has only two possible values (0 and 1 -- not
much room for future extensibility!), and the length field isn't
actually used for anything.) Also, the 'T' bit in BU seems redundant,
since neither MN nor HA actually uses the value for anything in
this specification.

I'm not objecting to keeping the TLV format in this document if the
issues are fixed, but would recommend taking small steps: get
nemo-v4traversal spec published first, and figure out TLV format
details when they're actually needed (in current nemo-v4traversal
spec, neither MN nor HA actually ever sends any TLV format packets).

Best regards,
Pasi