Subject: [nemo] RE: Issue 93 - way forward

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 5 Jul 2007 22:46:39 +1000

Folks, 

With the deadline fast approaching, I'd like to remind everyone to express a
choice, or a "don't care" about this issue. Given the contrast between the
amount of emails on this issue before Vs now, I'm inclined to assume that a
lot of people who participated before don't care which alternative we go
for. 

So just to be clear, the options are:
Alternative 1
Alternative 2
Don't care

So far we had one opinion for alt 1 and another for alt 2. 

Personally, I prefer 2 because it's clearer and doesn't allow for a seamless
switch between the two packet formats on a per-packet basis. I think that
makes things more predictable for tunnel setup at the HA. I'm also less
comfortable with the generic ICMP error response from the HA when the MN
sends a packet in a format that is not supported by the HA. I think using
the BU to signal which format should be used is cleaner. 

My 2 cents.

Hesham

PS: If we get a lot of "don't care" then I'll ask the chairs/AD to make the
decisions for us.  

 > -----Original Message-----
 > From: Hesham Soliman [mailto:[email-masked]] 
 > Sent: Sunday, July 01, 2007 2:27 PM
 > To: [email-masked]'; [email-masked]'
 > Subject: 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 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
 >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 5 Jul 2007 07:04:02 -0700

I prefer to use an explicit signaling mechanism (Alt 2) as well.  

Vidya

> Sent: Thursday, July 05, 2007 5:47 AM
> To: 'Hesham Soliman'; [email-masked]; [email-masked]
> Subject: [Mip6] RE: Issue 93 - way forward
> 
> Folks, 
> 
> With the deadline fast approaching, I'd like to remind 
> everyone to express a choice, or a "don't care" about this 
> issue. Given the contrast between the amount of emails on 
> this issue before Vs now, I'm inclined to assume that a lot 
> of people who participated before don't care which 
> alternative we go for. 
> 
> Personally, I prefer 2 because it's clearer and doesn't allow 
> for a seamless switch between the two packet formats on a 
> per-packet basis. I think that makes things more predictable 
> for tunnel setup at the HA. I'm also less comfortable with 
> the generic ICMP error response from the HA when the MN sends 
> a packet in a format that is not supported by the HA. I think 
> using the BU to signal which format should be used is cleaner. 
> 
> My 2 cents.
> 
> Hesham
> 
> PS: If we get a lot of "don't care" then I'll ask the 
> chairs/AD to make the decisions for us.  
> 
>  > From: Hesham Soliman [mailto:[email-masked]]  > 
> Sent: Sunday, July 01, 2007 2:27 PM  > To: [email-masked]'; 
> [email-masked]'
>  > a few days ago to discuss how to address the lack of  > 
> > a way of accomodating both sides with one solution that  > 
> avoids the technical inefficiency/lack of flexibility  > 
> concerns of both sides.
>  >
> > (presence of TLV or not). To do that two different  > 
> > 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. 
>  > 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
>  > 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: Vijay Devarapalli <[email-masked]>
Date: Thu, 05 Jul 2007 08:26:44 -0700

I prefer alternative 2.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Jul 2007 11:04:43 -0500

Since option 1 is contained and the proposed processing is very specific
to the case at hand, I support option 1.
That way we preserve one bit in the BU.

Regards,
Ahmad

> Sent: Thursday, July 05, 2007 7:47 AM
> Subject: [nemo] RE: Issue 93 - way forward
> 
> Folks, 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 5 Jul 2007 11:32:46 -0700

Hesham,

Sorry for the late reply on this.

Can you confirm, for option#2, the flag will be present in
the Binding Acknowledgment ? 

Thanks
Sri

> everyone to express a
> for a seamless

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 05 Jul 2007 14:48:16 -0700

> the Binding Acknowledgment ?

The flag would need to be echoed back in the binding acknowledgment.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 6 Jul 2007 12:58:57 +1000

Yes it has to be present in the BA. 

Hesham 

 > From: Sri Gundavelli [mailto:[email-masked]] 
 > Sent: Friday, July 06, 2007 4:33 AM
 > Subject: RE: [Mip6] RE: Issue 93 - way forward
 > 
 > Hesham,
 >

---

From: Jean Lorchat <[email-masked]>
Date: Fri, 06 Jul 2007 14:19:57 +0900

Dear all,

We are taking care of a Linux implementation of the DSMIP draft.
 From our point of view, alternative 1 seems better because
it does not require a kind of new state on the HA for
DSMIP operation. We did not think about issues related to changing
the encapsulated protocol (v4/v6/TLV) on a per-packet basis though.

Jean
(Nautilus6 Project)

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 6 Jul 2007 01:20:59 -0700

I agree Option#2 is cleaner and also disallowing encap mode
switch over on a per packet basis might be a good idea.

At the same time, I agree with Jean and Ahmad, it does not
introduce additional states, keeps the implementation simple.
We went over the flows as how the MN would ask for a specific
enap mode, in the presence/absence of NAT, in all cases
the explicit request appeared to be redundant, as the
acceptance of a specific encap mode and the NAT detection,
seem to implicitly dictate if TLV is required or not.

Its a tough call, but I'll go for Option#2. Just to keep
predictability in the operation and keep things explicit.

Sri

> Sent: Thursday, July 05, 2007 7:59 PM
> To: 'Sri Gundavelli'; [email-masked]; [email-masked]