Subject: RE: [netlmm] Conclusion of discussion on Issue #44: Add goal to support make before break handover

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 19 May 2006 10:31:43 -0700

James,
Whether we like it or not, we allow for individual opinions at the IETF,
not any opinions tied to institutions or affiliations. That is what
allows the IETF to function with far less politics than other SDOs.
Stifling that is a very bad idea. 

Regards,
Vidya 

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 12:19 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] Conclusion of discussion on Issue #44: 
> Add goal to support make before break handover
> 
> Vidya,
> 
> The point is - we are looking for new viewpoints.
> 
>             jak
> 
> ----- Original Message -----
> From: "Narayanan, Vidya" <[email-masked]>
> To: "James Kempf" <[email-masked]>; <[email-masked]>
> Sent: Monday, May 15, 2006 2:50 PM
> Subject: RE: [netlmm] Conclusion of discussion on Issue #44: 
> Add goal to support make before break handover
> 
> 
> Hi James,
> 
> >
> > *Please note this important qualifier. Email addresses from 
> the same 
> > institution of people who have already expressed a strong 
> opinion one 
> > way or the other will be discounted. I want to hear genuinely new 
> > opinions, not attempts to force the concensus in a particular 
> > direction through volume.
> >
> 
> I am not sure when institution or affliation of people 
> started factoring in IETF consensus/decisions, but a question 
> nevertheless - what if someone had a different viewpoint or 
> disagreed with someone else from the same institution? Would 
> you want to hear the opinion then? Or, what if someone sent 
> an email from an address that did not belong to their organization?
> 
> I understand your point about attempts to force consensus, 
> but the policy seems flawed.
> 
> Regards,
> Vidya
> 
> 
> > ----- Original Message -----
> > From: "Narayanan, Vidya" <[email-masked]>
> > To: "James Kempf" <[email-masked]>; <[email-masked]>
> > Sent: Monday, May 15, 2006 12:49 PM
> > Subject: RE: [netlmm] Conclusion of discussion on Issue #44:
> > Add goal to support make before break handover
> >
> >
> > I think this one took a lot of discussion in understanding the goal 
> > itself and its implications - but, I don't think what was discussed 
> > reflects any consensus either way (adding or not adding)...
> >
> > So, I think the question still remains open, given all the 
> discussion.
> > It may be good to post a specific question asking people's 
> opinion on 
> > adding/not adding the goal and giving another couple of days.
> >
> > Thanks,
> > Vidya
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:[email-masked]]
> > > Sent: Monday, May 15, 2006 11:45 AM
> > > To: Narayanan, Vidya; [email-masked]
> > > Subject: Re: [netlmm] Conclusion of discussion on Issue #44:
> > > Add goal to support make before break handover
> > >
> > > There was a lot of opinion on both sides of the issue. I
> > don't see any
> > > concensus to put this goal into the draft.
> > > Perhaps I should have phrased it as "lack of concensus to 
> put this 
> > > goal into the draft"?
> > >
> > >             jak
> > >
> > > ----- Original Message -----
> > > From: "Narayanan, Vidya" <[email-masked]>
> > > To: "James Kempf" <[email-masked]>; <[email-masked]>
> > > Sent: Monday, May 15, 2006 11:40 AM
> > > Subject: RE: [netlmm] Conclusion of discussion on Issue #44:
> > > Add goal to support make before break handover
> > >
> > >
> > > Hi James,
> > > Just curious - how do you conclude this as the rough
> > consensus? There
> > > have been a lot of email on this topic, but generally, I read the 
> > > overall opinion as "can be done" - so, I'm trying to
> > understand what I
> > > missed.
> > >
> > > Thanks,
> > > Vidya
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf
> > > > Of James Kempf
> > > > Sent: Monday, May 15, 2006 11:06 AM
> > > > To: James Kempf; [email-masked]
> > > > Subject: [netlmm] Conclusion of discussion on Issue #44:
> > > Add goal to
> > > > support make before break handover
> > > >
> > > > Today concludes the discussion on Issue #44. The WG rough
> > concensus
> > > > was not to add this as a requirement to the REQ draft, so I
> > > will close
> > > > the issue.
> > > >
> > > >             jak
> > > >
> > > >
> > > > _______________________________________________
> > > > netlmm mailing list
> > > > [email-masked]
> > > > https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
> > > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 21 May 2006 11:26:00 -0700

Posting to the new list.  

