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

May be you intended to leverage the MEXT TS option, but it currently defines
it as a new option (TSM).

"4.3.  Traffic Selector mobility option (TS)

   The Traffic Selector is a new mobility option that carries the
   parameters used to match packets for a specific flow mobility
   binding.  The LMA MUST include 1 or more traffic selector mobility
   options in an FMI message."

On 8/9/10 4:05 PM, "Sri Gundavelli" <sgundave@cisco.com> wrote:

> 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" <cjbc@it.uc3m.es> 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 <sgundave@cisco.com>
>>>> To: Behcet Sarikaya <sarikaya@ieee.org>; cjbc@it.uc3m.es
>>>> Cc: netext@ietf.org
>>>> 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
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>>       
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext