Subject: RE: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-06.t xt

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 24 Apr 2002 02:14:46 -0400

So I thought given the thread I would add some higher layer thoughts behind
Flarions interest in this draft and respond to some of the other comments
raised. I do so coming from an intial viewpoint of seeing absolutely no need
for regional registration for MIP...so am a slightly converted strong
sceptic..as you will see below.

Firstly, I agree with many that avoiding additional points of failure and
the cost/benefit of regional registration makes its usefulness debatable...
I agree that the hand-off aspects of this draft should be split out into the
hand-off work and that additional work is required on the 'home signaling
via regional node plane' to address some of the technical issues, especially
regarding backwards compatibility and GFA CoA assignment (see my previous
response to Annika on the latter and Ahmeds excellent analysis on the
former). Even then, (if I was a neutral), I think I would say that we would
need to see more deployment demand to progress the mechanisms in this draft
on standards track.

However, Flarion has one of the more challenging environments for MIPv4 and
we will deploy something, sometime, somewhere soon (hopefully in huge
volumes ;-) In reviewing a lot of MIP work in anticipation of that
deployment, reviews that are still ongoing and for obvious reasons
commercially sensitive at this time, it is apparent that there are some
missing bits. We plan to continue to write these up and submit them
following discussions and agreement with our core router partners and
customers to then hopefully trigger standards activity where necessary.
RegTunMods and RevTunMods were the first two such drafts and there will be
others unrelated to regional tunneling...

One such missing bit appears to be the need to be able to advertise the
existence of a regional element (the 'I' bit) to the MN, to detect when that
element has changed and to register to a home agent via each new regional
element. We specifically have little interest in the RFA, in the regional
element being a GFA and in the regional registration to the GFA itself. My
analysis of, and feedback on, the RegTun draft in [RegTunMods] was motivated
simply by the desire to be able to re-use the home registration regional
extensions and hence co-exist with GFAs that might already have been
deployed. I am open-minded about them getting deployed, but very unhappy if
the general regional element capability is lost or eventually not
standardised.

I can and will elaborate much further on these points in suitable drafts as
soon as I am able. This will hopefully be a matter of days or at worst a few
weeks. In the absence of that justification and information I would be
supportive of the draft being revised and taken to experimental. I would
however recommend that we try to separate out the home signaling via a
regional element, from the type of regional element and its features, as I
think (well know :-) they are distinct. A generalised address carrier with
sub-types can be used to transport addresses up and down that signalling
plane and be used to trigger address type specific processing..ie a GFA CoA
sub-type means do GFA type things. I think this redesign is a good idea even
just for GFA as who knows what future requirements will come upon us (ours
aside) and nailing up a general capability is unfortunate. This address
carrier should maybe be defined in a separate draft.

I also believe that the regional element should be able to be in the core or
at the edge as alluded to by other responders, although ours will likely be
in the core much to the horror of some of you no doubt. I wouldn't do it
though unless I thought it was absolutely necessary...believe me.

I think we should also finally recognise the extensive and excellent work
that has gone into RegTun, and await both suitable revisions and then
vendor/customer interest before committing this to standards track.

Regards,  Alan.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Apr 2002 11:52:54 -0500

Hi Alan,

Alan O'Neill wrote:

>volumes ;-)
do you mind giving more details?

> In reviewing a lot of MIP work in anticipation of that

-- 
Behcet

---

From: "Dana L. Blair" <[email-masked]>
Date: Thu, 25 Apr 2002 10:37:24 -0400

Nice explaination, but I don't see enough justification in this
email for a "regional element".

Please be aware that I am open to the idea of a "regional element".
However, there must be specific scenarios which have obvious
improvements over current MN, FA, and HA relationships to warrant
an internet standard.

Also, I would hesitate to suggest modifications to a draft which itself
has questionable merit as a standard.  Maybe you should start from
scratch with what you really need instead of creating various
modification drafts.

