Subject: [Mip6] Issue 93 - way forward

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 1 Jul 2007 14:27:17 +1000

Folks, 

Some of the people involved in the recent discussions on issue 93, the
NETLMM chairs and the AD had a teleconference a few days ago to discuss how
to address the lack of concensus on this issue. The aim of the meeting was
to find a way of accomodating both sides with one solution that avoids the
technical inefficiency/lack of flexibility concerns of both sides.

The following is a summary of what we agreed on in the meeting. 

The agreement was to define a way of handling both cases (presence of TLV or
not). To do that two different mechanisms were proposed, I'll list a summary
of each one below. 

1. Implicit signalling

The idea is to use the first byte after the UDP header to switch on whether
the following header is IP (v4 or v6) or a TLV header. Effectively, the
first byte is the version field of the IP header. versions 4 or 6 have the
obvious meaning, for the TLV header we can use one of the version numbers
that are not used today like 0 or 1. So for instance, 0 means TLV, 4 means
IPv4, and 6 means IPv6. 
Jari mentioned that this is used by other protocols like MPLS and it is
considered a hack by some people on the IESG but in our case we use a
specific port number for DSMIP therefore no one who does not implement the
DSMIP spec should receive this. 

So, when using this alternative, the TLV would look something like this:

Format (1byte) Type (1byte)  Length (2 bytes)

Format is just a bad name I use in this email to indicate that this byte is
used to identify the format of the following information (IP header or TLV)

Type is the message type 
length is the message length

2. Explicit signalling

In this mechanism we define a new flag in the BU that, when set, indicates
that the MN/MR wants to use the following format:
  IP
  UDP
  TLV
   ...etc
when the flag is cleared, it indicates the the MN/MR wants to use the
following format:
  IP
  UDP
  ...etc (i.e. no TLV). 

Obviously when using this mechanism there must be a default mechanism for
sending the BU itself. I.e., we can always send the BU in the current UDP
encapsulation format witohut the TLV but if the request is accepted then
data packets are sent as agreed during the BU/BA exchange. 

In either solution we will have to mandate that both the HA and the MN
support the negotiation mechanism and one default format. So, all
implementations have to support the current format of UDP encapsulation as a
base. This allows for interoperability. 

In this alternative there is no need for the Format field in alternative 1,
we only need to define Type and Length fields with one byte reserved.

Hesham

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 1 Jul 2007 14:31:27 +1000

Sorry, I forgot to mention the obvious, please send your comments ASAP so I
can update the draft. 

Hesham 

 > -----Original Message-----
 > From: Hesham Soliman [mailto:[email-masked]] 
 > Sent: Sunday, July 01, 2007 2:27 PM
 > To: [email-masked]; [email-masked]
 > Subject: [Mip6] Issue 93 - way forward
 > 
 > Folks, 
 >

---

From: <[email-masked]>
Date: Mon, 2 Jul 2007 12:58:17 +0300

Hi,

Nice to see this issue finally moving forward. 
So in mechanism 1, how would the MN signal the HA when to use TLV? Would
the MN just start using the TLV
option and the HA enables it as well when the first TLV tunneled packet
is received from the MN? How does the MN even
know the HA supports the TLV unless the support in mandated? ICMP error?
Error code in BACK?

I'm leaning towards the explicit signalling. IMHO, having the new flags
in BU/BACK is much cleaner approach.

Cheers,
Markku

>From: ext Hesham Soliman [mailto:[email-masked]] 
>Sent: 01 July, 2007 07:27
>Subject: [nemo] Issue 93 - way forward
>
>Folks, 
>
>Some of the people involved in the recent discussions on issue 
>93, the NETLMM chairs and the AD had a teleconference a few 
>days ago to discuss how to address the lack of concensus on 
>this issue. The aim of the meeting was to find a way of 
>accomodating both sides with one solution that avoids the 
>The agreement was to define a way of handling both cases 
>(presence of TLV or not). To do that two different mechanisms 
>were proposed, I'll list a summary of each one below. 
>
>1. Implicit signalling
>
>The idea is to use the first byte after the UDP header to 
>switch on whether the following header is IP (v4 or v6) or a 
>TLV header. Effectively, the first byte is the version field 
>of the IP header. versions 4 or 6 have the obvious meaning, 
>for the TLV header we can use one of the version numbers that 
>are not used today like 0 or 1. So for instance, 0 means TLV, 
>4 means IPv4, and 6 means IPv6. 
>Jari mentioned that this is used by other protocols like MPLS 
>and it is considered a hack by some people on the IESG but in 
>our case we use a specific port number for DSMIP therefore no 
>one who does not implement the DSMIP spec should receive this. 
>
>Format is just a bad name I use in this email to indicate that 
>this byte is used to identify the format of the following 
>information (IP header or TLV)
>
>Type is the message type
>In this mechanism we define a new flag in the BU that, when 
>set, indicates that the MN/MR wants to use the following format:
>  IP
>  UDP
>  TLV
>   ...etc
>when the flag is cleared, it indicates the the MN/MR wants to 
>use the following format:
>  IP
>  UDP
>  ...etc (i.e. no TLV). 
>
>Obviously when using this mechanism there must be a default 
>mechanism for sending the BU itself. I.e., we can always send 
>the BU in the current UDP encapsulation format witohut the TLV 
>but if the request is accepted then data packets are sent as 
>agreed during the BU/BA exchange. 
>
>In either solution we will have to mandate that both the HA 
>and the MN support the negotiation mechanism and one default 
>format. So, all implementations have to support the current 
>format of UDP encapsulation as a base. This allows for 
>interoperability. 
>
>In this alternative there is no need for the Format field in 
>alternative 1, we only need to define Type and Length fields 
>with one byte reserved.
>
>
>Hesham
>
>
>
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 2 Jul 2007 21:54:22 +1000

