Subject: [MEXT] Next steps with draft-ietf-mext-flow-binding

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2010 12:17:36 +0300

This draft was discussed in yesterday's IESG call. It is not yet 
approved, because there is one pending Discuss from Lars Eggert (see 
below). Please address it as follows:

>   DISCUSS-DISCUSS: There have been several revisions since Allison
>   Mankin's tsv-dir review, but it's unclear if the issues she raises
>   have resulted in text changes or where otherwise dealt with (there was
>   no follow-up email to the review.) Please clarify?
>   

I promised Lars that we'd send him a summary of the responses and 
changes. Please do so.

> Section 4.2., paragraph 11:
> >          This is an 8-bit unsigned priority field to indicate the
> >          priority of a particular option.
> ...
> >          FID-PRI MUST be unique to each of the flows
> >          pertaining to a given MN.  In other words, two FIDs MUST NOT be
> >          associated with the same FID-PRI value
>
>   DISCUSS: I may be misunderstanding this, but if FID-PRI must be unique
>   for all flows of an MN, and it's 8-bit, then there can only be 256
>   flows? That's awfully little.
>   

If this is true, that's worrisome. Can we expand the field or do 
something else to avoid limiting ourselves to 256 flows? 256 flows is 
quite little in the face of Ajax and so on...

> Section 4.2., paragraph 15:
> >             1 'Discard'.  This value indicates a request to discard all
> >             packets in the flow described by the option.  No BIDs are
> >             associated with this Action.  Care should be taken when
> >             using this Action as it will lead to disrupting applications
> >             communication.  Implementations may consider notifying
> >             impacted applications in mobile nodes.
>
>   DISCUSS: This action is turning MIP into a firewall control protocol.
>   

I'm not as worried about that as Lars is, but I also would suggest 
removing this part.

> Section 4.2.1.4., paragraph 13:
> >       A variable length field, the format and content of which is out of
> >       scope for this specification.  The traffic selector defined in
> >       [I-D.ietf-mext-binary-ts] is mandatory to implement.
>
>   DISCUSS: If it's mandatory to implement, then it needs to become a
>   normative reference (make this clear by s/mandatory to implement/MUST
>   be implemented/). I also don't understand what the purpose of this
>   specification is if this critical piece is left undefined? It can't
>   really be used without this, can it?
>   

I agree that the reference must be normative.

I am expecting a new revision and an e-mail detailing what we did based 
on Allison's review.

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 10 Sep 2010 19:34:18 +1000

> quite little in the face of Ajax and so on...

=> Well, it's certainly an issue for mobile routers. I think it's definitely
important to support more than 256 flows.

> I'm not as worried about that as Lars is, but I also would suggest

=> Agree on both accounts. I'm ok with removing this part. Although, I have
to say I don't see any problem with the Discard action. If it's a firewall
control protocol then it's the only one that works in a mobile environment
and that's ok with me.

Hesham

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 10 Sep 2010 11:03:48 -0700

I do not have a big problem with either of these suggestions but I need to check the impact of these changes to the draft. 

I will report in a few days, hopefully with an updated version.

Thanks
George

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: 10 September 2010 05:34
To: Jari Arkko; [email-masked]; [email-masked]
Cc: IESG; Lars Eggert
Subject: Re: [MEXT] Next steps with draft-ietf-mext-flow-binding

Hesham

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 13 Sep 2010 11:49:44 +0800

Hi,

I read through the draft again, and I have some additional questions,
Sorry for so late comments.

Section 4.2, about FID-PRI, I noticed there is a sentence of "This field
is needed in cases where two different flow descriptions in two 
different options overlap." I don't understand this well. It seems to me
that, if two flow binding of a given MN/MR are overlap, then FID-PRI is used
to set priority, otherwise FID-PRI is meaningless. So it is possible there
are
65535 flow binding and only 255 FID-PRI, as long as there is no flow binding
overlap. But I am not sure, when the FID-PRI is meaningless, how should we
deal with it. What value should the sender set and what operation should
the receiver take, and so on. Can we allocate value 0 to the meaningless 
FID-PRI (0 is reserved now)? 

