Subject: [netext] [NETEXT]Some questions about the working group

From: "tracey.Y" <[email-masked]>
Date: Tue, 10 Aug 2010 09:43:57 +0800

Hi,

      I have studied the NETEXT group for a long time and have  got a
general overview of the whole work. while paying attention to the main
topics in the working group and in the maillist , I found that the recent
focus maily on the terminal side. And I have some questions in private as
following:
      --Since flow mobility, inter-technology handover and multihoming are
considered to be service provided by the protocol, I want to know why it is
still  necessary to dicuss the depolyment at the  terminal side? bacause I
think in a simple scenario when a host wants to requst some service and
the network finds it does't qualify the requirements, the host will just get
a reply 'NO'.
      --Have the working group considered to give a specific P.S.
document to describe the protocol feature related in the network-based
mobility extension, such as the bulk refresh? I think it will let us know
 innovations in the working group and can differentiate the benefits
clearly.

     Thanks.

Regards,

   tracey.Y

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 9 Aug 2010 19:20:26 -0700 (PDT)

Hi Tracy,

inline.

> still  necessary to dicuss the depolyment at the  terminal side? bacause I

For supporting inter-technology handoffs, we require some configuration on
the host side. Its the ability for the host to perform handovers between
access interfaces and still not loosing application sessions while doing
the handoff. So, we specify the general requirements for the host that it
needs to support, for leveraging some of the mobility features. The use
of Virtual Interface (also some people call it logical interface) is one
such example.

> innovations in the working group and can differentiate the benefits

We dont write PS for every document. Most of these extensions have clear
requirements and based on the deployment experience. But, we some times
do insist on having Problem Statement document for some of the work items.
We generally do that, if we want to delay the work, that strategy really
helps :), so the WG spends two years on PS and another two years defining
the solution. By the time the work is complete, the industry will be
chasing a different problem. So, there is a purpose behind PS work :).

Hope these insights help.

Sri

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 11:26:20 -0700

Hi Sri -

Quick comments below -

Sri Gundavelli wrote:
> > [...]
> requirements and based on the deployment experience. 

Hmm... The deployment experience might not be available to everybody in this working group. 

If the requirements are clear it would be good that they are written and agreed upon by the working group. That does not necessarily mean publishing a draft or an RFC but just touch baseline over an email discussion. I am sure it would facilitate the other discussions we're having on the protocol design.

>                                                      But, we some times
> do insist on having Problem Statement document for some of the work
> items. We generally do that, if we want to delay the work, that strategy
> really helps :), so the WG spends two years on PS and another two years
> defining the solution. 

Sometimes we also do that to avoid solving imaginary requirements ;-)

>                     By the time the work is complete, the industry will be

Right, there's a purpose: To avoid developing protocols solving problems the industry does not care about ;-)

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Aug 2010 11:33:55 -0700

All fair points :) The goal and the purpose is much more balanced now. Tracey now got the point. :).

Sri

---

From: "tracey.Y" <[email-masked]>
Date: Sat, 21 Aug 2010 08:54:10 +0800

Thanks a lot for all of you. :)

Best Regards.
Tracey

2010/8/21 Sri Gundavelli <[email-masked]>

> > If the requirements are clear it would be good that they are written and
> agreed upon by the working group. That does not necessarily mean publishing
> a draft or an RFC but just touch baseline over an email discussion. I am
> sure it would facilitate the other discussions we're having on the protocol
> design.
> >
> >>                                                     But, we some times