Subject: [nemo] RE: [Mip6] RE: Issue 93 - resolution

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 7 Jul 2007 21:29:14 +1000

Ok, it looks like we're going with alternative 2. Thanks for all your input.

I'll submit the draft this weekend with this issue's resolution included. 

I talked to Jari about what to do with his review of issue 73 and he
suggested I submit the draft with all the other issues fixed. So whenever he
comes back with a resolution for it I can update the draft and announce it
on the list (i.e. even if I submit another version after the deadline). We
don't have any other outstanding issues. 

Thanks,
Hesham

 >  > > 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
 >  > >  > 
 >  > > 
 >  > > 
 >  > > 
 >  > > _______________________________________________
 >  > > Mip6 mailing list
 >  > > [email-masked]
 >  > > https://www1.ietf.org/mailman/listinfo/mip6
 >  >