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

marcelo bagnulo braun <[email protected]> Tue, 2 Nov 2004 16:53:26 +0100
Newsgroups gmane.ietf.multi6
Message-ID <551A450C-2CE7-11D9-8458-000D93ACD0FE@it>
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ó:
>   [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]
>

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



> 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.
>
>
>
>
>
>
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------