Or, if we allocate one FID-PRI to each flow binding,
remove this Sentence (I mean the sentence of "this field is needed in cases
of ...")? But in this case, I found a similar option field, BID-PRI, 
it is 7-bit length, while BID is 16-bit length, I don't understand why we
take
different criterion for FID and BID?

Section 4.3
   o  FID-PRI: This field indicates the priority of the flow and is used
      to break the tie between overlapping flows.
FID-PRI indicates the priority of the binding, but not the priority of the
flow.

Section 4.2.1.3,
   The binding reference sub-option
   includes one or more BIDs defined in MCoA [RFC5648].  
Some text of this document show it is possible that no BID is included in
Binding reference sub-option, such as section 4.2 action = Discard, and
List of section 4.3 BIDs N/A...

Last question, 
In a use case, where the MN doesn't support MCoA, or it has only one 
Interface, the MN wants to set a filter in its HA or maybe we can call it 
"flow-selective binding".
I mean the MN want the HA to discard packets from IP1 and want the 
HA to forward other packets to its binding care of address. In this case,
is the BID, which is created by MCoA specification, is mandatory?
Or need we support this use case in flow binding specification?

The detailed example, the list looks like,
 FID-PRI     FID    Traffic Selector    BIDs    Action     
 -------     ---    ----------------    ----    -------  
  xx        3       srcAddr=IPx       N/A     Discard  
  xx        2       srcAddr!=IPx      N/A     Forward 

another example is
FID-PRI     FID    Traffic Selector    BIDs    Action     
 -------     ---    ----------------    ----    -------  
  xx        3       TCP       N/A     Discard  
  xx        2       UDP       N/A     Forward

In section 4.2 of current draft, when action = Forward, it specifies
"One or more BIDs MUST be associated with this Action."
Shall we re-consider this? Or maybe I missed the discussion...

On the other hand, if we remove discard action from this document,
There is only forward action, do we need action field in this case?

Regards
Xiangsong

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tsirtsis, George
> Sent: Saturday, September 11, 2010 2:04 AM
> To: Hesham Soliman; Jari Arkko; [email-masked];
> [email-masked]
> Cc: IESG; Lars Eggert
> I do not have a big problem with either of these suggestions but I need to
check
> the impact of these changes to the draft.
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 13 Sep 2010 14:07:15 +1000

> FID-PRI (0 is reserved now)?

=> I'm not sure part is confusing so I'll start from the beginning. If you
have two flows, flow1 and flow2, where flow1 is defined as: src=any,
dst=HoA, protocol=TCP action: forward to address X; and flow2 is defined as:
src=any, dst=HoA, portnum= 80, action: forward to address Y then obviously
flow1 and flow2 overlap. So when you see either one you need to decide which
action to take. The FID-PRI tells you which one to prefer.
If there is no overlap the FID-PRI will not need to be inspected explicity.
In practice, you would list those flows in the order of the FID-PRI and you
would naturally take the first action that matches a flow. Just like a
routing table. 

> different criterion for FID and BID?

=> Sorry, I can't understand the question.

> FID-PRI indicates the priority of the binding, but not the priority of the

=> True. 

> List of section 4.3 BIDs N/A...

=> action = discard is about to be removed from the doc.

> is the BID, which is created by MCoA specification, is mandatory?

=> Since action = discard is about to be removed, I guess this use case will
not apply. If anyone has issues with such removal please let us know. The
removal was requested during IESG review.

>  FID-PRI     FID    Traffic Selector    BIDs    Action

=> Good question. I think we should. The field allows us the extensibility
later in case we want to introduce new actions.

Hesham

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 13 Sep 2010 13:30:16 +0800

> If there is no overlap the FID-PRI will not need to be inspected
explicitly.

I know the meaning of overlap, here my question is,
If FID-PRI need not to be inspected explicitly, how should we deal with?
My suggestion is to allocate 0 to this FID-PRI.

> => Sorry, I can't understand the question.

I have no strong option on these two cases, FID-PRI for overlapped flow
binding or for general flow binding.
But if WG take FID-PRI for general flow binding, that sentence should be
removed, and I wonder why we take different criterion for FID-PRI and
BID-PRI (field length aspect).
This it to say, why we permit 16bit BID/7bit BID-PRI, but forbid 16bit
FID/8bit FID-PRI?  Loadsharing between BIDs is OK but loadsharing between
FIDs is not OK?

> removal was requested during IESG review.

I'm interested in this use case, but I'm OK for removing discard action.

> later in case we want to introduce new actions.

I'm not against keeping action field, in fact I have no idea on this issue.
I just remember another case, general notification draft of MIP4 WG. That
draft met some trouble at last because there is no clear use case, somebody
asked why we need it? (I'm sure Jari know well this issue.)
It is very similar here, imho. If we would extend it later, then what is the
potential possibility? Except forwarding and discarding, I can tell only
buffering.

Thanks and best regards
Xiangsong

> >> To: Jari Arkko; [email-masked];

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 13 Sep 2010 14:41:32 -0700

Thanks Xiangsong. I am in the process of finalizing a newer version which deals with all of this and also comments from Lars. I should be able to publish the new version tomorrow but see some comments inline

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]] 
Sent: 13 September 2010 01:30
To: 'Hesham Soliman'; Tsirtsis, George; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [MEXT] Next steps with draft-ietf-mext-flow-binding

explicitly.

GT> First of all the FID-PRI is being increased to 16bits, you will see this in the next version. I think some of this is implementation specific but the function of the FID-PRI is I think very simple and clear. Flow bindings are placed in an ordered list according to their FID-PRI. Each packet coming in is matched against flow blow bindings in the order defined by this list. The first match wins.

GT> The feeling is that 127 BIDs i.e., 127 concurrent connections to the Internet for a single device is more than enough.  I thought the same way about FIDs too but some like the option of many more concurrent flows given the possibility of Mobile Routers, where many MNs can be connected through them i.e., the scaling requirements for BIDs and FIDs is different. Also BID length is already set in RFC5648 which there is no point in changing to something smaller even if it would have been sufficient.

> > FID-PRI indicates the priority of the binding, but not the priority of
the

GT> Yes, thanks. Will fix this.

> => action = discard is about to be removed from the doc.

GT> Indeed.

GT. OK, good.

GT> There is no longer a point in having an Action field. I am removing it.

Thanks and best regards
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 14 Sep 2010 09:39:25 +0800

Thank you George, but I think there is a hidden issue.

You said,
> GT> The feeling is that 127 BIDs i.e., 127 concurrent connections to the
> Internet for a single device is more than enough.  I thought the same way
> about FIDs too but some like the option of many more concurrent flows
given
> the possibility of Mobile Routers, where many MNs can be connected through
> them i.e., the scaling requirements for BIDs and FIDs is different. Also
BID
> length is already set in RFC5648 which there is no point in changing to
> something smaller even if it would have been sufficient.

Let's focus on FID-PRI, if you set it 16 bits as for mobile router scenario,
what will happen?

In my mind, the scenario maybe looks like:

MN1-----------\
           MR==>-------HA-----------CN
MN2-----------/
MN.......

In this case, there are multiple care of address binding for each MN,
As you said, 127 connection between MR and HA is enough, I do agree this
point.

But when MR sets multiple flow binding for a given MN, and sets FID priority
separately, which BID is referenced?
When MR sets priority for each flow binding and relates FID to BID, we are
creating mapping between flow binding and CoA binding
If there are only 127 BIDs, how can we map 65535 prioritized flow binding to
127 prioritized CoA binding?
If we map multiple FID to one BID, what is the meaning of these FID-PRI?
I think, the CoA BID is the final exist, if we set priority in the middle
step (flow binding), but map these priority values to same result (CoA
binding),
I don't understand why we need it.

Best regards,
Xiangsong

> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Tuesday, September 14, 2010 5:42 AM
> To: Xiangsong Cui; 'Hesham Soliman'; [email-masked]; [email-masked];
> Thanks Xiangsong. I am in the process of finalizing a newer version which
deals
> with all of this and also comments from Lars. I should be able to publish
the
> new version tomorrow but see some comments inline
> 
> To: 'Hesham Soliman'; Tsirtsis, George; [email-masked];
[email-masked];
> > > that, if two flow binding of a given MN/MR are overlap, then FID-PRI
is
> used
> > > overlap. But I am not sure, when the FID-PRI is meaningless, how
should
> we
> GT> First of all the FID-PRI is being increased to 16bits, you will see
this in the
> next version. I think some of this is implementation specific but the
function of
> the FID-PRI is I think very simple and clear. Flow bindings are placed in
an
> ordered list according to their FID-PRI. Each packet coming in is matched
> against flow blow bindings in the order defined by this list. The first
match wins.
> GT> The feeling is that 127 BIDs i.e., 127 concurrent connections to the
> Internet for a single device is more than enough.  I thought the same way
> about FIDs too but some like the option of many more concurrent flows
given
> the possibility of Mobile Routers, where many MNs can be connected through
> them i.e., the scaling requirements for BIDs and FIDs is different. Also
BID
> length is already set in RFC5648 which there is no point in changing to
> something smaller even if it would have been sufficient.
> 
> >
> > >
> > >
> > > Section 4.3
> > >> I do not have a big problem with either of these suggestions but I
need
> to
> > >>>>>             1 'Discard'.  This value indicates a request to
discard
> > > all
> > >> => Agree on both accounts. I'm ok with removing this part. Although,
I
> > > have

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 19:35:09 -0700

Xiangsong,

In the NEMO scenario you depicted, the hosts left of the mobile router on your diagrams do not act as mobile nodes per-se, they are regular nodes, attached to the mobile network served by the mobile router. Thus the only care-of addresses involved are those of the mobile router, and the BIDs involved are those corresponding to those care-of addresses -- not the care-of / BIDs of the nodes attached to the mobile network.

Hope that clarifies.

--julien