> From: Narayanan, Vidya 
> Sent: Sunday, May 21, 2006 11:04 AM
> To: 'Kent Leung (kleung)'; James Kempf; Genadi Velev; [email-masked]
> Hi Kent,
> I expect this to be fine for basic operation. However, I 
> wonder if this behavior will conflict with any multi-homing 
> support we may want to add in future - adding a flag to 
> explicitly indicate this allows the flexibility to easily add 
> multi-homing support. We can default the flag to a certain 
> value even. 
> 
> But, I'd be willing to live with this as the default 
> operation for now. 
> 
> Thanks,
> Vidya 
> 
> > From: Kent Leung (kleung) [mailto:[email-masked]]
> > Sent: Friday, May 19, 2006 12:04 PM
> > To: Narayanan, Vidya; James Kempf; Genadi Velev; [email-masked]
> > What would the problem with LMA supporting this feature by 
> > default?   Do
> > you expect this lingering time to be significantly long?  I'm not 
> > clear why handovers would require such a high latency?
> > 
> > I'm assuming the new location will always replace the old location 
> > when update message is received.  It's just that the old location 
> > lingers a little longer instead of being removed immediately.
> > 
> > Kent
> > 
> > > From: Narayanan, Vidya [mailto:[email-masked]]
> > > Sent: Friday, May 19, 2006 10:29 AM
> > > To: Kent Leung (kleung); James Kempf; Genadi Velev; 
> [email-masked]
> > > I am not sure that there are no interoperability issues. Are you 
> > > saying that there won't be any need to indicate a request 
> for this 
> > > feature in the update coming from the AR to the LMA?
> > > So, this means that the LMA will always allow this by default? 
> > > 
> > > I'm not sure this is a good idea - I feel that it would 
> be good to 
> > > have a flag in the update message indicating whether the
> > new location
> > > should replace the old location or not.
> > > Otherwise, there is room for ambiguity in operation. 
> > > 
> > > Vidya
> > > 
> > > > From: Kent Leung (kleung) [mailto:[email-masked]]
> > > > Sent: Friday, May 19, 2006 9:04 AM
> > > > To: James Kempf; Narayanan, Vidya; Genadi Velev; [email-masked]
> > > > Since this is a good thing to support in the
> > > implementation, we could
> > > > add some text to the base protocol draft as recommendations.
> > > > 
> > > > Would that suffice, Vidya?
> > > > 
> > > > Kent
> > > > 
> > > > > Sent: Friday, May 19, 2006 8:52 AM
> > > > > To: Narayanan, Vidya; Genadi Velev; [email-masked]
> > > > > Cc: Kent Leung (kleung)
> > > > > Actually, IETF standards are protocol standards. They
> > > never specify
> > > > > implementation. Implementors need to be free to innovate.
> > > > > 
> > > > > So if there are no protocol interoperability issues, there
> > > > is no need
> > > > > for a goal.
> > > > > 
> > > > >             jak
> > > > > 
> > > > > To: "Genadi Velev" <[email-masked]>;
> > "James Kempf" 
> > > > > <[email-masked]>; <[email-masked]>
> > > > > Cc: "Kent Leung (kleung)" <[email-masked]>
> > > > > Sent: Tuesday, May 16, 2006 7:08 PM
> > > > > Hi Genadi, Kent,
> > > > > Your understanding is correct that we are not talking 
> about the 
> > > > > multiple downstream paths to the ARs and only 
> referring to the 
> > > > > upstream paths towards the LMA.
> > > > > 
> > > > > While it is an implementation issue, it still needs to be
> > > > specified in
> > > > > the standard for interoperable impelmentation.
> > > > > 
> > > > > Thanks,
> > > > > Vidya
> > > > > 
> > > > > > Of Genadi Velev
> > > > > > Sent: Tuesday, May 16, 2006 8:56 AM
> > > > > > To: Narayanan, Vidya; James Kempf; [email-masked]
> > > > > > Cc: Kent Leung (kleung)
> > > > > > James, Vidya, all,
> > > > > > if the question is: does the LMA need to maintain the
> > > > reception of
> > > > > > MN's uplink packets coming from old and new ARs
> > > > > simultaneously for a
> > > > > > short period during handover, then I agree with this. I
> > > > also agree
> > > > > > with Kent that this is an implementation issue for the
> > > > LMA. I think
> > > > > > there should be no impact on the NETLMM protocol.
> > > > > >
> > > > > > The reason to agree on this is that the following situation
> > > > > might be
> > > > > > possible even if L2 performs hard handover: since the
> > > signalling
> > > > > > packets normally have higher priority than data packets,
> > > > the update
> > > > > > NETLMM signalling message (sent by new/old AR) may
> > > arrive at LMA
> > > > > > before MN's uplink data
> > > > > > packet(s) from old AR.
> > > > > >
> > > > > > However, the Issue #44 ("Add goal to support make 
> before break
> > > > > > handover") describes more general problem and needs a
> > few more
> > > > > > considerations especially for the downlink traffic. I would
> > > > > abstain to
> > > > > > include this general issue as a goal in the
> > > > > > *basic* protocol design in order to fulfill the WG
> > > schedule, but
> > > > > > rather to resume on it again when we come to work on NETLMM
> > > > > protocol
> > > > > > extensions.
> > > > > >
> > > > > > Just my 2 pence on this,
> > > > > > Genadi
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Of Kent Leung (kleung)
> > > > > > > Sent: Tuesday, May 16, 2006 1:26 AM
> > > > > > > To: Narayanan, Vidya; James Kempf; [email-masked]
> > > > > > > Hi James/Vidya.  This is my understanding of the
> > > issue based on
> > > > > > > reading a few exchanges.  In general, I agree with
> > > > Vidya and Pete.
> > > > > > >
> > > > > > > There is a request for MAP to maintain a brief lingering
> > > > > binding to
> > > > > > > receive packets (which may be in transit during
> > > handover) from
> > > > > > > previous AR.  This is only for reverse traffic 
> from the MN.
> > > > > >  Actually,
> > > > > > > I think this topic is an implementation issue that
> > > > > reduces upstream
> > > > > > > packet loss during handover.  Generally, a good feature
> > > > > to have and
> > > > > > > "can be done" on the MAP.  Not sure if it is mandatory or
> > > > > > optional.
> > > > > > > BTW, the idea applies to MIP HA.
> > > > > > >
> > > > > > > I believe we are not talking about multiple
> > > downstream paths to
> > > > > > > different ARs.  So the request is not for simultaneous
> > > > > bindings for
> > > > > > > traffic between ARs and MAP for duration of the session.
> > > > > > >
> > > > > > > This sounds reasonable to me.  BTW, sorry for
> > jumping in late.
> > > > > > > Thought this would have worked itself out. :)
> > > > > > >
> > > > > > > Kent
> > > > > > >