Re: [netext] Needs of traffic spec. on MAG?

[Sri Gundavelli <[e-mail]>]

Hi Carlos,

I think, the issue is with the TS format field, in the Traffic Selector
Mobility option (new option defined by this spec). It has the numbering
space. But, does not do any allocations for the existing TS specs. Note that
this numbering space is different from the TS format field in Traffic
Selector sub-option defined in MEXT flow binding draft

Just as in MEXT flow mobility draft, we need to pre-allocate the types for
the TS format field, as part of this numbering space. I agree, we dont
include the message/format definition, but the identifier allocation is what
needed. Format is out of scope, but not the numbering space. We need unique
identity for each of the flow spec that can be carried over these options.


1. IPv4 Binary TS
2. IPv6 Binary TS
3. XYZ

Regards
Sri




On 8/9/10 9:08 AM, "Carlos Jesús Bernardos Cano" <[e-mail]> wrote:

> On Mon, 2010-08-09 at 08:33 -0700, Behcet Sarikaya wrote:
>> Hi Sri,
>>   That is not really the point.
>> 
>> The point is that Flow Identification Mobility Option
>> defined in draft-ietf-mext-flow-binding-06
>> has a sub-option called
>> Traffic Selector sub-option
>> 
>> which can carry the TS.
>> 
>> This is to Carlos:
>> Why are we reinventing the wheel? The sub-option has already been defined
>> there 
>> (in Section 
>> 
>> 4.2.1.4.)!
> 
> We are not reinventing. We are reusing. It is the same option. We could
> even not include the format in the next revision of the flow mobility
> draft. The only goal of putting them it was to provide some context in
> the -00 version of the draft and to mention that the binary formats
> defined in draft-ietf-mext-binary-ts could be used.
> 
> Carlos
> 
>> 
>> 
>> 
>> Cheers,
>> 
>> Behcet
>> 
>> ----- Original Message ----
>>> From: Sri Gundavelli <[e-mail]>
>>> To: Behcet Sarikaya <[e-mail]>; [e-mail]
>>> Cc: [e-mail]
>>> Sent: Sat, August 7, 2010 2:38:51 PM
>>> Subject: Re: [netext] Needs of traffic spec. on MAG?
>>> 
>>> Hi Behcet:
>>> 
>>>>> You are right, we have to leverage the work done in  MEXT. The  Traffic
>>>>> Selectors for IPv4 and IPv6 flows can be  from the mext binary TS  work. I
>>>>> think, Carlos did provide the  TS option with a opaque field for
>>>>> including
>>>>> the filter. 
>>>> 
>>>> Current definition is only allowing TS like binary TS of  George to be
>>>> used.
>>>> There could be others like language based flow  descriptions proposed in
>>>> the
>>>> past. Is this reusing mext work?
>>>> 
>>>> 
>>> 
>>> Sure. Currently, as you say, George's IPv4 and IPv6 binary  traffic
>>> selectors
>>> are referenced as traffic selectors. However, Carlos chose  a variable
>>> length
>>> TS field, so in future we can write Traffic Selectors in  English, Spanish,
>>> Turkish ... So, if you have one, just write that selector  in your favorite
>>> metalanguage and carlos can point to  that.
>>> 
>>> 
>>> 
>>> Sri
>>> 
>>> 
>>> 
>> 
>> 
>>