Subject: [nemo] Summary and conclusion of: DS-MIP6 - Consensus call to close issue 93

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 14:46:40 -0500

So after an extensive discussion on this topic which spun off into a
discussion about the need/use for GRE, I would like to summarize where we
are with the options that we have.

Conclusion was that for DS-MIP6, Option 1 which is : " Parse the protocol
header following the UDP header" is good enough.

So it implies no changes to the current text in the DS-MIP6 I-D w.r.t this
issue are needed.

It was pointed out that in the future if GRE was determined as a protocol
that needs to be supported as well either for MIP6, NEMO or PMIP6 then it
would be specified in the appropriate WG and a UDP port reserved for the
same. In such a case it would essentially be the equivalent of option 2 in
the choices list (below).

At this time, the need for GRE especially in the scope of DS-MIP6 which is
primarily MIP6 and NEMO is not proven. Hence we will move forward with
Option 1 and close this issue.

-Raj

On 5/8/07 4:16 PM, "ext Basavaraj Patil" <[email-masked]> wrote:

> 
> Hello,
> 
> The DS-MIP6 I-D <draft-ietf-mip6-nemo-v4traversal-04.txt> still has
> issue 93 open. This was discussed at IETF68. Vijay presented 4 options
> to solve the issue. These are captured in:
> 
> https://www3.ietf.org/proceedings/07mar/slides/mip6-2.pdf
> 
> We need to make a decision on this issue and move forward with the
> I-D. At the meeting itself, I got the sense that option 3 was the one
> that had the least impact and easy to implement.
> 
> Please consider this email as a consensus call for issue 93. The
> problem and choices are as follows (based on Vijay's slides):
> 
> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The
> encapculations are either:
>  - IPv6-in-UDP-over-IPv4
>  - IPv4-in-UDP-over-IPv4
> There is a need (or I guess desirable) to indicate the type of
> protocol being encapsulated in the UDP header.
> 
> Choices are:
> 1. Parse the protocol header following the UDP header
> 2. Reserve a UDP port for each protocol header (i.e one UDP port for
>    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)
> 3. One reserved UDP port and a DS-MIP6 "tunnel type message"
> 4. Encapsulated protocol header type is indicated in the BU message
> 
> Pros and cons of these choices are in the slides that were presented
> at IETF68 (see URL above).
> 
> Please provide your opinions and comments by May 15th, 07 on the MIP6
> mailing list.
> 
> -Raj
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 01 Jun 2007 22:52:49 +0200

Hi Raj,

> header following the UDP header" is good enough.

Could you give us an indication of who preferred which option?  You seem
to be very clear about the outcome, while it was far from obvious to me
that the counts turned out to support above conclusion...

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 16:18:05 -0500

Henrik,

Rough consensus is what I am going by here.
But I will send the count or who chose what if it helps anyway.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 16:36:27 -0500

Vijay D. - Option 4 originally and then changed to Option 2
Hesham - Option 1
Sri Gundavelli - Option 3
Kent - Option 3
Ahmad Muhanna - Option 3
Alex Petrescu - Option 1 (Interpreted)
George T. - Option 1
Mohamed Khalil - Option 3
Markku Ala-V - Option 2
Henrik L. - Option 3
Pascal T. - Option 1 (Interpreted)

So we have a sort of a tie if you strictly go by count.
If I were to express my own opinion (non-chair-hat), I would go with
option 1 as well for the current DS-MIP6 proposal (aligned with my
earlier email that if and when GRE is planned for use, another UDP
port can be reserved... But for now option 1). That would break any
deadlock issues.

Or the other way is to let the chairs decide what is the sense of the
discussion on the ML and from the perspective of the charter/scope and
urgency of this protocol. And from this angle as well, I would stick
by my conclusion, i.e option 1.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 1 Jun 2007 15:13:11 -0700

FWIW, I had also supported going with Option 1 for DS-MIP6. 

Vidya 

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 2:36 PM
> To: Levkowetz
> Cc: [email-masked]; Mobile IPv6 Mailing List
> Subject: [Mip6] Re: [nemo] Summary and conclusion of: DS-MIP6 
> - Consensus call to close issue 93
> 
> 
> 
> Hesham - Option 1 Sri Gundavelli - Option 3 Kent - Option 3 
> Ahmad Muhanna - Option 3 Alex Petrescu - Option 1 
> (Interpreted) George T. - Option 1 Mohamed Khalil - Option 3 
> Markku Ala-V - Option 2 Henrik L. - Option 3 Pascal T. - 
> Option 1 (Interpreted)
> 
> If I were to express my own opinion (non-chair-hat), I would 
> go with option 1 as well for the current DS-MIP6 proposal 
> (aligned with my earlier email that if and when GRE is 
> planned for use, another UDP port can be reserved... But for 
> now option 1). That would break any deadlock issues.
> 
> Or the other way is to let the chairs decide what is the 
> sense of the discussion on the ML and from the perspective of 
> the charter/scope and urgency of this protocol. And from this 
> angle as well, I would stick by my conclusion, i.e option 1.
> 
> -Raj
> 
> 
> >> discussion about the need/use for GRE, I would like to summarize 
> >> where we are with the options that we have.
> >> 
> >> Conclusion was that for DS-MIP6, Option 1 which is : " Parse the 
> >> protocol header following the UDP header" is good enough.
> > 
> > Could you give us an indication of who preferred which option?  You 
> > seem to be very clear about the outcome, while it was far 
> from obvious 
> > to me that the counts turned out to support above conclusion...
> > 
> > 
> > Henrik
> > 
> >> So it implies no changes to the current text in the 
> DS-MIP6 I-D w.r.t 
> >> this issue are needed.
> >> 
> >> 
> >> It was pointed out that in the future if GRE was determined as a 
> >> protocol that needs to be supported as well either for 
> MIP6, NEMO or 
> >> PMIP6 then it would be specified in the appropriate WG and 
> a UDP port 
> >> reserved for the same. In such a case it would essentially be the 
> >> equivalent of option 2 in the choices list (below).
> >> 
> >> At this time, the need for GRE especially in the scope of DS-MIP6 
> >> which is primarily MIP6 and NEMO is not proven. Hence we will move 
> >> forward with Option 1 and close this issue.
> >> 
> >> -Raj
> >> 
> >> 
> >> 
> >>> issue 93 open. This was discussed at IETF68. Vijay presented 4 
> >>> options to solve the issue. These are captured in:
> >>> 
> >>> I-D. At the meeting itself, I got the sense that option 3 was the 
> >>> one that had the least impact and easy to implement.
> >>> 
> >>> 1. Parse the protocol header following the UDP header 2. 
> Reserve a 
> >>> UDP port for each protocol header (i.e one UDP port for
> >>> Please provide your opinions and comments by May 15th, 07 on the 
> >>> MIP6 mailing list.
> >>> 
> >>> -Raj
> >>> 
> >>>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 1 Jun 2007 15:13:11 -0700

Vidya

---

From: Jean Lorchat <[email-masked]>
Date: Sat, 02 Jun 2007 08:27:31 +0900

Hi,

In the Nautilus6 project, we are working on a Linux implementation of 
the DS-MIP6 draft and as such, we currently provide option 1. It seems 
satisfactory enough for us and we have no issues to report with that, as 
of yet. Implicitly, I'd say we support option 1 as implementors.

Also, I personally feel that it is important for the DS-MIP6 
specification to move forward quickly.

Regards,
Jean

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Jun 2007 01:27:53 +0200

> So we have a sort of a tie if you strictly go by count.

No, if we strictly go by the above count, there's no tie:

Option 3	5 counts
Option 1	4 counts
Option 2	2 counts

> port can be reserved... But for now option 1). That would break any

That would be credible if you'd said that before pronouncing a consensus
for option 1.  Now it doesn't.

> by my conclusion, i.e option 1.

That was my original reason for asking for the count -- having followed
the discussion, my perception was *very* different, and there wasn't a
consensus for 1 in the sense of the discussion.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Jun 2007 01:28:29 +0200

Hi Vidya, Rai,

> FWIW, I had also supported going with Option 1 for DS-MIP6. 

Of course that matters, Vidya, but the more important thing here
is that it's pretty clear to me that there is *no* rough consensus
present.

Please don't manufacture one when there isn't one; if there
really isn't one, do another call for discussion and/or show
of hands, and if the group is deadlocked, use 3929.

I can't accept this pronouncement of a consensus, rough or not,
in the group, neither from my observation of the discussion or
from the count.

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 18:44:06 -0500

Henrik,

> No, if we strictly go by the above count, there's no tie:

Guess I need to count better. Sorry, my mistake. Yes based on the above that
is true. But I missed Vidya in this count (which she indicated following the
email). So if I were to include Vidya in the count and myself, it would be
very rough consensus.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 18:52:15 -0500

Henrik,

Rough consensus is what we have from my perspective on this issue. It is not
being fabricated. 

Apparently you differ. I can ask Jari (AD) for his recommendation on
whether:
1. To do a new consensus call
2. Use any of the RFC 3929 alternatives

-Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 2 Jun 2007 11:41:51 +1000

Henrik, 

You seem to be looking for a vote. We've always asked for concencus to
change anything 
in the draft. The numbers that Raj sent clearly indicate that there is no
concensus to change the draft. 5:4 is not concensus. Therefore, I think
Raj's decision is correct. I hope we don't turn the IETF into a voting
organisation, if we do then the whole process of providing a vote would be
different from what we do today. 

Hesham 

 > From: Henrik Levkowetz [mailto:[email-masked]] 
 > Sent: Saturday, June 02, 2007 9:28 AM
 > To: Narayanan, Vidya
 > Cc: [email-masked]; Mobile IPv6 Mailing List; Basavaraj Patil
 > Subject: Re: [Mip6] Re: [nemo] Summary and conclusion of: 
 > DS-MIP6 - Consensuscall to close issue 93
 > 
 > Hi Vidya, Rai,
 >

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 2 Jun 2007 11:59:07 +1000

incidentally it is apparently 6:5 in favour of option 1. If the draft
contained option 2 today then I would say that 6:5 is not concensus to
change the draft. 

Hesham 

 > From: Hesham Soliman [mailto:[email-masked]] 
 > Sent: Saturday, June 02, 2007 11:42 AM
 > To: 'Henrik Levkowetz'; 'Narayanan, Vidya'
 > Cc: [email-masked]; 'Mobile IPv6 Mailing List'
 > Subject: RE: [Mip6] Re: [nemo] Summary and conclusion of: 
 > DS-MIP6 -Consensuscall to close issue 93
 > 
 > Henrik, 
 >

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Jun 2007 12:14:43 +0200

> Rough consensus is what we have from my perspective on this issue. It is not

Then you use a very different definition of rough consensus than I
do.  I see no consensus at all in this question yet.

> 2. Use any of the RFC 3929 alternatives

Yes, please do so.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Jun 2007 12:15:54 +0200

Hesham,

On 2007-06-02 03:41 Hesham Soliman said the following:
> Henrik, 
> 
> You seem to be looking for a vote.

No, I'm not looking for a vote.  I'm looking for consensus on how to
handle the issue.  And I don't see any consensus on how to handle the
issue here.

	Henrik

> We've always asked for concencus to
> change anything

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 2 Jun 2007 21:04:42 +1000

> handle the issue.  And I don't see any consensus on how to handle the

=> The issue was raised against an existing solution, if there is no support
in the WG (6 people against and 5 for it) then clearly there is no agreement
that there is an issue to begin with. What are you suggesting we do? If
there is no support for the perceived issue then naturally it's rejected. I
don't think anyone is changing their mind if we ask the same question again
in the space of two weeks...

If a 6:5 or 5:4 means no concensus to you, then I'm surprised that you
accepted the same numbers as concensus on other issues, like the mapped
address one or issue 93. Should we repeat all those questions again? 

Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 02 Jun 2007 14:56:20 +0200

On 2007-06-02 13:04 Hesham Soliman said the following:
> The issue was raised against an existing solution, if there is no support
> that there is an issue to begin with.

I think this is incorrect; that we don't agree on a solution doesn't
mean there isn't an issue.  But if you want to ask the list if they
think this is a non-issue, go right ahead.

> What are you suggesting we do? If

I saw several people change position during the discussion, which is
of course the benefit of having a discussion in the first place -- as
various aspects of a question is illuminated, people get a clearer
view of the tradeofs, and hopefully align in a rough consensus.

> address one or issue 93. Should we repeat all those questions again? 

If you have counts of those issues that indicate that there was no
consensus (and 6:5 or 5:4 isn't even rough consensus as far as I can
tell) then I think that would be the right thing to do.  However, my
memory of the other discussions isn't that they were as inconclusive
as this one.

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 2 Jun 2007 23:49:58 +1000

> think this is a non-issue, go right ahead.

=> We already did that, it's implicit in the question for a choice between
keeping things as they are (i.e. it's not an issue that we need to solve) Vs
3 other options (or 2 workable options because option 4 doesn't work).

 > view of the tradeofs, and hopefully align in a rough consensus.

=> Several people? I saw one.

 > tell) then I think that would be the right thing to do.  

=> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there
is no concensus to change the draft. Of course the figures for the mapped
address were sent to the list, it was 5:4 for the change, you have those
figures too. So if we re-open an issue for this reason then we have to be
consistent and re-open all issues. 

   However, my
 > memory of the other discussions isn't that they were as inconclusive

=> You can check Raj's email on the mapped address issue yourself, it was
another 5:4. I don't remember the exact number on issue 93. I assume you're
not considering that a valid concensus either, we would agree on that.

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 2 Jun 2007 11:30:58 -0700

I understand the need to complete the DSMIP6 as early as
possible and I appreciate the Chair's position to close
this issue soon. I really like to see that as well. I also
believe, IMO, that there is a proper justification in asking
for Option#3. Its for a simple TLV header, qualifier in UDP
for the payload packet. Many reasons, examples, protocol
conventions including 3519's way of dealing with the exact
same issue, lack of resaved port numbers, opening multiple
port numbers if we were to extend it later, and many other
reasons were mentioned and against the one solid reason of
extra-4 byte overhead. We don't have turn this to a voting
machine, if we see the need for this request with certain
flexibility.

Now, w.r.t the voting, I though Pascal did mention the need
for a supporting new encapsulation mode and off course he
also wanted this work to close ASAP and that leaves it in
a ambiguous vote. And if I interpret Vijay's emails correctly,
his preference is for Option#4 and his second preference is
for option#3. He can speak up. And, we missed Alessio Casati's
preference on this issue, he did support option#3. So with
Jouni Korhonen, he did state that "I prefer more future proof
extensibility over slight performance hit thus I prefer the
4 bytes header like in 3519". I also interpret Yoshi Tsuda's
vote in favour of option#3.

If this is not rough consensus, atleast, there is sufficient
interest to discuss this issue further and proper conclude.
My 2c.

Regards
Sri

> Sent: Saturday, June 02, 2007 4:05 AM
> To: 'Henrik Levkowetz'

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Jun 2007 00:30:26 +0200

On 2007-06-02 15:49 Hesham Soliman said the following:
> We already did that, it's implicit in the question for a choice between

I think here we have a fundamental disagrement.

If I understand your reasoning right, then you are saying that in a
case when the WG doesn't have consensus on an issue, whatever is
written in a document is going to be the resolution.

I'm saying that if the working group doesn't have consensus on an issue,
it doesn't matter what the document says; the document cannot go forward
with either of the discussed solutions if the WG doesn't have rough
consensus for one of them.

Maybe you're focussing more on what is going to be changed in the
document right now, rather on closing the issue; while I'm focussing on
resolving the issue, and the text of the document at the point when it
can be sent for publication, rather than focussing on what happens to
the document text right now?

> Several people? I saw one.

And I saw several.  Does arguing about this lead anywhere?

> I agree that 6:5, 5:4 or 4:3 is not a concensus. To me that means there
> You can check Raj's email on the mapped address issue yourself, it was

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Jun 2007 00:47:00 +0200

On 2007-06-02 20:30 Sri Gundavelli said the following:
...
> vote in favour of option#3.

So if I count this correctly, we have 

Option 3	9 counts (+ Vijay's 2nd pref)
Option 1	5 counts
Option 2	2 counts
Option 4	1 count

> interest to discuss this issue further and proper conclude.

I agree.

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 12:37:21 +1000

Sri, 

Pascal's email was not sent in private and we don't need an interpretation.
He's alive and well and he didn't object to Raj's conclusion. He clearly
said that we should let the draft move as is. I believe other people who are
also alive and well can speak for themselves if they were
misrepresented.....

I look forward to people expressing that they were misrepresnted by the
chairs. I don't think it's useful for you or Henrik to recount on their
behalf.

Hesham

 > >  > >>>>>> So after an extensive discussion on this topic 
 > which spun 
 > >  > >>>> off into a 
 > >  > >>>>>>> The DS-MIP6 I-D 
 > <draft-ietf-mip6-nemo-v4traversal-04.txt> 
 > >  > >>>> still has 
 > >  > >>>>>>> We need to make a decision on this issue and 
 > move forward 
 > >  > >>>> with the 
 > >  > >>>>>>> 4. Encapsulated protocol header type is 
 > indicated in the 
 > >  > >>>> BU message

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 12:39:22 +1000

Henrik, 

Like I said, if you want to go by your interepretation then I'll ask the
chairs to reopen the other issues. I won't accept selectivity on where to
apply those rules. 
I'll wait for the chairs/AD's decision on this. 

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 2 Jun 2007 22:33:39 -0700

Hesham,

Fine. Let them speak out. I will just say, there is sufficient
interest to close this issue properly. Rest, I will leave it to
the chairs and to the authors of this draft to ensure the draft
reflects the WG consensus, in the right spirit.

Regards
Sri

> Sent: Saturday, June 02, 2007 7:37 PM
> To: 'Sri Gundavelli'; 'Henrik Levkowetz'
> DS-MIP6-Consensuscall to close issue 93
> 
> Sri, 
> 
>  > >  > >>>>>>> Please provide your opinions and comments by 
> May 15th, 
>  > >  > >> 07 on the 
>  > >  > >>>>>>> MIP6 mailing list.
>  > >  > >>>>>>>
>  > >  > >>>>>>> -Raj
>  > >  > >>>>>>>
>  > >  > >>>>>>>

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 16:37:18 +1000

That's fine with me.

Hesham 

 > From: Sri Gundavelli [mailto:[email-masked]] 
 > Sent: Sunday, June 03, 2007 3:34 PM
 > To: 'Hesham Soliman'; 'Henrik Levkowetz'
 > >  > >  > > organisation, if we do then the whole process of 
 > providing 
 > >  > >  > a vote would be
 > >  > >  > >>>>>> discussion about the need/use for GRE, I 
 > would like to 
 > >  > >  > >> summarize 
 > >  > >  > >>>>>> Conclusion was that for DS-MIP6, Option 1 
 > which is : " 
 > >  > >  > >> Parse the 
 > >  > >  > >>>>> Could you give us an indication of who 
 > preferred which 
 > >  > >  > >> option?  You 
 > >  > >  > >>>>>> At this time, the need for GRE especially 
 > in the scope 
 > >  > >  > >> of DS-MIP6 
 > >  > >  > >>>>>> which is primarily MIP6 and NEMO is not 
 > proven. Hence 
 > >  > >  > >> we will move 
 > >  > >  > >>>>>>> Problem: UDP encapsulation is used in 
 > DS-MIP6 for NAT 
 > >  > >  > >>>> traversal. The 
 > >  > >  > >>>>>>> Pros and cons of these choices are in the 
 > slides that 
 > >  > >  > >>>> were presented

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Jun 2007 10:48:13 +0200

Hesham,

> chairs. I don't think it's useful for you or Henrik to recount on their

As you said about Pascal's email, the mails were sent to the list,
not in private.  If a review of the list shows substantially more
expressions of preference than were noticed by the chairs, this
seems to me to be a matter which I *do* think it's useful to point
out by showing a strawman recount.  I don't think you want the chair
to misrepresent what people have expressed on the list?

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Jun 2007 10:52:13 +0200

Hi Hesham,

> chairs to reopen the other issues. I won't accept selectivity on where to

Certainly.

But we should also have indications of preference which reasonably well
match what has been sent to the list.  With the mis-tally of people's
expressed preference in the latest case, the first thing to do would
maybe be to go over the list material in the other cases, and see if
maybe the list showed a consensus even if the chair's tally didn't
show one?

	Henrik

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 19:33:07 +1000

> to misrepresent what people have expressed on the list?

=> No of course I don't want that, hence my statement above. But these
people are on the list and they know whether they were misrepresented or
not. For the last few weeks (and since Raj sent his last email a couple of
days ago) no one seemed to complain, so let them speak for themselves. 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 19:46:15 +1000

> maybe the list showed a consensus even if the chair's tally didn't

=> I'm not sure what you mean by "going over the list material in the other
cases" but I'm more than happy for the chair or AD to review the concensus
threads for all those issues and include known opionions from the DT people.
Actually, some people were counted despite not sending a peep about the
issue to the list (not only during the concensus call but in general). So,
yes a review is fine with me as long as we're consistent; regardless of the
outcome. I was ok with things as is because at least it was consistent. The
question is whether we want to keep delaying things to do this or just go
with the decisions that were already made. 

Personally, I prefer less delays and going with the decisions already made
(and you know too well that I didn't agree with some of the outcomes), but
if you're objecting to the way all these decisions are made and the chairs
grant a review of all those issues then I'm fine with that too. As I said
earlier, the only thing that doesn't make sense is to change the rules for
one issue. 

Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 03 Jun 2007 17:55:41 +0200

Hi Hesham,

On 2007-06-03 11:46 Hesham Soliman said the following:
> I'm not sure what you mean by "going over the list material in the other

Right.

> with the decisions that were already made. 

I don't particularly want to delay things, but swiftly producing a
document which doesn't reflect the lists viewpoint on how the issues
should be resolved doesn't seem like a good idea either -- in the worst
case, it would lead to a requirement to do a -bis document immediately,
which I would see as a rather larger delay...

> earlier, the only thing that doesn't make sense is to change the rules for

I agree with this.

	Henrik

---

From: <[email-masked]>
Date: Mon, 4 Jun 2007 11:11:04 +0300

Hi,

Just to clarify my position on this issue, my preference was option 1
for now but reserve option 2 for extending
the protocol to support e.g. GRE later if seen necessary.

Cheers,
Markku 

>From: ext Basavaraj Patil [mailto:[email-masked]] 
>Sent: 02 June, 2007 00:36
>To: Levkowetz
>Subject: Re: [nemo] Summary and conclusion of: DS-MIP6 - 
>Consensus call toclose issue 93
>
>
>
>(aligned with my earlier email that if and when GRE is planned 
>for use, another UDP port can be reserved... But for now 
>option 1). That would break any deadlock issues.
>
>Or the other way is to let the chairs decide what is the sense 
>of the discussion on the ML and from the perspective of the 
>charter/scope and urgency of this protocol. And from this 
>>> So it implies no changes to the current text in the DS-MIP6 
>I-D w.r.t 
>>> this issue are needed.
>>> 
>>> 
>>>> 1. Parse the protocol header following the UDP header 2. Reserve a

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 13:59:22 -0700

Hesham,
 
> that there is an issue to begin with. What are you suggesting 
> we do? 

I disagree with this. It is an open issue. Just because it is
already there in the draft does not mean it gets to stay in
the draft. 6:5 means we don't have a good way forward. It does
not mean that there is no issue and the existing solution should
stay in the draft.

Vijay

If

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 14:05:19 -0700

Raj,

This is fine with me. But today we already have option 2. One
reserved UDP port for IPv4/v6 and another for ESP encapsulation
of DS-MIPv6 tunneled packets. 

Vijay

> Sent: Friday, June 01, 2007 12:47 PM
> To: ext Basavaraj Patil; Mobile IPv6 Mailing List; [email-masked]
> Subject: [Mip6] Summary and conclusion of: DS-MIP6 - 
> Consensus call to close issue 93
> 
> 
> I-D w.r.t this

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 5 Jun 2007 17:58:05 +0200

>also alive and well can speak for themselves if they were

[Pascal] Thanks Hesham :) :) 

I might have preferred 3 to be honest, just like I might have preferred
to include the RR test for IPv4 traversal and a number of other things
like HA in an IPv6 dominant network, etc... But realistically I think
the draft is good enough for the purpose and should not be delayed. I
voted to keep the mapped address for the same reasons.

So my proposal was:

1) publish the current draft ASAP with minimum (editorial) change.

2) promote rapidly a separate I-D on enabling option 3. 