> Xiangsong Cui
> Sent: Monday, September 13, 2010 6:39 PM
> To: Tsirtsis, George; 'Hesham Soliman'; [email-masked];
> [email-masked]; [email-masked]
> > > > Section 4.2, about FID-PRI, I noticed there is a sentence of
> "This
> field
> > > > different options overlap." I don't understand this well. It
> seems to
> me
> > > > to set priority, otherwise FID-PRI is meaningless. So it is
> possible
> > there
> > > > are
> > > > 65535 flow binding and only 255 FID-PRI, as long as there is no
> flow
> > binding
> > > => I'm not sure part is confusing so I'll start from the beginning.
> If
> you
> > > dst=HoA, protocol=TCP action: forward to address X; and flow2 is
> defined
> > as:
> > > flow1 and flow2 overlap. So when you see either one you need to
> decide
> > which
> > > In practice, you would list those flows in the order of the FID-PRI
> and
> > you
> > > > remove this Sentence (I mean the sentence of "this field is
> needed in
> > cases
> > > > it is 7-bit length, while BID is 16-bit length, I don't
> understand why
> > we
> > > > take
> > > >    o  FID-PRI: This field indicates the priority of the flow and
> is
> used
> > > > FID-PRI indicates the priority of the binding, but not the
> priority of
> > the
> > > > flow.
> > >
> > > => True.
> > >
> >
> > > > Some text of this document show it is possible that no BID is
> included
> > in
> > > > Binding reference sub-option, such as section 4.2 action =
> Discard,
> and
> > > > Interface, the MN wants to set a filter in its HA or maybe we can
> call
> > it
> > > > HA to forward other packets to its binding care of address. In
> this
> > case,
> > > => Since action = discard is about to be removed, I guess this use
> case
> > will
> > > not apply. If anyone has issues with such removal please let us
> know.
> The
> > It is very similar here, imho. If we would extend it later, then what
> is
> the
> > GT> There is no longer a point in having an Action field. I am
> removing
> it.
> >
> > Thanks and best regards
> > Xiangsong
> >
> >
> > >
> > > Hesham
> > >
> > >
> > > >
> > > >
> > > > Regards
> > > > Xiangsong
> > > >
> > > >
> > > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > >> Tsirtsis, George
> > > >>>>   DISCUSS: I may be misunderstanding this, but if FID-PRI must
> be
> > > > unique
> > > >>>>   for all flows of an MN, and it's 8-bit, then there can only
> be
> 256
> > > >>> something else to avoid limiting ourselves to 256 flows? 256
> flows
> is
> > > >> => Well, it's certainly an issue for mobile routers. I think
> it's
> > > > definitely
> > > >>>>>             packets in the flow described by the option.  No
> BIDs
> > > are
> > > >>>>>             associated with this Action.  Care should be
> taken
> > when
> > > >> to say I don't see any problem with the Discard action. If it's
> a
> > firewall

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 14 Sep 2010 10:55:44 +0800

Thanks Julien,

Now I would like to change the picture to:

MNN1-----------\
MNN2-----------/
MNN.......

Left nodes are mobile network nodes, not mobile nodes.

But the operations of MR (CoA binding, flow binding, setting BID/FID
priority) are unchanged,
So my concerns are still there, how can we map 65535 priority levels to 127
priority levels?

For example, the lists (FID list & BID list) are:

    FID-PRI     FID    Traffic Selector    BIDs    Action       A/I
    -------     ---    ----------------    ----    -------     ------
       10        4           TCP            2      Forward      Active
       20        3       srcAddr=IPx        5     Discard      Active
       30        2       srcAddr=IPy        3,4      Forward      Inactive
       40        5           UDP           1       Forward      Active

BID-PRI      BID    CoA      etc.
-------        ---      ----
2           2
2           1
3           3
4           4
5           5

We map FID 4 to BID 2, and map FID 5 to BID 1.
Although FID 4 and FID 5 have different priority level, but BID 1 and BID 2
share the same priority level, all their traffic are routed to the same CoA
(i.e. BID),
So, in this case, what is the meaning of FID-PRI of FID 4 and FID 5?

We are facing a strange mapping, from 65535 priority (i.e. bigger space) to
127 priority (i.e. smaller space), that is my concern.

Thanks and regards,
Xiangsong

> From: Laganier, Julien [mailto:[email-masked]]
> Sent: Tuesday, September 14, 2010 10:35 AM
> To: Xiangsong Cui; Tsirtsis, George; 'Hesham Soliman';
[email-masked];
> In the NEMO scenario you depicted, the hosts left of the mobile router on
your
> diagrams do not act as mobile nodes per-se, they are regular nodes,
attached
> to the mobile network served by the mobile router. Thus the only care-of
> addresses involved are those of the mobile router, and the BIDs involved
are
> those corresponding to those care-of addresses -- not the care-of / BIDs
of the
> nodes attached to the mobile network.
> 
> Hope that clarifies.
> 
> --julien
>

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 14 Sep 2010 11:03:46 +0800

Sorry, there is a mistake in my example statement, I will update it and
repost the example to you!

Xiangsong

> From: Xiangsong Cui [mailto:[email-masked]]
> Sent: Tuesday, September 14, 2010 10:56 AM
> To: 'Laganier, Julien'; 'Tsirtsis, George'; 'Hesham Soliman';
> [email-masked]'; [email-masked]';
> [email-masked]'
> Cc: [email-masked]'
priority)
> are unchanged,
>        10        4           TCP            2      Forward
> Active
>        40        5           UDP           1       Forward
> Active
> Although FID 4 and FID 5 have different priority level, but BID 1 and BID
2 share
> the same priority level, all their traffic are routed to the same CoA
(i.e. BID),
> We are facing a strange mapping, from 65535 priority (i.e. bigger space)
to 127
> priority (i.e. smaller space), that is my concern.
> 
> Thanks and regards,
> Xiangsong
> 
[email-masked];
attached
are
> > those corresponding to those care-of addresses -- not the care-of / BIDs
of
> > > > Internet for a single device is more than enough.  I thought the
same
> > > way
> > > > > > that, if two flow binding of a given MN/MR are overlap, then
FID-
> > > PRI
> > > > > > deal with it. What value should the sender set and what
operation
> > > > But if WG take FID-PRI for general flow binding, that sentence
should
> > > > Internet for a single device is more than enough.  I thought the
same
> > > way
> > > > > >> I do not have a big problem with either of these suggestions
but

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 14 Sep 2010 11:53:19 +0800

