Subject: [MEXT] Review of draft-ietf-mext-flow-binding-01

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 9 Mar 2009 15:37:29 -0700

Hi Hesham, All,

I went through draft-ietf-mext-flow-binding-01. There are some issues that need to be resolved in particular based on the latest version of the MCoA draft.

General comments:

- I think the interactions with rfc3775 compliant BUs should be captured in the document. For example what happens if the BC of the HA has two FID entries for HoA1 and then the MN sends a BU without any FID/BID but just with the CoA? I think the correct behavior is that the new BU will overwrite the BCE and the MN will go back in a rfc3775 operation mode. This should be allowed and captured in the MN and HA operations

- We should have a brief section about DSMIPv6 applicability in the same way we have it in the MCoA draft (section 8). My understanding is that the same considerations of MCoA draft apply (no bulk registration for an initial binding when IPv4 CoA is used in order to perform NAT detection)

- Section 6.4 needs more details based on the home link operation described in the latest version of the MCoA draft

- the draft assumes that FID option can be used without BID option. However based on the MCoA draft, a BU without a BID will replace all the BCEs which contain a BID. I think some alignment is required on this. Can we assume BID is always used when FID is used?

Detailed comments:

- Section 2: I would update the terminology as follows:

   Flow

      A flow is identified as a set of data packets that are exchanged

      between two distant hosts and can be univocally identified and grouped based on the Flow Description.

   Flow Description

      A set of instructions that describes and univocally identifies a flow.

- Section 3.2: the format of the Binding Reference Sub-option is not clear. I guess the assumption is that the field BID should point to a BID mobility option in the BU or to an existing entry in the BCE. It is not also clear based on the text in this section why a MN would include more than one BID for a specific FID: I think the motivation is to enable n-cast - in this case I would add that in this subsection to make it clearer.

- Section 4.1: the MCoA draft does not define any preferred or default CoA. The Priority field in the BID option was removed a few revisions ago. Therefore it is up to this draft to define a default CoA or a default binding. I think we have two possibilities:

1) we mandate that the MN always has a default binding with match-all filters

2) we allow the MN to not have a default binding. In this case there may be packets that do not match any FID in the BCE. The treatment of these packets at the HA may be left implementation dependant or we may mandate that packets that do not match any existing filters are discarded. The latter would allow the MN to avoid signaling blacklist flows.

The issue of the default binding requires changes also in other section of the draft (e.g. 4.3, 6.1). We should also understand what happens if a default FID is removed by the MN.

- Section 4.4:

   An Add operation implies that the FID is new and is not already used

   by the mobile node for any other flow binding.  If the Flow

   identification option is sent without any flow description and with

   the PRO field indicating an Add operation, this MUST be seen as a

   wild card request by the sender.  A wild card request implies that

   all flows should be directed to the particular care-of address in the

   packet.

The last statement is true only if there is not any other entry which matches an incoming packet and has higher priority. We should clarify that.

- Section 6.1.1:

   o  If the Action field is set to indicate N-cast, the Binding

      Reference sub-option must be present and it must contain one or

      more BIDs.  If the Binding Update sub-option includes only one

      BID, it must be pointing to a care-of address other than the one

      included in the binding update.

Based on this, the n-cast would be done between the CoA in the BID and the CoA in the source address of the packet. I think it would be much cleaner to always include all BIDs for which n-casting is requested. The source address of the packet is not processed as CoA when a BID is present based on the MCoA draft (similarly to what happens in case the Alt-CoA option is used). This comment applies also to the fourth bullet of section 8.1

- I think section 7 should be renamed to Correspondent Node operations

I have also some editorial comments but I will give them offline to authors.

Cheers

Gerardo

---

From: Christian Kaas-Petersen <[email-masked]>
Date: Tue, 10 Mar 2009 14:06:15 +0000 (GMT)

In my view, both the motivation (Hesham's comment) and the warning
(George's note) should find its way into the document.

Christian

--- Den tirs 10/3/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] Review of draft-ietf-mext-flow-binding-01
> Til: "Hesham Soliman" <[email-masked]>
> Cc: "Christian Kaas-Petersen" <[email-masked]>, "[email-masked]" <[email-masked]>
> Dato: tirsdag 10. marts 2009 12.00
> Yes, this could be appropriate for
> light UDP traffic e.g., VoIP ....
> some health warnings regarding flooding multiple links with
> traffic
> might be in-order.
> 
> George
> 
> On Tue, Mar 10, 2009 at 9:43 AM, Hesham Soliman
> <[email-masked]>
> wrote:
> >
> >
> >
> > On 10/03/09 8:34 PM, "Christian Kaas-Petersen" <[email-masked]>
> > wrote:
> >
> >>
> >> I should like to understand the motivation for
> N-cast.  Which application
> >> will have a need, when sending packets to a
> specific mobile node, for
> >> having its packets replicated and sent over N
> different links
> >> to a mobile node?
> >
> > => This is not an unusual handover smoothing
> technique. But you can also use
> > it for redundancy when multiple links exist.
> >
> > Hesham
> >
> >>
> >> Christian
> >>
> >>
> >> --- Den man 9/3/09 skrev Giaretta, Gerardo <[email-masked]>:
> >>
> >>> Fra: Giaretta, Gerardo <[email-masked]>
> >>> Emne: [MEXT] Review of
> draft-ietf-mext-flow-binding-01
> >>> Til: "[email-masked]"
> <[email-masked]>
> >>> Dato: mandag 9. marts 2009 23.37
> >>>
> >>>
> >>> - Section 6.1.1:
> >>>
> >>>
> >>>
> >>>    o  If the Action
> >>> field is set to
> >>> indicate N-cast, the Binding
> >>>
> >>>
> >>>       more
> >>> BIDs.  If the
> >>> Binding Update sub-option includes only one
> >>>
> >>>       BID,
> >>> it must be pointing
> >>> to a care-of address other than the one
> >>>
> >>>
> >>> included in the binding
> >>> update.
> >>>
> >>>
> >>>
> >>> Based on this, the n-cast would be
> >>> done between the CoA
> >>> in the BID and the CoA in the source address
> of the packet.
> >>> I think it would be
> >>> much cleaner to always include all BIDs for
> which n-casting
> >>> is requested. The
> >>> source address of the packet is not processed
> as CoA when a
> >>> BID is present
> >>> based on the MCoA draft (similarly to what
> happens in case
> >>> the Alt-CoA option
> >>> is used). This comment applies also to the
> fourth bullet of
> >>> section 8.1
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>       Find din nye laptop på kelkoo.dk. Se de
> gode tilbud her -
> >> http://dk.yahoo.com/r/pat/mm
> >> _______________________________________________
> >> MEXT mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mext
> >
> >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext
> >
> 

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd