Subject: Re: [MEXT] multiple coa draft 11

From: Christian Kaas-Petersen <[email-masked]>
Date: Fri, 6 Mar 2009 14:09:36 +0000 (GMT)

I'm all in favor of crystal clear specifications.  I think the draft
should take a stand.  If the intention is to have a one-to-one mapping
between BID-values and care-of addresses, the draft should say so.
If it is allowed to have a many-to-one mapping between BID-values and
care-of addresses, the draft should say so.  In either case,
the draft should motivate the choice.  I do not have a view
of which choice is best; I only wish for helpful text.

Christian

--- Den fre 6/3/09 skrev Hesham Soliman <[email-masked]>:

> Fra: Hesham Soliman <[email-masked]>
> Emne: Re: [MEXT] multiple coa draft 11
> Til: "Christian Kaas-Petersen" <[email-masked]>, "George Tsirtsis" <[email-masked]>
> Cc: [email-masked]
> Dato: fredag 6. marts 2009 14.29
> FWIW, I can't think of any reason why
> the MN would want to assign two BIDs
> to the same CoA. I've commented on this before and don't
> know how it was
> handled in the draft. I can understand how muliple FIDs can
> be assigned to
> one BID (or CoA) but I can't think of any reason for
> assigning multiple BIDs
> to the same CoA. It's at minimum confusing and can cause
> problems with
> implementations. If there is no need for it, why would the
> spec be vague or
> even allow it? 
> 
> Hesham
> 
> 
> On 6/03/09 6:51 PM, "Christian Kaas-Petersen" <[email-masked]>
> wrote:
> 
> > 
> > Suppose a mobile node sends a BU with BID1 referring
> to v6CoAx,
> > and then later sends  another BU with BID2
> referring to v6CoAx.  Then the
> > home agent should reject the second BU because two
> different BID-values
> > are expected referring to different care-of
> addresses.  To me this
> > is an inter-operability problem; and I think it is
> similar to the
> > problem of a mobile node sending a BU with BID=0 (see
> section 4.3
> > where "the value of zero is reserved and MUST NOT be
> used").
> > It was not obvious to me, which of the status values
> found in
> > section 4.4 would be appropriate.
> > 
> > Christian
> > 
> > --- Den tors 5/3/09 skrev George Tsirtsis <[email-masked]>:
> > 
> >> Fra: George Tsirtsis <[email-masked]>
> >> Emne: Re: [MEXT] multiple coa draft 11
> >> Til: "Christian Kaas-Petersen" <[email-masked]>
> >> Cc: [email-masked]
> >> Dato: torsdag 5. marts 2009 13.38
> >> some more inline...
> >> 
> >> On Thu, Mar 5, 2009 at 10:44 AM, Christian
> Kaas-Petersen
> >> <[email-masked]>
> >> wrote:
> >>> 
> >>> Thanks a lot.  Two further comments inline
> >>> 
> >>> --- Den tors 5/3/09 skrev George Tsirtsis
> <[email-masked]>:
> >>> 
> >>>> Fra: George Tsirtsis <[email-masked]>
> >>>> Emne: Re: [MEXT] multiple coa draft 11
> >>>> Til: "Christian Kaas-Petersen" <[email-masked]>
> >>>> Cc: [email-masked]
> >>>> Dato: torsdag 5. marts 2009 11.02
> >>>> Hi Christian, some comments
> >>>> inline...
> >>>> 
> >>>> On Thu, Mar 5, 2009 at 8:20 AM, Christian
> >> Kaas-Petersen
> >>>> <[email-masked]>
> >>>> wrote:
> >>>>> 
> >>>>> 
> >>>>> Hi Ryuji
> >>>>> 
> >>>>> Reading
> draft-ietf-monami6-multiplecoa-11, I
> >> have some
> >>>> comments and
> >>>>> questions.
> >>>>> 
> >>>>>  * There was a discussion on the
> mail-list
> >> in
> >>>> relation to draft 10,
> >>>>>   whether two diffent BID-values can
> map to
> >> the same
> >>>> care-of address.
> >>>>>   Draft 11 is not explicit on this.
>  As the
> >> entries
> >>>> in the
> >>>>>   binding cache are separate,
> >>>>>   and can be updated one by one, the
> benefit
> >> of
> >>>> having two BID-values
> >>>>>   point to the same care-of address
> comes
> >> when
> >>>> introducing flow
> >>>>>   identifier: flow identifiers can
> remain
> >> mapped to
> >>>> the same BID-value
> >>>>>   even when care-of addresses change.
>  It
> >> would help
> >>>> implementers
> >>>>>   if the draft somewhere (section 2?)
> states
> >> "Two BID
> >>>> values MAY
> >>>>>   refer to the same care-of
> address."
> >>>>> 
> >>>> 
> >>>> GT> You are reading MCoA and thinking
> Flow
> >>>> Bindings....which is not a
> >>>> good thing to do :-). The way MCoA and
> Flow
> >> Bindings have
> >>>> been
> >>>> designed, flow movement is based on
> mapping FIDs
> >> to
> >>>> different BIDs.
> >>>> BIDs simply identify available CoAs
> (i.e.,
> >> available
> >>>> paths). I do not
> >>>> see why would one point two BIDs to the
> same CoA.
> >>> 
> >>> Will it be acceptable to add a statement like
> "Two
> >> BID-values
> >>> MUST NOT refer to the same care-of address" to
> the
> >> draft?
> >>> 
> >> 
> >> GT2> MUST NOT is only appropriate if the action
> causes
> >> interoperability problems, which I am not sure it
> does
> >> here. I would
> >> like to hear other opinions though WRT to this
> since I have
> >> not
> >> thought about it in detail for some time. If there
> is no
> >> other
> >> foreseeable use of multiple BIDs pointing to the
> same CoA
> >> then, I
> >> would say something like "more than one BIDs 
> SHOULD
> >> NOT be mapped to
> >> the same CoA".
> >> 
> > 
> > 
> > 
> >   
>    ___________________________________________________________
> > Skal du købe ny bil? Sammenlign priser på brugte
> biler med Kelkoo og find et
> > godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb
> > _______________________________________________
> > 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

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 6 Mar 2009 14:47:19 +0000

Clarity is good, but I would also like to avoid unnecessary restrictions.
IMO, SHOULD NOT here is appropriate.

George