I carefully consider this problem again, I found it is not a real problem.
But I still want to make sure my understanding here.

For the firstly created BID list, if it is:

 BID-PRI      BID    CoA      etc.
 -------        ---      ----
 1           1
 2           2
 3           3
 3           4
 3           5

Then, for the FID lists,

FID-List 1:
 FID-PRI     FID    Traffic Selector    BIDs           A/I
 -------     ---    ----------------    ----    -------     
  10        4           TCP           xx           Active
  20        3       srcAddr=IPx        xx           Active  
  30        2       srcAddr=IPy        xx            Active
  40        5           UDP           xx           Active
  50        6       srcPort=Portx       xx           Active
  60        7       desPort=Porty       xx           Active

FID-List 1 is OK, although it is a bigger-to-smaller mapping.

FID-List 2:
 FID-PRI     FID    Traffic Selector    BIDs           A/I
 -------     ---    ----------------    ----    -------     
  10        4           TCP            1,2         Active
  20        3       srcAddr=IPx        1,2         Active  
  30        2       srcAddr=IPy        1,2          Active
  40        5           UDP           1           Active
  50        6       srcPort=Portx       1           Active
  60        7       desPort=Porty       1           Active

FID-List 2 is also OK. 
My question here: For FID 2/3/4, only BID 1 would be chosen at last, right?
(because BID 1 is high priority then BID 2 )

FID-List 3:
 FID-PRI     FID    Traffic Selector    BIDs           A/I
 -------     ---    ----------------    ----    -------     
  10        4           TCP            1,2         Active
  20        3       srcAddr=IPx        1,2         Active  
  30        2       srcAddr=IPy        1,2          Active
  40        5           UDP           3,4,5      Active
  50        6       srcPort=Portx       3,4,5      Active
  60        7       desPort=Porty       3,4,5      Active

FID-List 3 is a bit special, but maybe still OK.
My question here: For FID 5/6/7 (with different priority), BID 3/4/5 would
be chosen, and the traffic forwarding are loadshared among the three CoAs,
right?
(BID 3/4/5 are with same BID-PRI,  Prioritized FID-PRI flow still may meet
flow loadsharing among interfaces.)

My general impression, the mobility node implementing MCoA and flow binding,
should be aware the bindings (CoA binding and flow binding), and its
expected forwarding interface/path.

A bit complex, but not protocol issue.

Do I understand the documents right now?

Thanks and best regards,
Xiangsong

[email-masked];
your
attached
are
of the

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Sep 2010 05:00:54 -0700

Xiangsong, when a flow binding indicates more than one BID then matching traffic is replicated and forwarded to all the BIDs listed. So in List 2, FIDs 2/3/4 will be forwarded to both BID 1 and 2, irrespectively of BID-PRI.
BID-PRI only affects traffic that does not match any specific flow binding, in which case it is forwarded to the highest priority BID.

George

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]]
Sent: 13 September 2010 23:53
To: Laganier, Julien; Tsirtsis, George; 'Hesham Soliman'; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [MEXT] Next steps with draft-ietf-mext-flow-binding

 BID-PRI      BID    CoA      etc.
 -------        ---      ----
 1           1
 2           2
 3           3
 3           4
 3           5

Then, for the FID lists,

FID-List 1:

FID-List 2:

FID-List 2 is also OK.

FID-List 3:

Thanks and best regards,
Xiangsong