The PS for that new I-D is almost done thanks to Sri's work and the
discussions over this issue 93. There were needs listed, I just added a
mobile pseudo-wire.

The fact that IPv6 comes straight after the UDP header pre exists to the
IPv4 traversal work, so issue 93 is a problem that should be addressed,
but can be addressed separately, with backward compatibility to both MIP
and MIPTRANS (it's not much harder anyway).

I believe it's hard to close the issue cleanly without a commitment to
do that work.

IMHO, exact same goes for the security issue we discuss over the
validity of the CoA: It's generally very hard for a MR to check that it
is actually reachable from the HA at the CoA unless RR test is
performed. Then again, the problem preexists to MIPTRANS, even if
MIPTRANS makes it worse with IPv4 and NATs. There also, I think a small
paper proposing a new optional mechanism could be a useful RFC.

I hope I made myself clearer now...

> > > we do? If

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Jun 2007 09:55:19 -0500

Hi Vijay,

Sure... So I guess you are okay with not having to add the 4 byte header
(Option 3).

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Jun 2007 10:01:37 -0500

Since concerns about rough consensus, process followed and who said what
w.r.t the various options seem to be dragging on, I have requested Jari
Arkko (AD) to review the discussion and the thread and provide a
recommendtion on next steps.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Jun 2007 00:39:58 +0300

All,

(Sorry for not responding to this sooner -- I was traveling.
But I have now reviewed the list discussion and talked
to some of you as well.)

First, it should be obvious that if we need to worry about
the difference of one or two persons, then we don't have
consensus. I appreciate the fact that we sometimes end
up in a controversial situation where there is no clear
consensus. But we should aim to run the working groups
by consensus rather than move forward when a slim
margin shows that some resolution "wins". That is, if
the opinions are so diverse then more discussion is
probably needed. Also, it would be better if people
who post opinions actually state why they believe
what they believe ("Approach A is already in my
implementation" or "Approach B makes X very
hard"). We also need to listen to what the others
are saying, and be able to change our opinion when
we learn new things. Everyone on this WG needs
to work harder towards consensus.

The other observation I would make is that in any
case the conclusions sent by the chairs need to
be accurate. I realize that in some cases a response
is unclear or may change/come late. But the counts
need to be right, and contain people who have
sent their opinions to the list. Basavaraj has already
admitted he made a mistake here, and has promised
to get this right in the future.

A datapoint from my discussion with the people
involved in this: I did not hear any extreme opinions
about the technical matter itself. None of the main
alternatives were seen to cause significant problems,
even if everyone had their favorite alternative. With
that in mind, I do not believe we should make this
process a long one. An almost perfect solution
now is better than a perfect solution later...

Hesham and Henrik talked about the nature of the
consensus call and that is actually an interesting
issue. One opinion was that lack of consensus
means we can not move forward until the issue
is resolved. Another opinion was that lack of
consensus means the issue was rejected and we
move forward without changing the document.
I'd say which approach to use is a judgment call.
The former approach is the usual IETF one. We really
need to solve issues that we know exist in the
specification. But in some cases, particularly with
new features someone suggests to adopt, it may
make sense to employ the other approach. Then
lack of consensus to adopt/not adopt the feature
means the document progresses anyway, assuming
of course there was earlier consensus about the
current document. Issue 93 is perhaps a borderline
case, as you could argue its either a new feature
or an issue in the current document.

How do we move forward? I would like to extend
the consensus call for a short period (a week)
and see if we can reach a better conclusion.
In addition to the preferred alternative (1-4) and
rationale, I think it would also be useful to understand
how the group feels about the text in the current
document. Does it adequately describe the operation
with regards to this issue (irrespective of whether you
prefer the used approach or not)? If no, some change
will be needed.

Hesham has also raised a concern about one
earlier issue (73). I will take a look at the discussion
to see if we need to revisit that. Note that we
will not revisit old issues lightly, only in case
of when substantial new information comes to
light.

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 10:53:49 +1000

Thanks Jari, This is the perfect answer to our discussion. I hope we can
move on within the extended week to resolve this. Folks, please feel free to
express more opinions, change opinions ...etc

Hesham 

 > From: Jari Arkko [mailto:[email-masked]] 
 > Sent: Thursday, June 07, 2007 7:40 AM
 > To: Basavaraj Patil
 > Subject: Re: [Mip6] Summary and conclusion of: DS-MIP6 -

---

From: "Yoshi Tsuda \(yotsuda\)" <[email-masked]>
Date: Thu, 7 Jun 2007 11:52:34 +0800

Hello Jari, Hesham, Sri and all:

 Thank you for your works!  If possible, and if you have time,
 I prefer the option#3.  I'm sorry for my late response.

 Does anyone have any time constraint to publish the current
 draft now?  If not, I deeply agree with Henrik; it would be sad
 to see many emails about a -bis document just after publishing
 the current draft...

 Personally, I don't care too much for GRE; if there are any
 other better mechanisms than GRE, it would be fine.  I agree
 with Hesham, if we got a port number, it would be wonderful.
 But, if not, it would be still great to have some encapsulation
 mechanisms as a second option.  GRE is just available in
 MIPv4 so far. :)  Have a nice day!

Cheers.
-Yoshi

> Sent: Thursday, June 07, 2007 9:54 AM
> To: 'Jari Arkko'; 'Basavaraj Patil'
> Subject: RE: [Mip6] Summary and conclusion of: DS-MIP6 - 
> Consensus calltoclose issue 93
> 
> Thanks Jari, This is the perfect answer to our discussion. I 
> hope we can move on within the extended week to resolve this. 
> Folks, please feel free to express more opinions, change 
> opinions ...etc
> 
> Hesham 
> 
>  > From: Jari Arkko [mailto:[email-masked]]  > Sent: 
> Thursday, June 07, 2007 7:40 AM  > To: Basavaraj Patil  > Cc: 
> [email-masked]; Mobile IPv6 Mailing List  > Subject: Re: 
> [Mip6] Summary and conclusion of: DS-MIP6 -  > Consensus call 
> toclose issue 93  >  > All,  >  > (Sorry for not responding 
> to this sooner -- I was traveling.
>  > But I have now reviewed the list discussion and talked  > 
> to some of you as well.)  >  > First, it should be obvious 
> that if we need to worry about  > the difference of one or 
> two persons, then we don't have  > consensus. I appreciate 
> the fact that we sometimes end  > up in a controversial 
> situation where there is no clear  > consensus. But we should 
> aim to run the working groups  > by consensus rather than 
> move forward when a slim  > margin shows that some resolution 
> "wins". That is, if  > the opinions are so diverse then more 
> discussion is  > probably needed. Also, it would be better if 
> people  > who post opinions actually state why they believe  
> > what they believe ("Approach A is already in my  > 
> implementation" or "Approach B makes X very  > hard"). We 
> also need to listen to what the others  > are saying, and be 
> able to change our opinion when  > we learn new things. 
> Everyone on this WG needs  > to work harder towards consensus.
>  >
>  > The other observation I would make is that in any  > case 
> the conclusions sent by the chairs need to  > be accurate. I 
> realize that in some cases a response  > is unclear or may 
> change/come late. But the counts  > need to be right, and 
> contain people who have  > sent their opinions to the list. 
> Basavaraj has already  > admitted he made a mistake here, and 
> has promised  > to get this right in the future.
>  >
>  > A datapoint from my discussion with the people  > involved 
> in this: I did not hear any extreme opinions  > about the 
> technical matter itself. None of the main  > alternatives 
> were seen to cause significant problems,  > even if everyone 
> had their favorite alternative. With  > that in mind, I do 
> not believe we should make this  > process a long one. An 
> almost perfect solution  > now is better than a perfect 
> solution later...
>  >
>  > Hesham and Henrik talked about the nature of the  > 
> consensus call and that is actually an interesting  > issue. 
> One opinion was that lack of consensus  > means we can not 
> move forward until the issue  > is resolved. Another opinion 
> was that lack of  > consensus means the issue was rejected 
> and we  > move forward without changing the document.
>  > The former approach is the usual IETF one. We really  > 
> need to solve issues that we know exist in the  > 
> specification. But in some cases, particularly with  > new 
> features someone suggests to adopt, it may  > make sense to 
> employ the other approach. Then  > lack of consensus to 
> adopt/not adopt the feature  > means the document progresses 
> anyway, assuming  > of course there was earlier consensus 
> about the  > current document. Issue 93 is perhaps a 
> borderline  > case, as you could argue its either a new 
> feature  > or an issue in the current document.
>  >
>  > How do we move forward? I would like to extend  > the 
> consensus call for a short period (a week)  > and see if we 
> can reach a better conclusion.
>  > In addition to the preferred alternative (1-4) and  > 
> rationale, I think it would also be useful to understand  > 
> how the group feels about the text in the current  > 
> document. Does it adequately describe the operation  > with 
> regards to this issue (irrespective of whether you  > prefer 
> the used approach or not)? If no, some change  > will be needed.
>  >
>  > Hesham has also raised a concern about one  > earlier 
> issue (73). I will take a look at the discussion  > to see if 
> we need to revisit that. Note that we  > will not revisit old 
> issues lightly, only in case  > of when substantial new 
> information comes to  > light.
>  >
>  > Jari
>  >
>  >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 6 Jun 2007 21:20:19 -0700

A question was asked, why do we need a 4-byte header when
we carry IPv4/IPv6 packets in a IPv4-UDP tunnel header ?

Reasons were stated as why we don't need it and why there
is no next IP version in our lifetimes. This is the other
side of the coin as why we would need it. I'm sure, we
can converge and decide on one solution, what ever that
is. 

Summary of the comments captured favoring option#3. Lets
close this thread ASAP.

1. Protocol Design Convention

Looking at IP header, Ethernet header or IPv6 options,
always the prev header qualifies the payload that follows.
No protocol is looking at the payload to determine the
type.

2. How 3519 handles the exact same scenario 

When a packet is carried in a UDP transport, its important
that the payload is classified by a prior header. Designers
of 3519 chose that option. Please see the 4 byte TLV header
in RFC-3519, Section 3.1.

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      |  Next Header  |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Extensibility and Future proof

We cannot say, we will only carry raw IPv4 or IPv6 payloads
and so the 1st byte IPv4 version lookup is sufficient. Lets
learn some thing from the IPv6 address space design, from
the Y2K problem or the millennium bug.

Allow the provision for carrying other types of messages.
Example:

- GRE Header (Explained below in item#6)

- Other encapsulation headers

4. Tunnel Keep Alive message

When DSMIP chose IPv4 UDP transport for NAT traversal,
the need for keepalive messaging between the tunnel
peers for keeping the NAT bindings came up. The authors
of the draft chose to use MIP6 signaling messages BU/BA
as a way to refresh the keepalive messages. IMO, having
a simple keepalive messages is lot more useful than an
expensive BU/BA. Most 3519 implementation today optimize
on this, by eliminating the keepalives when there is
traffic. We cant do such optimizations with BU/BA.

5. Lack of Reserved ports for allocation

The comment was made, we can always extend DSMIP for supporting
GRE or other encapsulation modes. Then the issue of backward
compatibility came up. The tunnel end points cannot demux the
encapsulated packets, when some packets are encapsulated with
a thin header and some with out a thin header. So, the only
alternative would be to allocate two ports numbers and the end
points have to listen on both the port numbers. But, as Henrik
mentioned, there is also an issue with the available reserved
ports for standard network services.

6. Why do we need GRE Header ?

We need GRE tunnel header for various reasons, when ever we
carry multiple streams within a tunnel, the GRE header for its
mature header semantics, the key field and the sequence number
field is useful.

We have some NEMO use cases where we use the GRE key to tag
certain MNP flows, and the tunnel peers use these keys as a
form of a selector for differential treatment. Its a color
code.

Use cases:

a.) Overlapping private IPv4 addressing support on the MAGs
    (PMIP6 Usage)

b.) GRE tunnel header for NEMO usecase

c.) Carrying other protocol packets (Lets say, IPX packets)
    in a MIP tunnel.

