Subject: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.txt

From: Yungui Wang <[email-masked]>
Date: Fri, 07 Aug 2009 09:54:08 +0800

Hello 

I had sent below comment at before. Re-forwarding it here. Welcome
your clarification. Thanks.

1, Could the IPv4/IPv6 binary traffic selector sub-options be
encoded as the TLV/TV (type, length, value) format?
Consideration: TLV/TV format can save size of message.
case 1, It may be not necessary to describe the traffic which
includes all the parameters in the sub-option. e.g. the traffic is
described as "UDP 21"
case 2, On the other hand, one parameter may appear multiple times
in the sub-option to describe the traffic. e.g. the traffic
includes two flow which may be presented as TCP port 5000 and
5002.

2,  Could the Ethernet service flow description sub-option be also
introduced in this document? 
Consideration: 
The Ethernet service sub-option is senseful when Ethernet service
is supported by MIP (referring to
http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt ). 

The format of the Ethernet serice sub-option can be:

- Ethernet serice sub-option (TLV/TV format)
0x01   48bit,source MAC address
0x02   48bit,destination MAC address
0x03   16bit,ethernet type
0x04   16bit,vlan tag

- Ethernet serice sub-option (proto header format)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|E|V|       Reservered      |   (S) Source MAC Address      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    (S) Source MAC Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 (D)Destination MAC Address                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(D)Destination MAC Address     |   (E) Ethernet Type           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        (V) VLAN tag           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B.R.
Yungui

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 7 Aug 2009 04:46:14 -0400

> includes two flow which may be presented as TCP port 5000 and

GT> I am not sure I understand. The existing format would result to
(using IPv4 TS for the example):
-  case 1: in a 2+5byte suboption since only B flag  (Protocol=UDP),
and I flag (Dst port low=21) would be set
- case 2 in 2+7byte suboption since B flag  (Protocol=UDP),  I flag
(Dst portlow=5001), and K flag (Dst portlow=5001) would be set.
How does the TLV/TV format allow for more efficient packing?

> - Ethernet serice sub-option (proto header format)

GT> Given that draft-wu-mip4 is not a WG draft yet I do not think it
makes sense to start adding TSs for this already in a WG doc.

---

From: Yungui Wang <[email-masked]>
Date: Mon, 10 Aug 2009 08:40:15 +0800

Hello

Got it. Thanks. However, in case 2, I mean that there needs
multiple TS(s) for the non-continuous ports based traffic flows. 
In addition, it seems that the destination address is not required
to be defined in the TS? Isn't the MN's HoA? The HA always knows
it.

B.R.
Yungui

> -----Original Message-----
> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Friday, August 07, 2009 4:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: FW: [MEXT] Comments to
draft-ietf-mext-binary-ts-00.txt
> > 1, Could the IPv4/IPv6 binary traffic selector sub-options 
> be encoded 
> > as the TLV/TV (type, length, value) format?
> > case 1, It may be not necessary to describe the traffic 
> which includes 
> > all the parameters in the sub-option. e.g. the traffic is 
> described as 
> > "UDP 21"
> > case 2, On the other hand, one parameter may appear 
> multiple times in 
> > the sub-option to describe the traffic. e.g. the traffic 
> includes two 
> > flow which may be presented as TCP port 5000 and 5002.
> >
> 
> -  case 1: in a 2+5byte suboption since only B flag  
> (Protocol=UDP), and I flag (Dst port low=21) would be set
> - case 2 in 2+7byte suboption since B flag  (Protocol=UDP),  
> I flag (Dst portlow=5001), and K flag (Dst portlow=5001) would
be set.
> > 2, ?Could the Ethernet service flow description sub-option be
also 
> > The Ethernet service sub-option is senseful when Ethernet 
> service is 
> > supported by MIP (referring to 
> > 0x01 ? 48bit,source MAC address
> > 0x02 ? 48bit,destination MAC address
> > 0x03 ? 16bit,ethernet type
> > 0x04 ? 16bit,vlan tag
> >
> > ?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
> >
> > |S|D|E|V| ? ? ? Reservered ? ? ?| ? (S) Source MAC Address ? ?
?|
> > | ? ? ? ? ? ? ? ? ? ?(S) Source MAC Address ? ? ? ? ? ? ? ? ?
? |
> > | ? ? ? ? ? ? ? ? (D)Destination MAC Address ? ? ? ? ? ? ? ? ?
?|
> > |(D)Destination MAC Address ? ? | ? (E) Ethernet Type ? ? ? ?
? |
> > | ? ? ? ?(V) VLAN tag ? ? ? ? ? |

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 10 Aug 2009 08:54:15 -0400

> multiple TS(s) for the non-continuous ports based traffic flows.

GT> True, for non-continuous ports you need multiple TSs, but can we
do better than that?

> to be defined in the TS? Isn't the MN's HoA? The HA always knows

GT> If the MN supports NEMO then you might want to identify specific
IP address even for destination..

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 10 Aug 2009 10:32:21 -0700

Folks,

I was reading the IPsec mailing list and found two interesting excerpts w.r.t. flow TS. 

Tero Kivinen wrote:
> When defining traffic selectors it should be noted, at as RFC4301 supports decorrelated 
> policies all the traffic selectors should be such that they can be used to express full 
> ranges. The current traffic selectors are not doing that and that has caused problems as 
> there is no way to explain hole without lots of entries.
>
> I.e. if you have two overlapping traffic selectors which one is very specific (down to ip,
> protocol and port) and other is more generic (for example any port) the current traffic 
> selector set cannot efficently express that, as the more generic traffic selector will 
> have one hole in the middle, and as formats 7 and 8 do not have protocol ranges, there is 
> no way to efficiently express protocols 0 .. n-1 and n+1 .. 255.
>
> This SHOULD NOT be repeated in any new traffic selectors. All new traffic selectors should 
> have ranges for all fields.

Steve Kent wrote:
> The protocol number example refers to the fact that we cannot express protocol  number 
> ranges in IKE, and that caused us to remove support for this feature from IPsec. I agree 
> with Tero that, going forward, we should require support for ranges of values for ALL new 
> TS values that we define.

I'm feeling we should follow this design guidelines, and start to make all fields in TSs as range.

What do people think?

--julien