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

From: Sri Gundavelli <[email-masked]>
Date: Sun, 01 Aug 2010 09:06:57 -0700

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. So, the semantics of the flow identification are from MEXT work,
which took lot of time. Now, how the filters are exchanged in PMIPv6
signaling is specific to this draft.

Sri

On 7/30/10 1:49 PM, "Behcet Sarikaya" <[email-masked]> wrote:

> Hi Carlos,

  What I don't understand is why we are not reusing great work
> already done in 
Mext WG? They defined Flow Identification Mobility Option.
> What is wrong in 
reusing this option? Many things are similar in PMIPv6.

> Why try to reinvent the wheel? Remember that one of the design decisions made
> 
for PMIPv6 was to reuse Mobile IPv6 as much as possible. There are a lot of
synergies we can get from such reuse. If you look a few years back, attempts
> to 
define totally new protocol for netlmm was not favored, PMIPv6 was
> selected 
instead.

Regards,

Behcet

----- Original Message ----
> From:
> Carlos Jesús Bernardos Cano <[email-masked]>
> To: Youn-Hee Han
> <[email-masked]>
> Cc: [email-masked]
> Sent: Wed, July 28, 2010 10:18:21
> AM
> Subject: Re: [netext] Needs of traffic spec. on MAG?
> 
> One more
> comment. As I mentioned in another e-mail to Julien,
> there might be  the
> need of making the MAG aware of the flow descriptions
> (traffic selector)  in
> case the MN is attached through different
> interfaces to the same MAG. In
> that case we might need some support and
> signaling to make the MAG aware of
> the interface that should be used to
> deliver packets of this flow to the
> MN.
> 
> Opinions?
> 
> Carlos
> 
> On Wed, 2010-07-28 at 15:06 +0200,  Carlos
> Jesús Bernardos Cano wrote:
> > Dear Youn-Hee,
> > 
> > On  Wed, 2010-07-28 at
> 21:43 +0900, Youn-Hee Han wrote:
> > > Dear  Bernardos,
> > > 
> > >  
> > >
> 
> > > I¹d like  to ask a question about
> > >
> ³draft-bernardos-netext-pmipv6-flowmob-00.²
> > > 
> > > In the  call
> procedure figure, I noticed that traffic specification is
> > >  delivered to
> MAG from LMA. 
> > > 
> > > I understand that the  specification should be
> managed at LMA to do a
> > > traffic filtering. 
> > > 
> > >  
> > > 
> > >
> However, is such a  traffic filtering still needed at MAG?
> > 
> > The MAG
> needs to know  the flow that is gonna be routed through it, so it
> > can
> insert the  required routing state.
> > 
> > > 
> > > IMHO, it is not  needed
> at MAG. If so, why is the specification
> > > delivered to  MAG?
> > 
> > This
> is something that can be discussed. The minimum info  required is
> > the MN's
> prefix of the moved flow, so the route is installed  at the MAG.
> > If finer
> control is required (e.g., prevent the MN send  flows through a
> > MAG that
> is not the one the LMA has setup flow mobility  state, or other
> > purposes),
> then the flow mobility (traffic selector,  e.g., 5-tuple)
> > should be
> delivered to the MAG.
> > 
> > > 
> > > Isn¹t sufficient that the home network
> prefix related to the  traffic
> > > is delivered to MAG?
> > 
> > That'd be
> the minimum  info. As mentioned before, the MAG may need the
> > whole flow
> definition,  and in that case the LMA has to deliver that
> > information to
> the  MAG.
> > 
> > Thanks,
> > 
> > Carlos
> > 
> > > 
> > >  
> > > 
> > >
> Youn-Hee Han
> > > 
> > >  
> > > 
> > > 
> > >
> _______________________________________________
> > > netext mailing  list
> >
> > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/netext
> > 
> >
> _______________________________________________
> > netext mailing  list
> >
> [email-masked]
> > https://www.ietf.org/mailman/listinfo/netext
> 
> -- 
>
> Carlos Jesús  Bernardos Cano     http://www.netcoms.net
> GPG FP: D29B 0A6A
> 639A  A561 93CA  4D55 35DC BA4D D170 4F67
> 

_______________________________________________
netext mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 04 Aug 2010 14:52:14 +0200

Exactly.

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 6 Aug 2010 13:21:16 -0700 (PDT)

----- Original Message ----
> From: Sri Gundavelli <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Sent: Sun, August 1, 2010 11:06:57 AM
> 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? 

>So, the semantics of the flow identification are from  MEXT work,

The real flow mobility work in mext was based on Flow Identification Mobility 
Option defined draft-ietf-mext-flow-binding-06.
If we don't reuse it we are missing the whole mext work and trying to reinvent 
the wheel.

 It is not signaling specifics.

Regards,

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 07 Aug 2010 12:38:51 -0700

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Aug 2010 08:33:16 -0700 (PDT)

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.)!

Cheers,

Behcet

----- Original Message ----
> Sent: Sat, August 7, 2010 2:38:51 PM

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 09 Aug 2010 09:06:36 -0700

Hi Behcet,

We can surely work on the leveraging the options, or updating the message
structure as needed. This is as part of evolving the WG document based on
the feedback. Carlos or others will not have any issue with that. Inputs
welcome.

Regards
Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 09 Aug 2010 18:08:12 +0200

> Why are we reinventing the wheel? The sub-option has already been defined there 

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

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 09 Aug 2010 16:05:24 -0700

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

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 09 Aug 2010 16:09:24 -0700

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."