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

Yungui Wang <w52006@huawei.com> Mon, 10 August 2009 00:40 UTC

Return-Path: <w52006@huawei.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC5D3A6864 for <mext@core3.amsl.com>; Sun, 9 Aug 2009 17:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.214
X-Spam-Level:
X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, MANGLED_SIDE=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxX7ZqEbFb-5 for <mext@core3.amsl.com>; Sun, 9 Aug 2009 17:40:14 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8B9793A6861 for <mext@ietf.org>; Sun, 9 Aug 2009 17:40:14 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO400MNCXV42C@szxga04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO400MQJXV4NJ@szxga04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST)
Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO400IA8XV3G7@szxml04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST)
Date: Mon, 10 Aug 2009 08:40:15 +0800
From: Yungui Wang <w52006@huawei.com>
In-reply-to: <d3886a520908070146g56631fe8p7ff638a1bce9f99d@mail.gmail.com>
To: 'George Tsirtsis' <tsirtsis@googlemail.com>
Message-id: <00de01ca1953$213a9db0$110ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcoXPNfUMNjdU55WSYGwbj9Vckh82gABIQwA
Cc: mext@ietf.org
Subject: Re: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: w52006@huawei.com
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 00:40:15 -0000

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:tsirtsis@googlemail.com] 
> Sent: Friday, August 07, 2009 4:46 PM
> To: w52006@huawei.com
> Cc: mext@ietf.org
> Subject: Re: FW: [MEXT] Comments to
draft-ietf-mext-binary-ts-00.txt
> 
> On Thu, Aug 6, 2009 at 9:54 PM, Yungui Wang<w52006@huawei.com>
wrote:
> > 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.
> >
> 
> 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?
> 
> > 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
> >
> 
> 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.
> 
> >
> >
>