[email-masked];
your
attached
are
of the

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Sep 2010 06:47:32 -0700

Hi Jari/Lars, et.al.,

I just submitted v10 of the draft handling Lars's comments. See inline:

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: 10 September 2010 05:18
To: [email-masked]; [email-masked]
Cc: IESG; Lars Eggert
Subject: Next steps with draft-ietf-mext-flow-binding

GT> several days ago I forwarded to Lars my response to Alisson's comments but I summarize below. 
- Accepted Alisson's suggestion and now the binary traffic selector draft is referenced and mandated for interop reasons. In the latest version I made it a normative reference based on Lars/Jari's suggestion.
- Alisson suggested that 255 TS types might not be enough but this was discussed in the WG and it was felt that an additional Sub-option Type can be defined at a later time for additional TS types if needed. Remember these are 255 different languages for *defining* a flow. 
- Alisson questioned whether a single FID Summary option is sufficient. Initially I thought that 128 FIDs are plenty. Based on Lars's comments though I changed the FID-PRI to allow for more active FIDs in support of MRs, which meant that I also had to allow multiple FID Summary options for the same reason. 
- The security considerations section was beefed up based on Alisson's and other peoples' comments.
- Alisson also spotted a number of Nits which we fixed 

GT> As I said above I extended the field to 16bits, thankfully we have space w/o having to change the structure of the option.

GT> I removed this Action, which means that the only Action defined is 'Forward', which is pointless and makes the spec read really strange. Given this I dropped the Action field, turning it into 'reserved' bits. This resulted in some editing which generally simplified a number of explanations.

GT> I made it a normative reference. There is a story about why TS formats is outside this draft but I will not bore you with it.

GT> I hope this e-mail and the new version satisfies all the comments/suggestions we received.

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 14 Sep 2010 22:12:31 +0800

OK, I see, thank you for your patient explanation!

Best Regards,
Xiangsong

----- 原邮件 -----
发件人: "Tsirtsis, George" <[email-masked]>
日期: 星期二, 九月 14日, 2010 下午8:01
主题: Re: [MEXT] Next steps with draft-ietf-mext-flow-binding
收件人: Xiangsong Cui <[email-masked]>, "Laganier, Julien" <[email-masked]>, 'Hesham Soliman' <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