thanks,
Dana

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alan O'Neill
> Sent: Wednesday, April 24, 2002 2:15 AM
> To: Annika Jonsson; Charles E. Perkins; Madhavi W. Chandra; James Kempf;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [mobile-ip] WG Last Call:
> draft-ietf-mobileip-reg-tunnel-06.txt
>
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Apr 2002 07:54:56 -0700

> scratch with what you really need instead of creating various

Your implication seems to be that our draft has questionable
merit.  I think that statement itself has zero merit.  Furthermore,
I am pretty sure our draft has a lot of merit.  We can go about
fixing the problems it has, but your previous notes seemed to
offer no specific improvements.

I also strongly suggest that we have to allow for separate handover
improvement protocols to be specified in separate documents, which
seems to be contrary to your earlier suggestion.  The protocol
demands for regional registration are qualitatively different
than those for managing connectivity at the edge routers, and
neither one of those protocol solutions belongs in the base
protocol specification for Mobile IP.

Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 25 Apr 2002 09:58:24 -0500

Hello Dana,
  Of course you are entitled to have your own opinion, but I kind of 
like the following view of Ahmad, it is positive and it is going to lead 
to some progress:

> The more solutions we have for the same problem is the better as long 
> as they are:
>         1. OPTIONAL
>         2. 100% BACKWARD COMPATIBLE.
>
> Operators can pick and choose the best for them.
>

>scratch with what you really need instead of creating various
Regards,

--behcet

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 25 Apr 2002 12:11:42 -0400

Hi Charlie,

> offer no specific improvements.

There is no doubt that your draft is the result of extensive
research.  Perhaps if we included a section in the draft 
that outlined the scenarios that would benefit from the 
implementation and added text in the Intro/Abstract to indicate 
clearly that this design is OPTIONAL, it would be more apparent 
that the architecture need not be implemented.  It would also
be clear under what circumstances one would want to implement
this design.  I would also suggest a section on synergies
with Fast Handoffs...to explain the interaction, or separation.

We can certainly help you with text.  I think this is 
independent of the draft status...experimental or not.

Regards,
Madhavi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Apr 2002 09:19:51 -0700

Hello Madhavi,

"Madhavi W. Chandra" wrote:

> research.

In this case, we also have publications, simulations, and
implementations to back up the research.

>             Perhaps if we included a section in the draft

I think this would be great.  I would locate the synergy section
in another Appendix.  I would locate the optionality statement
and scenario description in the first part of the document,
probably within section 3 (perhaps section 3.1).

> independent of the draft status...experimental or not.

I hope I am not speaking out of line before consulting my
co-authors, but for myself I would quite appreciate your
help.

Regards,
Charlie P.

---

From: "Emad Qadoura" <[email-masked]>
Date: Thu, 25 Apr 2002 22:20:50 +0200

Charlie,

I have the following Qs:

1) Do you have a link of where I can find such
publications/Simulations/Implementations? Also having them in a
reference like section would be a good idea?

2) In practice, what would be the likely/suggested size of the domain
(the size of the coverage area) for a GFA? an example considering
wireless networks would be helpful?

3) If the coverage area is large, and the home network does provide
personalized content services based on the mobile node's location
requiring a finer location, would you expect this feature to be always
turned off?

4) Did a prior bakeoff include this draft?

Regards,
EQ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Charles E.
Perkins
Sent: Thursday, April 25, 2002 6:20 PM
To: Madhavi W. Chandra
Cc: Annika Jonsson; [email-masked]; Eva Gustafsson
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

Hello Madhavi,

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Apr 2002 14:47:47 -0700

Hi Charlie,

> implementations to back up the research.

Did your simulations look at what happened if a GFA fails?

            jak

---

From: Tom K Weckstrom <[email-masked]>
Date: Fri, 26 Apr 2002 16:55:04 +0300

James,

---end quoted text---