d.) MIP4 supports it for a reason 

e.) Industry direction and related work, these are the active
    drafts:

http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-00.tx
t
http://www.ietf.org/internet-drafts/draft-yegani-gre-key-extension-02.txt
http://www.ietf.org/internet-drafts/draft-tsirtsis-l2gre-pmipv4-00.txt

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 14:35:38 +1000

Sri, 

This is a good start for discussion. In the spirit of listening, I'll
address some of those comments. 

 > traffic. We cant do such optimizations with BU/BA.

=> We discussed this already no? We said that you could encapsulate a ping
in IP or use a dst option if you want to save bytes. So there are many ways
of doing this, I don't see this as a Y2K equivalent.

 > ports for standard network services.

=> I'd appreciate some pointers to this problem. About 18 months ago I asked
for 6 ports and got them almost instantly. 

 > We need GRE tunnel header for various reasons, "when ever we
 > field is useful."

=> I've added quotes around the area that I'm responding to above
Are you seriously saying that whenever multiple flows are encapsulated in a
packet GRE is needed? 
If you are then I think this is flat wrong, factually it's wrong. I hope you
can either qualify that or change it or explain it better. 

I'll leave it with those comments for now to focus the discussion, I have
other comments on the rest of the text but let's do it piecemeal. 

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 12:09:14 +0200

