Subject: Few comments on draft-ietf-multi6-architecture-02

From: Thierry Ernst <[email-masked]>
Date: Tue, 2 Nov 2004 19:15:22 +0900

Dear all,

Here are a few comments on draft-ietf-multi6-architecture-02

Section 2.
- Figure 1. only shows a site with 2 transit providers A and B. Wouldn't
it be useful to illustrate the case where the network is
"multi-attached" ? Then, wouldn't be useful to state if this draft
considers this specific case or not ? 

- What is the definition of "seamlessly supported" ? My mobility
background may not help me to undertand this term in the same way as it
is assumed in this document. I would use "Transparency". It's probably a
good idea to uniformize the terms between the mobility and the
multihoming fields, given the many identical issues.

Section 4.1:
- typo "remote domain domains"

- why the number 10**7 is used, and not, say, 10**10 ? Can we consider
the network everyone will have at home a site ? Such network would most
likely be multihomed to distinct ISPs.

Section 4.2
- I would add NEMO Basic Support (draft-ietf-nemo-basic-support-03.txt,
together with MIP6 (although there is no Route Optimization procedure in
NEMO Basic Support).

  [BTW, just being curious, can't we consider a NEMO multihomed to 2
  distincts ISPs as a site ? cf draft-ietf-nemo-multihoming-issues-01.txt]

Section 4.3
- typo in "...the only viable destination address to use the one that is
based ..."

Section 4.6
- "on packet ingress to the site": it that good English ?  Is "ingress"
used as a verb ?

- in "a large number of associated security considerations" shouldn't it
be "issues" instead of "considerations" ?

- "header rewriting on site exit is for" -> shouldn't it be "on
site-exit router" ?

- typo "the this would"

Section 5
- missing word around "there" in "to transform the ULP PDU to include
locator information there is an associated requirement"

Section 5.3.1
- Blank line missing before paragraphs "ICMP Triggers", "Routing Triggers", ...

Section 5.3.2
- I'm not sure the following sentence is fine: "An implication of this
selection process is that the host s that path selection policy ..."

- "select components": shouldn't it be "selected components" ?

- The word "IN" shouldn't be capitalized

Section 5.3.3
- in "...when all flows to and from a particular destination has
stopped": should be "have stopped"

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Nov 2004 16:53:26 +0100

Hi Thierry,

i just want to make a comment about one of the points that you are 
considering (this may be OT for this list though... but i hope that the 
chairs will let me know when to shut up :-)

El 02/11/2004, a las 11:15, Thierry Ernst escribió:
>   distincts ISPs as a site ? cf 
> draft-ietf-nemo-multihoming-issues-01.txt]
>

I am not sure that all the multihomed nemos can easily fall under the 
definition of a multihomed site.
IMHO, there are cases where it is clearly so, and that the multi6 
solution will provide a solution for the multihomed nemo, while in some 
other cases, i am not so sure.

For instance, suppose a nemo that has a multihomed home network. So the 
nemo has two prefixes, one per ISP of the home network. In this case i 
guess that it is clear that the multi6 solution should apply to this 
network, i guess.

The same case could be when the nemo has two home networks (which i 
guess that is the case that you are considering)

I mean in all these cases, the point is that the multihoming doesn't 
occur between the nemo and the fixed network, but between the 
attachment of the home network(s) and the internet. I guess that in 
those cases, the multi6 solution should apply.

However, when we are considering a nemo that has multiple attachments 
points, and for instance only one nemo prefix, then the fundamental 
assumption of multi6 solution is no longer valid, since the nemo has a 
single prefix. I guess that in these cases, the usefulness of the 
multi6 solution will diminish.

But anyway, i fell that it is very important to determine which parts 
of the nemo multihoming problem can be addressed with multi6 and which 
parts will require additional tools.

Regards, marcelo

> stopped": should be "have stopped"
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 4 Nov 2004 17:00:02 +0900

Hi Marcelo,

> definition of a multihomed site.

Sure, some case do fall under the definition of a multihomed site, some
don't.

> those cases, the multi6 solution should apply.

OK for the 1st case, but in the second case (the nemo has 2 home
networks), I would rather see the multihoming occuring between the
nemo and the home network. 
      
         home network 1
             |  _AR
  |  _-p1/56-|-|_|- p1/48 -- Internet
  |-|_| MR      _
  |   -p2/56-|-|_|- p2/48 -- Internet
             |   AR
         home network 2

> multi6 solution will diminish.

Agree. In such case, I wouldn't consider the nemo as a "site" therefore
the site-multihoming solution wouldn't apply.

> parts will require additional tools.

Identifying which parts can be addressed by existing solutions of WG is
something that we should definitely clarify in
draft-ietf-nemo-multihoming-issues.

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 4 Nov 2004 15:47:19 +0100

>   |   -p2/56-|-|_|- p2/48 -- Internet

ok, sorry for not fully specifying my idea. I was thinking about the 
case where there is a single MR and two HAs, in which case, the 
situation is less clear. anyway, i guess that the key issue is the 
point below...

> draft-ietf-nemo-multihoming-issues.

yes, imho this is the first thing that we should do with multihoming in 
nemo, but for this we need to understand the basic multi6 solution, i 
guess, which is still not defined...

regards, marcelo