I think this question is irrelevant. Let me explain with some
additional comments/questions:

- What happens, if a FA serving a single foreign network (without the
  hierarchy) happens to fail?
  --> The users are without the MIP service.

- What do you do, if you suspect that your firewall, VPN GW, high end
  router, or GFA may fail and you do not want the users be affected?
  --> You deploy a High Availability solution. There are solutions out
      there for the above mentioned network elements, probably
      excluding GFA at the moment.

- Should the High Availability solution be somehow bound to this
  standardisation proposal at hand?
  --> Why should it be? That can be handled separately. That can be
      standardized separately, if need be. To me, it looks like High
      Availability solutions would most often be proporietary.

Regards, Tom

-- 
Tom Weckström         <[email-masked]>          PGP id:  E1DB55E9
Lifix Systems Oy      <http://www.lifix.fi/>  Mobile:  +358 50 350 5997
Innopoli 2	      Tekniikantie 14	      FIN-02150 Espoo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Apr 2002 23:41:30 -0700

Tom,

I think this question is quite relevent. We are talking here about
routing, and the original Internet routing design accommodates failure
quite well. Any change should also.

If an FA fails, only the mobile nodes in its subnet are affected. If a
GFA fails, some number of subnets under it are affected, including all
their mobile nodes. I think this is a problem if the design does not
accommodate it.

With regard to high availability, high availability invariably means
high cost. It is much more expensive to design for five 9s reliability
than to design the protocol for redundency, so that low cost, cheaper
elements that are used daily can take over if a single element fails. I
do not think network operators want to see the next generation of mobile
networks based on IP require expensive, high availabiliy equipment like
VLRs if it is possible to provide equivalent functionality with lower
cost, redundant elements such as routers.

            jak

----- Original Message -----
From: "Tom K Weckstrom" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Charles E. Perkins" <[email-masked]>; "Madhavi W. Chandra"
<[email-masked]>; "Annika Jonsson" <[email-masked]>;
<[email-masked]>; "Eva Gustafsson"
<[email-masked]>
Sent: Friday, April 26, 2002 6:55 AM
Subject: Re: [mobile-ip] WG Last Call:
draft-ietf-mobileip-reg-tunnel-06.txt

---

From: "Emad Qaddoura" <[email-masked]>
Date: Sun, 28 Apr 2002 21:02:33 +0200

James,

	I agree with you, but I would add even protocol redundancy
should be left to the vendor. A system may provide several protocols
which may all have needs for different reliability aspects. And if one
system has several protocols and each protocol has its own HA or five 9s
requirements, then a vendor would have to end up with many of these
implementations which may be different. Therefore, the protocol design
should stay out of these aspects and leave it up to the vendor’s system
design specifics.

Thx.
EQ
SmartIPNet

> From: [email-masked] [mailto:owner-mobile-
> [email-masked]] On Behalf Of James Kempf
> Sent: Saturday, April 27, 2002 8:42 AM
> To: Tom K Weckstrom
> Cc: Charles E. Perkins; Madhavi W. Chandra; Annika Jonsson; mobile-
> [email-masked]; Eva Gustafsson
> Subject: Re: [mobile-ip] WG Last Call: draft-ietf-mobileip-reg-tunnel-
> 06.txt
> 
> Tom,
>

---

From: "Dana L. Blair" <[email-masked]>
Date: Mon, 29 Apr 2002 16:27:33 -0400

> [mailto:[email-masked]]On Behalf Of James Kempf
> Sent: Saturday, April 27, 2002 2:42 AM
> To: Tom K Weckstrom
> Cc: Charles E. Perkins; Madhavi W. Chandra; Annika Jonsson;
> [email-masked]; Eva Gustafsson

Actually a well designed Wireless Access network would have more
than one FA per IP Subnet.  Therefore, if one FA fails, then
MNs could re-register through the other FA quite simply.

thanks,
Dana