Hesham Soliman wrote:
[...]
>> The comment was made, we can always extend DSMIP for supporting GRE
>> or other encapsulation modes. Then the issue of backward 
>> encapsulated packets, when some packets are encapsulated with a
>> thin header and some with out a thin header. So, the only 
>> mentioned, there is also an issue with the available reserved ports
>> for standard network services.
> 
> => I'd appreciate some pointers to this problem. About 18 months ago
> I asked for 6 ports and got them almost instantly.
>> 
>> We need GRE tunnel header for various reasons, "when ever we carry
>> multiple streams within a tunnel, the GRE header for its mature
>> header semantics, the key field and the sequence number field is
>> useful."
> 
> => I've added quotes around the area that I'm responding to above Are
> you seriously saying that whenever multiple flows are encapsulated in
> a packet GRE is needed? If you are then I think this is flat wrong,
> factually it's wrong. I hope you can either qualify that or change it
> or explain it better.

Another comment that was made is that _if_ the problem is to transport 
link-layer messages (something else than IP) over IP then GRE is not the 
only solution - L2TP does approximately that too; if I understand the 
comment correctly.

Thus _if_ we know the problem then we still have to choose between 
several solutions (muxing based on other things than the intermediary 
tagging header, GRE and L2TP).

But I'm not sure I understand very well the problem in the first place.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 08:19:59 -0700