> Xiangsong, when a flow binding indicates more than one BID then 
> matching traffic is replicated and forwarded to all the BIDs 
> listed. So in List 2, FIDs 2/3/4 will be forwarded to both BID 1 
> and 2, irrespectively of BID-PRI.
> BID-PRI only affects traffic that does not match any specific flow 
> binding, in which case it is forwarded to the highest priority BID.
> 
> George
> 
> To: Laganier, Julien; Tsirtsis, George; 'Hesham Soliman'; 
> [email-masked]; [email-masked]; draft-ietf-mext-flow-
> [email-masked]: [email-masked]
> I carefully consider this problem again, I found it is not a real 
> problem.But I still want to make sure my understanding here.
> 
> 
> > addresses involved are those of the mobile router, and the BIDs 
> involvedare
> Behalf Of
> > > > GT> The feeling is that 127 BIDs i.e., 127 concurrent 
> connections to
> > > the
> > > > Internet for a single device is more than enough.  I thought 
> the same
> > > way
> > > > the possibility of Mobile Routers, where many MNs can be 
> connected> > through
> > > > them i.e., the scaling requirements for BIDs and FIDs is 
> different.> > Also
> > > BID
> > > > length is already set in RFC5648 which there is no point in 
> changing> > to
> > > As you said, 127 connection between MR and HA is enough, I do 
> agree> > this
> > > point.
> > >
> > > But when MR sets multiple flow binding for a given MN, and 
> sets FID
> > > priority
> > > When MR sets priority for each flow binding and relates FID to 
> BID, we
> > > are
> > > If we map multiple FID to one BID, what is the meaning of 
> these FID-
> > > PRI?
> > > > Thanks Xiangsong. I am in the process of finalizing a newer 
> version> > which
> > > deals
> > > > with all of this and also comments from Lars. I should be 
> able to
> > > publish
> > > the
> > > > > > that, if two flow binding of a given MN/MR are overlap, 
> then FID-
> > > PRI
> > > is
> > > > used
> operation> > should
> > > > > => I'm not sure part is confusing so I'll start from the 
> beginning.> > If
> > > you
> > > > > src=any, dst=HoA, portnum= 80, action: forward to address 
> Y then
> > > obviously
> > > > > If there is no overlap the FID-PRI will not need to be 
> inspected> > > explicitly.
> > > >
> > > > If FID-PRI need not to be inspected explicitly, how should 
> we deal
> > > with?
> > > > GT> First of all the FID-PRI is being increased to 16bits, 
> you will
> > > see
> > > this in the
> > > > ordered list according to their FID-PRI. Each packet coming 
> in is
> > > matched
> > > > against flow blow bindings in the order defined by this 
> list. The
> > > first
> > > match wins.
> > > >
> > > >
> > > > > would naturally take the first action that matches a flow. 
> Just> > like a
> > > > > routing table.
> > > > >
> > > > > >
> > > > > > of ...")? But in this case, I found a similar option 
> field, BID-
> > > PRI,
> > > > I have no strong option on these two cases, FID-PRI for 
> overlapped> > flow
> > > > But if WG take FID-PRI for general flow binding, that 
> sentence should
> > > be
> > > > FID/8bit FID-PRI?  Loadsharing between BIDs is OK but 
> loadsharing> > between
> > > > FIDs is not OK?
> > > >
> > > >
> > > > GT> The feeling is that 127 BIDs i.e., 127 concurrent 
> connections to
> > > the
> > > > Internet for a single device is more than enough.  I thought 
> the same
> > > way
> > > > the possibility of Mobile Routers, where many MNs can be 
> connected> > through
> > > > them i.e., the scaling requirements for BIDs and FIDs is 
> different.> > Also
> > > BID
> > > > length is already set in RFC5648 which there is no point in 
> changing> > to
> > > > > > In a use case, where the MN doesn't support MCoA, or it 
> has only
> > > one
> > > > > > I mean the MN want the HA to discard packets from IP1 
> and want
> > > the
> > > > > > is the BID, which is created by MCoA specification, is 
> mandatory?> > > >
> > > > > > Or need we support this use case in flow binding 
> specification?> > > > >
> > > > > > Shall we re-consider this? Or maybe I missed the 
> discussion...> > > > >
> > > > > > On the other hand, if we remove discard action from this 
> document,> > > > > There is only forward action, do we need action 
> field in this
> > > case?
> > > > >
> > > > I'm not against keeping action field, in fact I have no idea 
> on this
> > > issue.
> > > > I just remember another case, general notification draft of 
> MIP4 WG.
> > > That
> > > > draft met some trouble at last because there is no clear use 
> case,> > somebody
> > > > potential possibility? Except forwarding and discarding, I 
> can tell
> > > only
> > > > buffering.
> > > >
> > > >
> > > > > >> I do not have a big problem with either of these 
> suggestions but
> > > I
> > > need
> > > > to
> > > > > > check
> > > > > >> I will report in a few days, hopefully with an updated 
> version.> > > > >>
> > > > > >> Thanks
> > > > > >> George
> > > > > >>
> > > > > >>> If this is true, that's worrisome. Can we expand the 
> field or
> > > do
> > > > > >> => Well, it's certainly an issue for mobile routers. I 
> think> > it's
> > > > > > definitely
> > > > > >>>>>             using this Action as it will lead to 
> disrupting> > > > > applications
> > > > > >>>>   DISCUSS: This action is turning MIP into a firewall 
> control> > > protocol.
> > > > > >>>>
> > > > > >>>
> > > > > >> control protocol then it's the only one that works in a 
> mobile> > > environment
> > > > > >> and that's ok with me.
> > > > > >>
> > > > > >> Hesham
> > > > > >>
> > > > > >>