> know the HA supports the TLV unless the support in mandated? 

=> There is no signalling in this option, the packet is just parsed based on
the first byte. If the HA doesn't support the TLV then it would have to send
an ICMP error. You can't send an error in the BA because the error is in the
data flow, which happens after the BU/BA.

 > in BU/BACK is much cleaner approach.

=> I think it's cleaner too. 

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 3 Jul 2007 11:12:50 +0200

Hi Hesham, 

Speaking of obvious, I guess we need to make sure we word this 'the
first nibble' as opposed to the first byte, since we are talking about
the version which is only the first 4 bits of the payload within UDP :)

> > that the MN/MR wants to use the following format:

Does the tunnel IP mean IPv4 only or do you plan to specify it for both
families? I'm just concerned that we might not be symmetrical, which was
a strong point of your original draft.

Pascal

>Sent: Saturday, June 30, 2007 9:31 PM
>To: 'Hesham Soliman'; [email-masked]; [email-masked]
>Subject: RE: [Mip6] Issue 93 - way forward
>
> > (presence of TLV or
> > switch on whether
> > set, indicates
> > mechanism for
> > and the MN
> > alternative 1,

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 3 Jul 2007 19:45:35 +1000

> the version which is only the first 4 bits of the payload 

=> Right, once I get a clear idea of which option we're going for we can
name things accordingly. So far there was one preference mentioned for
option 2. Can you say which one you prefer? 

 > families? 

=> To avoid confusion, the text you quoted above was listing the order of
headers not the different tunnel types. But to answer your question, the
tunnel IP would cover both the same way we have it today. So IP/UDP/IP works
regardless of the IP version. I think the same can be done for the TLV but I
suspect people would want to define different types for the Type field. 

Hesham

I'm just concerned that we might not be 
 > symmetrical, which was
 > >Sorry, I forgot to mention the obvious, please send your 
 > comments ASAP
 > so I
 > >can update the draft.
 > >
 > >Hesham
 > >
 > > > considered a hack by some people on the IESG but in our 
 > case we use
 > a

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 3 Jul 2007 19:55:41 +1000

Folks, 

Please express a choice, preferrably with reasons for one of the two options
below. I'd really like to get this in the draft before the deadline. 

Thanks, 
Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 3 Jul 2007 13:03:00 +0200

Hi Hesham:

Option 1 is fine with me. Note that we could collapse the format and the
type by keeping the type less than x45 which leave ample space to define
many TLVs. We have to define the error case when the HA does not support
a TLV from the MN which is compatible with eth case when the HA supports
only IPv4 and IPv6.

OTOH, option 2 seems to demand that we define the interaction if one end
supports one value of the flag and the other end does not, on top of the
case where a given value for the TLV type is not supported by one party.
Usually that ends up with requesting that the HA supports both and be
more complex.

Do I miss something?

Pascal

>Sent: Tuesday, July 03, 2007 11:56 AM
>Subject: [nemo] RE: [Mip6] Issue 93 - concensus call
>
>Folks,
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 3 Jul 2007 21:20:11 +1000

> a TLV from the MN which is compatible with eth case when the 

=> Yes that goes back to the previous comment made about option 1. I think
the error case would have to be an ICMP message because this is an error on
the data path not the signalling path. 

 > supports one value of the flag and the other end does not, 

=> No, it doesn't do that, our suggestion from the conference call was to
have 
a base format that MUST always be supported, in addition to the negotiation
mechanism. 
I'll record your preference for option 1 though unless you change it. 

Hesham