Hi Hesham,

> of doing this, I don't see this as a Y2K equivalent.

Yes. Your suggestion will work ! A *minor* side affect is that,
if a user does a manual ping to the HA, the HA will not be
able to differentiate between the user ping to the DSMIP
ping, always DSMIP process gets all the packets. 

> for 6 ports and got them almost instantly. 

I will let Henrik answer the port number issue. As I mentioned, this
was noted by Henrik. 

> other comments on the rest of the text but let's do it piecemeal. 

When a tunnel carries multiple flows from different nodes, the
semantics of the outer GRE header are useful. That was my intended
comment. Now, I've cleary given the pointers as where its useful.

- In Proxy Mobile IPv6, when the MAG is supporting mobile nodes
  with overlapping private IPv4 addresses, we need a selector that
  can be used by the tunnel peers for differentiating the flows.

- I've given pointers to the three active drafts, using GRE and
  all are mobility related drafts, leveraging GRE header. George's
  draft uses GRE key as a way to identify the mobile flows inside.

My text above may not be convincing to you, but, the use of GRE is 
much more than what we think, IMHO. Just these 3 draft and the
support for GRE in MIP4, reflect the same.

Thanks
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 01:33:28 +1000

> ping, always DSMIP process gets all the packets. 

=> Well, sure, and it should. Just like a user ping in plain MIP might get
tunnelled unless you force the use of the CoA.

 >   draft uses GRE key as a way to identify the mobile flows inside.

=> Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed
for IPv4 networks with overlapping IP addresses and we discussed that before
(and it's typically used by the infrastructure not the host). None of that
applies here. I already said that if for some reason you need it in PMIP
then you can use it before the UDP header. Plus, why are we standardising
PMIP extensions in this WG? 

 > support for GRE in MIP4, reflect the same.

=> I know GRE is used but the use cases do not apply to our scenarios here.
Of course you can create a scenario where you use it from a host if you
really want to, my point is that we don't *need* it, as your earlier text
seemed to imply in no uncertain terms. How many hosts use GRE today? 

Hesham

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Jun 2007 12:00:41 -0500

Folks,

My apologies for the error in the count as well as having missed several
people from the count itself.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:03:21 +0300

Sri,

> traffic. We cant do such optimizations with BU/BA.

I don't see why not. First of all, you can always skip
a keepalive when there is other traffic. Secondly, you
can skip the entire contents and send an empty container.
Etc.

> mature header semantics, the key field and the sequence number

Hmm. Reading on...

>From your list, this sounds like the most valid reason. But are
there other ways to deal with this? Can you expand on the
requirement and describe why there are no other ways to
deal with it?

> c.) Carrying other protocol packets (Lets say, IPX packets)

This is not a very convincing use case. We can always encapsulate
L2TP etc. inside if we really want to.

