Subject: Re: [netlmm] Multiple interfaces

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 9 Oct 2007 10:18:09 -0700 (PDT)

I support Jari's mail. 
Mind you that we were the first to introduce the per-MN prefix concept in draft-sarikaya-16ng-prefix-delegation
I regret using per-MN there 
Of course the intention was per MN's interface, the misnomer came from the traditional concept of assigning addresses to hosts.
  In short, MAC + NAI could be used but MAC which is needed because LMA is far away could be sent only when HNP is set to zero. So I don't see any need for every PBU to contain MAC. What we need is an optional parameter to carry this. 
  Although I appreciate hard work by Raj, Vijay, et al., I think MAC is better and it is possible for SDO usage (WiMAX does have it) to get 64-bit MACs, I saw some individual drafts on this.
  For the sake of moving on, let's do this. I believe the same thing is needed even in RFC 3775 for HA as well.

Regards,

Behcet

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: Christian Vogt <[email-masked]>; Basavaraj Patil <[email-masked]>; "Narayanan, Vidya" <[email-masked]>; Sri Gundavelli <[email-masked]>
Cc: NetLMM Mailing List <[email-masked]>
Sent: Tuesday, October 9, 2007 9:25:12 AM
Subject: [netlmm] Multiple interfaces

Let me state some requirements from an AD perspective.

There is absolutely no requirement for you to solve all problems
in the base document. However, generally speaking we try
to avoid specifications that cause problems for existing
nodes, even if those problems appear only in some configuration.
I do worry about the case where I insert two wireless cards in
my laptop, both of them happen to connect to the same Netlmm
domain, and the laptop becoming confused about which
interface is really operational. As a result, I would recommend
having the base spec avoid that problem. But I would also
strongly recommend against trying to do too much; you
don't have to solve the full multihoming problem in the general
case, only problems related to hosts that are completely unaware
of Netlmm in the background.

Another requirement is that we should follow the truth-in-advertising
principle. The document needs to be accurate in its characterization
of what it can do and what it cannot do.

Finally, given my read of the issue, Erik's response, and a chat
with some other experts, I would suggest resolving this issue
rather than merely voting on it. Fortunately, I don't
think a resolution is that hard to come by or hard to
adopt.

Some additional personal observations follow.

Lots of discussion on this, but it seems to me that the opinions
are not that far apart. Both you Basavaraj and Christian explained
how things can work when the identifiers associated with the
netlmm attachments to two different interfaces are different.

Christian proposed a conceptual change where prefixes are
per interface; Basavaraj proposed essentially the same
thing but left to the policy of the network and only considered
interface type, not instance.

I think its obvious by now that the network needs to know about
the interfaces; without that information we'll be in trouble from
day one as well as when we try to make future enhancements.

But lets not be confused about terminology. By "interface" above
I mean interface as seen from IP; you could still share one such
interface among multiple access technologies.

I wonder if there's a solution somewhere between what Basavaraj
and Christian suggested:

- conceptual model is changed to per-interface prefix
- pmip exchanges carry not just the MNID but also an abstract interface
identifier (e.g., MAC + NAI)
- the rest is up for future work and implementations

If this is in the base, it causes no problems for existing hosts,
while still allowing at least some ways of implementing even
cross-technology handovers and multihoming from Sri's list.

And the additional information would allow us to create whatever
extensions with even nicer properties in the future, as extensions
to the base RFC (e.g., monami6, relaxations of the point to point model,
etc).

Jari

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

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