> e.) Industry direction and related work, these are the active

Mumble. It is very clear that the Internet has many, many
tunneling schemes from here to eternity.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Jun 2007 08:24:42 -0700

> requirement and describe why there are no other ways to

IMO, GRE is the cleanest. I had looked at other options, it is
doable, but ugly. Anyone else knows more on this?

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 26 Jun 2007 00:28:52 -0700

Hi Jari,

> Sent: Friday, June 22, 2007 2:03 AM
> To: Sri Gundavelli
> Cc: 'Basavaraj Patil'; 'Henrik Levkowetz'; [email-masked]; 
> 'Mobile IPv6 Mailing List'

That's what I meant, when using a KA message, it can always
be skipped when there is traffic. The KA processing is not
expensive as compared to the use of BU/BA for the same purpose.

> requirement and describe why there are no other ways to

This is for supporting the overlapping private IPv4 address
scenario. As Vijay was saying, GRE is the most simplest way
to solve this. It has the proper semantics in the header,
such as GRE key etc. There are many MIP4 implementations that
use this mechanism for tagging the flows between the PDSN and
the HA.

> L2TP etc. inside if we really want to.

The scenario was about using about using MIP tunnel for routing
other traffic. L2TP cant be used, as it wont provide mobility. 

Regards
Sri