[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft interim meeting minutes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
please find the draft interim meeting minutes below. Please mail
comments or corrections by July 7th. Neither me or Brian can find a
copy of Eliot's presentation. We have asked him for a copy and will
publish it on http://ops.ietf.org/multi6/interim-04/ as soon as we have
it. I will let the list know when it's there as well.
kurtis & Brian
Minutes of meeting from Multi6 interim meeting
==============================================
Date: 2004-06-14
Place: Santa Monica, Loews Hotel
Agenda:
1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.)
2. Charter review (co-chairs, 5 min.)
http://www.ietf.org/html.charters/multi6-charter.html
3. Review "Things to think about" draft (Eliot Lear, 45 min.)
http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-
about-03.txt
4. Review threats draft (Erik Nordmark, 45 min.)
http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats
- -01.txt
5. Review + discuss future Architecture draft (Geoff Huston by phone,
co-chairs, 2 hours)
http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures
- -00.txt
6. Open discussion on the impact of various categories of solutions
(co-chairs, 1 hour)
7. Conclusions of meeting and where to move from here.
Minutes of meeting: Jens Kristian Kjaergaard with support from John
Loughney, Kurt Erik Lindqvist, Brian Carpenter and the Jabber
scribes in the form of Iljitsch van Beijnum, Bill Fenner and Joe
Touch. Minutes edited by Kurt Erik Lindqvist and Brian Carpenter.
Slides used as input can be found at http://ops.ietf.org/multi6
Jabber log at
http://www.xmpp.org/ietf-logs/multi6@ietf.xmpp.org/2004-06-14.html
Audio/video archive at http://www.muada.com/multi6streaming2.php
For A/V streaming see
http://ops.ietf.org/lists/multi6/multi6.2004/msg00902.html
Attendees :
Kurtis Lindqvist, kurtis@kurtis.pp.se
Jens Kjaergaard, jens.k.kjaargaard@ericsson.com
John Loughney, john.loughney@nokia.com
Thomas Narten, narten@us.ibm.com
Michael O'Neil, mjo@arin.net
Erik Nordmark, nordmark@sun.com
Dave Crocker, crocker@brandenburg.com
Roy Brabson, rbrabson@us.ibm.com
Eliot Lear, lear@cisco.com
Joe Touch, touch@isi.edu
Mikael Lind, mikael.lind@teliasonera.com
Josh Chao, hcc@mail.ndhu.edu.tw
Qing Li, qing.li@bluecont.com
Jean-Francois Tremblay, tremblay@hexago.com
Tomohiro Fujisaki, fujisaki.tomohiro@lab.ntt.co.jp
Jim Bound, jim.bound@hp.com
Yanick Pouffary, yanick.pouffary@hp.com
Jordi Palet, jordi.palet@consultintel.es
Brian Carpenter, brc@zurich.ibm.com
David Kessens, david.kessens@nokia.com
Iljitsch van Beijnum, iljitsch@muada.com
Marcelo Bagnulo, marcelo@ing.uc3m.es
Jukka Ylitalo, jukka@nomadiclab.com
Aaron Falk, falk@isi.edu
Bill Fenner, fenner@research.att.com
Joe Touch, touch@isi.edu
Jeff Barrows, jeff@barrows.net
Chris Christou, christou-chris@bah.com
Ali Karimi, aki.karimi@ieee.org
1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.)
===============================================================
Brian Carpenter commented on the intention of the meeting agenda and
briefly addressed the alternative schedule put forward by Iljitsch
van Beijnum on the multi6 mailinglist.
A set of questions were prepared by Kurt Erik Lindqvist (Kurtis) and
Brian Carpenter for agenda item 6.
Brian Carpenter gave a reminder of the IETF IPR rules as updated
by RFC3667 and RFC3668 and encouraged people to follow IETF etiquette
by:
- reading the drafts before commenting
- taking turns at the microphone
- signing the blue (white) sheet
- noting that meeting minutes will be public
Iljitsch van Beijnum encouraged us to complete one issue before going to
the next during the discussion.
2. Charter review (co-chairs, 5 min.)
=====================================
Brian Carpenter (BC) reviewed the current working group charter defined
in
http://www.ietf.org/html.charters/multi6-charter.html.
Brian Carpenter noted that the WG has only produced RFC3582, that
has (possibly conflicting) goals that aren't strict requirements.
The "Multihoming in IPv4" draft has expired and kurtis intends to
issue a revised version before the IETF San Diego meeting.
Aaron Falk(AF): We have received some other documents, but not
evaluating,
and not all drafts seem to be listed.
BC: There are to many to list them all
Kurtis: There is a list of all multi6 related drafts at
http://ops.ietf.org/multi6 - if there are errors, tell kurtis.
Someone: The working group webpage should be updated with a link to this
page.
BC: Yes, we will ask the secretariat to update the page [Note added
after the meeting: this has been done.]
AF: There is some important charter stuff that is not in the new charter
BC: We are not chartered to actually work on solutions, and when a WG
later is, it might not be this one or even in management/ops Area.
3. Review "Things to think about" draft (Eliot Lear, 45 min.)
=============================================================
This agenda item was a review of:
http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-
about-03.txt
Elliot Lear (EL) presented the changes and open issues.
Slides at ????????????????????????????
EL: Not very many updates since last meeting, should not take full 45
minutes. Thanks to Marcelo and Pekka.
EL: First change, if using shim layer aproach. Is fragmentation done
above or below shim layer? And can you piggyback on existing
fragmentation? If you can establish a context while doing
communicaiton this could reduce latency, and this would be very
valuable. Saving roundtrips is good, especially on "call" setup. IF
you are doing the shim on top of fragmentation that can be
troublesome, especially with UDP.
Joe Touch(JT): "Call" setup? I am at the IETF. Is roundtrip saving a
specific issue for multi6? Seems to be specifically tailored to a
telephony type of environment. Why save roundtrips if noone else in
the stack is doing it?
EL: A phone regulatory limitation
JT: That is the point, IP is best effort. This is a red herring.
EL: This is not a requirements draft. If you address this it is a nice
thing, but doesn't disqualify solutions that don't meet this.
BC: <chair hat off> Hard to dismiss phone requirements. Disagrees
with Joe, the world is changing whether we like it or not.
Dave Crocker(DC): Sometimes we can replace bad requirement with a good
one. You don't delta one view of the world to another, replace yes but
not delta. Latency and roundtrip counts not just for call setup in a
telephony environment.
EL: No phone vs internet debate, latency counts. Better not to use these
examples.
Margaret Wasserman (throught Jabber, MW): Are the presenations on-line?
BC: No
[Note added after the meeting: Bill Fenner contrived to upload most of
the slides to a temporary site via GPRS!]
It was agreed to avoid the phone terminology and move on.
EL: I added the MPLS-TE part on the request of Pekka Savola.
Iljitsch van Beijnum (IvB): Why layer2 stuff? We are working on layer
three here.
EL: Right, but there may be some subtle interactions. Not
sure. Traffic Engineering implications of multi6 cannot be ruled out,
which makes it a valid item in a things-to-consider draft. Few of
the new requirements were my idea. The list on the screen are changes
made in this version and has come as feedback from others.
Someone: How does your solution interact with DNS caching semantics?
EL: Randy in the meeting in Minneapolis pushed for operational
concerns document.
KL: General comment. With DNSSEC there seems to be circular
dependencies that we might be careful of as well. But others here
know more about this than I do.
EL: Yes, that is Margaret's pet-peeve, circular dependencies were
already in the first draft. Example was what if the DNS server is
multihomed? It would be could if DNS servers could avail themselves
of multi6.
EL: Another new issue, impact on in/egress filtering.
EL: A word about applications. Eihter the solution odes not require
any changes, in which case the application only deals with IP
addresses, or things that look like IP addresses. Or the changes are
hopefully clearly documented and relatively simple code fragment
diffs might be nice. HIP makes IP addresses opaque as it fits in 128
bits but it doesn't really look like a regular one, may be ok for
some apps not for others.
EL: Logging issues aren't really mentioned.
EL: If you make addresses opaque to applicaitons, how do applications
keep track of who they're talking to? We may need to theorize but not
actually create an API.
AF: Random thoguht. If you are debugging, I can ping an IP address,
may want to ping an identity?
EL: Yes, interesting. Two pices of information. Ping-like,
traceroute-like. I.e see which addresses are involved in reaching a
certain identity.
DC: Important, I was considerably dismayed as an apps guy. I would
like to see code diffs for apache to implement locator/identifier
split.
BC: <as co-chair> maybe push to area-directors? <co-chair hat off>
Maybe imposing that *nothing* changes is hard, but should be careful
with
requiring to change applications. There was much pain in apps land when
the
basic IPv6 changes where made to the stack. [Editing note: did I say
stack?
Surely I meant socket. - BC]
TN: Be careful about ruling out of scope. Useful to list stuff, but
in the end make tradeoffs. This implies API must use addresses.
BC: We clearly have an action item to get handle on boundary
conditions.
KL: Do we want it in this document?
BC: Probably not. We should talk to application ADs. And we hope our
AD is listening...
John Loughney (JL): I support Brian. Not talk aout specific
applications, but about things like callbacks ans so on. Solutions
should consider this.
Someone: We need several lists. We need to know wheter identifiers
change
or not, whole bunch of stuff. We need to collect it, but not
neccessarily right now.
EL: Note that this talk is a diff. There are other referral issues in
the
draft already.
EL: Moving on, security. Does your solution introduce time-based
attacks that were not previously possible? Add referrence to threats
draft. We'd like to follow hippocratic oath: first do no harm. I have
just asked questions, but now rather spend time on solutions.
IvB: I am concerned that solutions may create strong dependency of
the Internet on DNS.
Application stuff was fun, but what about DNS? Today I can do
stuff without DNS. May not be able to in the future, regardless of the
circular stuff?
EL: Please provide text.
EL: And I am done.
BC: Do people in this room want to adopt this document as a WG
document? We can decide if we want to publish it as an RFC in the
future.
The meeting unanimously raised its hands to adopt the document as a WG
document.
BC: This has to be verified on the list, and we will later decide if
we will freeze the draft.
4. Review threats draft (Erik Nordmark, 45 min.)
==================================
This agenda item was a review of:
http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt
Erik Nordmark presented the draft according to input in presentation:
http://ops.ietf.org/multi6/interim-04/multi6-interim-threats.pdf
JL: One concern about new identifier space. What's the role of
authentication and authorization for that space? Do we need to AAA
that ID and how does that relate to the IP address? Does this bring
up any new security threats?
EN: We are assuming that an ID at some level, be it an identifier or
locator can speak for itself at some point. The basic concern is
proving ownership of the id. Inherently you're authorized to speak
for yourself, you can go further with authorization, especially
authorization to send a locator to avoid DoS. I don't know wheter
it's "ownership" notion or "authorization" - "ownership" is simpler.
JL: Authorization can live higher. We need to be careful with
implying too much about identifier layer. Final note, what about
binding between ID/Loc? Would it be possible that you're authorized
on one IP address but if you change to a different connection how do
you get your identifier still valid for that new connection?
EN: It might make sense to come up with more context - there may be
some intro material for the draft.
TN: Using authorization words helps clarify who is being authorized,
clarify e.g. address authorization/ownership.
TN: When to publish vs. when to sit on doc. If the WG thinks they're
done, it might be useful to push it through IESG to get the IESG
review - not a crime to publish an RFC and then update it a year
later.
DC: I suggest we distinguish between IPv4/TCP today (i.e., threats that
we
tolerate) vs. ones we are creating with multi6 vs. something that's an
opportunity to "improve" the current infrastructure since we're
changing things already. Some of what I've heard today sound a whole
like trying to "fix the Internet"
EN: I'm just trying to make sure we understand where we are today
with the IPv4 Internet.
DC: Yes, just distinguish between what threats are new and what are
part of the existing world.
BC: <chair-hat on> It's ok to say "this is a threat and we're not
going to fix it".
JL: Make sure we put the limits as to what we're going to
authorize/authenticate. The use of address as authorization
has happened; how do we identify but not solve fixes to this?
EN: pointed out that although the concepts of on-path and
off-path attackers are well understood potential dynamic or pass-by
on-path attackers needs further considerations.
EN: Appendix B contains input to the security analysis of some of the
proposals. Is this the appropriate place?
BC: Suggest to leave "as is" and review in 6 months.
Elliot Lear mentioned that mobility related threats are new compared
to existing treat scenarios.
BC: Do we think the WG should accept Erik's draft as a WG draft?
The draft was accepted as a working group draft with most of the room
for, some abstains, and no against. To be confirmed by the WG on
the list.
5. Review + discuss future Architecture draft (Geoff Huston by phone,
co-chairs, 2 hours)
================================================================
This agenda item was a review of:
http://www.ietf.org/internet-drafts/draft-nordmark-multi6-
architectures-00.txt
Geoff Huston presented "Architectural approaches to Multi-Homing for
IPv6"
remotely on phone from Australia.
Slides at
http://ops.ietf.org/multi6/interim-04/2004-06-10-multi6-arch.ppt
Geoff Huston (GH): This is an idividual submission I hope will be
accepted by the
working group.
GH: If you can get PI space from your RIR you can have multihoming,
but this isn't easy especially if you're small. So then use a more
specific of PA space. This is often a backup solution, no good load
balancing.
GH: The issue is that if you want a solution that can work for decades
you can't assume the number of mulithomers is going to be small,
there may be millions of other assumption we have to make: we don't know
the scaling issues with current routing, both protocols and routers
we have now. We can use routing approach for multihoming but it may
not scale adequately. The question is if there is an alternative
approach.
GH: Take 2 address blocks, one from each provider. Communication
depends on reachability and policy. Can I do load balancing OR
primary/backup configuration? Generic problem: local host in
multihomed site, ISPs a and b, internet cloud, remote host.
GH: There are a number of things to be aware of.
GH: 1. Two means more than one, can be several but two is the
minimum.
GH: 2. First hop must be different for first hop, don't know about the
rest and trying to know this isn't a goal. Second thing to know:
this isn't mobility, homeless or otherwise. I.e there
always is a starting position of assured connectivity.
Additional connectivity may be established
dynamically. So if you bring up isp c when a session is already
running over a and or b, adding c to the session should be ok.
GH: Functional goals, RFC3582 enumerates them. They are not
requirements, but goals. You can't meet all objectives all the time,
also from the other drafts discussed earlier. RFC3582 gives you a list
of 10 items: redundancy load sharing, traffic engineering, policy,
simplicity, etc. When grouping points some are about routing, some are
not. Last but not least, names/endpoints, stuff in the dns
issue, bootstrapping problem re. legacy compatibility, you must be
reachable through a FQDN.
EL: One quick point: the questions addressed are all appropriate but the
organization of the document could be better.
GH: Four generic approaches:
1. Route each M-H site
IPv4 approach
2. Introduce ?Identity? into the protocol exchange
2.1 Insert a new element in the protocol stack
New synchronization element to exchange id/locator binding
2.2 Modify the Transport or IP layer of the protocol stack
Perform id/locator mapping within an existing protocol element
2.3 Modify the behaviour of the host/site exit router interaction
Modified forwarding architecture coupled with distributed state of
identity / locator binding
JL: Other WG is working on path signaling.
Alison Mankin (Through Jabber, AM): My point is that multihoming
can't include all this functionality per se within it.
IvB: Traffic engineering is an actual requirement. People aren't
going to pay for bandwidth that they will use 1 per cent of the time.
GH: Slide 7. I call myself by my identifier, you call me by my
locator. Have identity stuff as discrete element or do it in an
existing protocol element and sync up at the same time as this element.
GH: Final option (of the 4): can modify behaviour of the host site
exit router interaction: site exit router changes your stuff with or
without host's knowledge.
GH: Slide 8. Multihoming via routing. Ultimately, routing each site
removes structural hierarchy from interdomain system. 10^7 is taken
as a meassurement of the number of sites required to be supported.
We don't think this scales.
GH: Slide 9. If you can't do it in routing you have to do the split;
there is no other way. The network needs to route the packet based on
"where".
GH: Slide 10. New protocol element, that have to map somewhere in the
stack. We can do this in two places: between ip and transport or
between transport and ulp (although nobody proposed this).
IvB: I think doing it between transport and ulp is a red herring -
how can you do it without reimplementing much of TCP?
DC: Geoff I appreciated your point that this is a theoretical
point. One of the functional requirements when doing it at session
layer, is to maintain what applications thinks is transport
context over multiple transport connections.
BC: There is at least one proprietary solution that doesn't care about
TCP survivability.
DC: Transport survivability is an issue if doing it at the session
layer.
GH: I agree. I will put in more text for completeness.
GH: Slide 11. Other way to do it: change protocol element so it's done
as part as normal operation of that element (transport or ip). Can
have set of locators that work as identifier, or alter the ip protocol
to support ip-in-ip structures that distinguish between
current-locator-address and persistent-locator-address , ie. mipv6.
GH: Slide 12. Modified host / router interaction. May need to do
source based routing because isp may do unicast reverse path
filtering; a very heavy weight solution compared to the alternative
of adding morelocators.
BC: Do you disagree with the analysis in the Huitema draft?
GH: No. But it's very heavy weight to have to modify all internal-site
routers if the behavior of a router depends on location in site, hard
to operate/debug.
BC: Don't disagree, but Huitema draft says you MUST solve ingress
filtering problem.
GH: Different solutions here.
JT: We do something like this where each host has an internal router,
everybody is an exit router.
GH: Write it up, as I am not sure I completely understand it.
GH: Slide 13. Number of ways to solve site exit problem. First, if you
only want the ser (site exit router) to route and nothing else, (which
is
probably a good thing to do) then have dmz/anycast group and tunnel to
appropriate ser/isp other approach: all internal routers do source
address based routing. Third, dangerous, make sers rewrite source
addresses. Fourth, modify uRPF so any isp accepts any source locator
move on to identifier/locator binding.
GH: Slide 14. You want to allow a single session to work over multiple
paths over time. One approach: transport protocol establishes session
on identity, then *SOMEWHERE* map to locator that's used on the wire.
GH: Slide 16. Where do you put the new identity protocol element?
Most proposals put this above ip and below fragmentation and ipsec.
This makes sense if you want things to happen correctly.
BC: Ohta-san made a strong case on the mailing list that this is
completely wrong and it must be in transport. Counter-argument?
GH: Haven't directly addressed this claim, but I disagree. If you want
IP-Sec and fragmentation to work, you need to do dynamic rewriting
AFTERwards and map back at receiving side.
GH walks through ulp->transport->identity->ip and back at receiver
interactions. Identity is explicity there because you need to
synchronize both ends.
GH: Slide 18. How can you do this? Conventional: each protocol takes a
PDU from the previous one, so simply expand packet at each layer.
GH: Slide 19. Some approaches have explicitly gone out of band, and
there is some benefit here, topology changes don't always happen
nicely. This can use timing of topology change rather than application
timing. The other way is three way conversation with reference point
so two parties sync with a third one. This is a generalization of
using dns.
GH: Slide 20. "referential". Use a reference to a third party point a
a means of peering (e.g. dns identifier rs).
GH: Slide 21. Use identity token from protocol address space, or FQDN
as identity token. Structured token vs unstructured token. If we use
ip address little changes necessary. Use identity tokens lifted from a
protocol address space DNS, applications, transport manipulate an
address. IP functions on locators. Stack Protocol element performs
mapping of FQDN as the identity token. Is this creating a circular
dependency? Does this impose unreasonable demands on the properties of
the DNS? Structured token. What would be the unique attribute of a
novel token space that distinguishes it from the above? Unstructured
token. Allows for self-allocation of identity tokens (opportunistic
tokens). How to map from identity tokens to locators using a lookup
service? Adding straws to back of DNS camel may be dangerous.
GH: If you're going to create a new namespace it's either going to
look a lot like a dns name or a lot like an address.
DC: Keep same namespace as DNS but distinct lookup servie.
TN: Running dns on a new port requires serious thought. Is this a
place we want to go?
DC: I'm not saying we do, just have it on record.
GH: Alternatively, take token with no structure at all. It's just a
token, not even complete guarantee of uniqueness. This works well,
except for mapping.
IvB: Is this token per site, or per host?
GH: Or per session, per site means some structure.
GH: Next slide. Common issues: Picking the "best" source locator. Try
them all. Or identity peering protocol to allow the remote end ...
GH: Slide 23. Other part is picking best destination locator. Longest
match / use each in turn. Iljitsch made point in march: may need to
look at pairs of locators.
GH: Slide 24. How do you know when to change address? Timeout may take
too long. Proposals for heartbeat. Modified transport
trigger. Host/router interaction trigger. Application timeframe vs
network timeframe. Failure during session startup and failure
following session establishement.
GH: Slide 25. How do you know a session is completed? What do you need
to do to bootstrap? Are there "distinguished locators" that you
always need?
GH: Next slide. Session persistence. Use home locator. Use locator
set. Use new peering based on identity protocol elemenet and allow
locators to be associated with the session identity.
GH: Slide 27. Identity/locator binding domain. In very restrictive HIP
there is a new identity per session. Allowed to bind bindings across
sessions? Binding management issues.
GH: Slide 28. Bilateral peer applications vs multi-party
applications. Applicaton hand-over and referral in session-based
identities referral is impossible or rather: extremely challinging.
GH: Next slide. Security consideriations. Point to Erik's draft real
soon.
EN: Back to common issues. Session establishement is common, but
termination also. There are two pieces to the security stuff: Keep
architectural issues from actual threats. Where we need to do
something like your draft for security too.
GH: Generic architecture for security hard to do. Vulneratbilities are
clear from actual implementations, hard to do based on generic stuff
so you'd have to analyse each proposal separately.
BC: We decided to keep Erik's security draft and park analysis there
until we find another place for it.
BC: Do security analysis when number of proposals gets below 30.
GH: My suggestions for moving forward: 1 complete proposal survey
(appendix). 2. analyse identity properties in further
detail. 3. Examine some futher open issues (next slides). 4. Make
some tentative conclusions regarding the properties of a robust
multihoming approach and a strawman propsal). 5. Submit to WG for
adoption as a WG document.
BC: Do you want to do one more iteration of the draft as individual
before making it a WG document?
GH: Yes. Now the open issues:
GH: How serious is routing problem re multihoming anyway? Can routing
scope be a better solution that complete protocol reengineering? Are
there other approaches here to managing the inflation rate? Betting on
routing isn't necessarily bad, it just has risks. Open questions:
"Are you doing all of these changes JUST for multihomming"? The issue
is that it's a big fundamental problem, more general than multihoming
perception could be that this is solution overkill. We have to
distribute identity prefixes also structured space management has
serious overhead. You can't just select your own identity, so can we
use something that already exists?
DC: May want to mention origin of first two points: "strategic
marketing": not getting much for what you're doing. Second we should
worry about operational impact.
GH: Second one is very important.
KL: Yes, there will be overhead but we have that today too.
GH: Yes, someone said for domain names this is terrible.
BC: Ergo: do not involve ICANN.
EN: Why need structured space? To make lookup scale, and to guarantee
uniqueness. We can probably make top not administrative. So structured
space != someone owns the root.
GH: Slide 33. Applications and id/loc is a self reference within an
application the identity value? If so, then can opportunistic id
values be used in this context?
JT: Questions about what you can and can't do with identifiers
GH: Slide 34. Structured space heavy weight solution. Unstructured
space has referral issues, potential vulnerability to attack if using
ip addresses in referrals, still the existing overloading...
GH: Next slide. Proposed next steps. I intend to have a new version
within a few weeks, before the cutoff for San Diego. Want to do more
work on survey, more notes on routing, steps 1, 2 and 3, but not 4
(see earlier).
KL: What if we limit the number of solutions later today?
GH: I wanted to capture survey in longer-lived document.
The architecture draft is kept as an individual submission by Geoff
until point 1. + 2. + 3. in the next step list is done. Hopefully
this could be settled within the next couple of weeks.
6. Open discussion on the impact of various categories of solutions
(co-chairs, 1 hour)
===============================================================
The objective of this agenda item was to structure the more than 30
proposals addressing IPv6 multihoming. For this Brian Carpenter
used his slides at
http://ops.ietf.org/multi6/interim-04/interim-agenda.ppt (start at
slide 8).
BC: Does Geoff's draft cover the right stuff?
EL: It might cover too much. I don't know if it is ready for RFC
publication, but it would be ready for WG document status. It doesn't
appear to miss anything substantial.
IvB: I sent in a list of comments when he first published it, didn't
check if they were addressed in the -01; One thing that was missing
in the previous version is the issue of initiating new sessions when
there has been an outage - the -00 talked mostly about keeping
existing sessions running. Should be explicit that this is important.
GH <via Jabber>: There is no -01 yet - these comments will be
integrated.
JL: Geoff's draft seems quite complete; I'd like to see reducing some
of the scope; It especially struck me that some of the common things
for multihoming are common in general. So not specific to multihimoning.
We should start scoping out what's more explicitly multi6.
BC: Geoff's draft or another draft?
JL: I'd like to see Geoff's start to scope things at least say that
things are not just a multihoming issue.
GH <via Jabber>: Common in general for id/ocator split or common in
general in some other way? I'm still unsure - IF you head down the
id/locator split then there are a set of issues.
JL: I think his draft captures commonality in ID/Locator split, that's
reasonable; some are more general in the general sense -- like
detecting loss of connectivity, detecting presence of connectivity
BC: One of the drafts that v6ops is not currently considering pertains
to how you find v6 connectivity when randomly attaching to the
network; there's some commonality there to finding some connectivity
in multihoming.
BC: Conclusion: not much missing; scoping issue: make it explicit
what things are intrinsically part of multihoming and what is more
general.
BC: Slide: "Some questions (2)"
Is modifying all transport layers to deal with multihoming realistic?
Are all transport layers equal for mh?
Will applications in general deal with mh issues?
Do we believe that any applications will deal with mh issues?
TN: that means modifying every single UDP-using application.
EL: With TCP and SCTP, you know the start and end; state is
well-defined and maintained below application. Now with UDP you need
to not only maintain that below state but also names/id/loc/etc
JT: I would phrase 1st Q. differently: I don't think it makes sense
for a transp layer to know what multihoming means - but it makes sense
for them to know an identifier is. I may want to rewrite transport
layers once to abstract ID, but not deal with multiple IDs.
IvB: The socket layer might know when communications stop and
start. Don't create an artificial dichotomy between modifying all
transports and not modifying any transports; Could modify some.
BC: "Satirically", "tell everyone to use SCTP and you're done".
IvB: Transport based on UDP are done in applications; changing
applications takes forever; most applications use TCP; you could
implement a change in TCP and just do something to UDP that keeps
them running but doesn't necessarily give all the gains.
EN: What's the need for modifying things at the transport layer?
Transport do everything wrt multihoming? Transport is aware that there
are multiple paths to relearn e.g. congestion but not perform any
multihoming decisions itself. Can you give *some* benefit to
unmodified transports, then can you put something into the transport
to make them work better?
BC: E.g. ECN if the path changes
EN: Could say that we're only going to worry about TCP, but even
saying therefore a session from multihoming perspective is only TCP,
that might not scale well for short sessions.
BC: Or media streaming.
EN: So part of what we're asking about is connection-oriented vs. UDP
BC: and DCCP
GH <via Jabber> : Media streaming === DCCP is the direction - yes - so
we may be talking TCP and DCCP here.
EL: We're hearing about what you can and can't touch - I don't think
we should hold the application layer to be sacrosanct. Misuse of IP
address in applications? Suggest 3 levels: modify IP layer;
connection-oriented; application layer? Say to application providers
"If you want to take advantage of this, you need to add a call or two
or understand ID/Locator".
BC: I'm hearing people say that the big bullets are "no" and small
are "yes". <refer to "Some questions (2)" slide>
EL: Perhaps some apps don't care to use the new API; could have shim
library.
BC: Implying new socket calls as a result.
EL: Potentially.
TN: 1st bullet is wrong question to ask: it's not a yes/no question,
since it depends on what the change is.
KL: Can a non-modified application or transport layer take any
advantage of the improved underlying network?
BC: That's never been a requirement.
KL: We're close to going down that rathole.
Someone: What about ipsec tunnels?
BC: That was covered in Geoff's presentation - location of shim
decides whether fragmentation or ipsec works.
BC: Whole solution in transport isn't very popular with those in this
room; part of the solution could go in the transport.
IvB: There are 2 different ways unmodified apps could take advantage
of multihoming: 1. If full ID/Locator split, apps see IDs, big problem
is mapping service. 2. If something like NOID, there are IP addresses
that must be reachable in the app that filter through the API; the
lower layers probably can't change e.g. a nonworking dest addr for a
new session attempt to a working dest addr since they don't know the
working addresses, can change source address because apps usually
don't specify source, can do tricks when failure in the middle of a
session.
BC: Line closed for this slide.
JT: Re IP-Sec: Worth categorizing, e.g. IKE looks like an
application. Protocol caring about address used for routing, it cares
in the way that a transport protocol would, so think of it in the same
way. Conclusion on this slide: questions aren't quite properly
phrased. Probably will be some implications to transport layers even
though we don't put the solution in the transport layer. Same is
probably true of [sophisticated] applications.
BC: Now on slide 10 - "Some questions (3)"
Is it reasonable to assume that socket state can include mh state?
Or does the necessary state have to be dissociated from sockets?
Can the IP layer accurately decide when to forget mh state?
Does it matter if mh state stays too long?
JT: I don't think it's appropriate to say "Socket" here. As far as
portocols are concerned that's an application layer. I'm not saying we
shouldn't talk about sockets; last slide talked about application
layer, sockets aren't magically different. Sockets are a particular
implementation of an application layer.
BC: Socket state is implementation-specific state that contains all
the magic protocol state; why is that application layer?
GH <via Jabber>: The second bullet makes sense to me as a question.
TN: Maybe another not well-formed question - more like "Will
applications have or need access to the multihoming state"?
GH <via Jabber>: And the answer appears to me to be 'no' - it would
be preferable for transport to signal session state to the id/loc
mapping.
JT: Socket layer *is* the application.
KL: There has been this discussion & we have the general question -
upper-layer hints? -> clearly modification of the socket interface, if
applications help manage the state.
TN: Maybe real issue again is what info needs to go up, how high up,
what needs to go down, how far down?
BC: And what needs to be stored? Take noid - somewhere you have to
keep a list of locators that go with the locator you're using for the
ID. Is that kept once per socket, once per host, ...?
EN: This is about sharing or reusing data across multiple connections
or over time.
EN: So that degree of sharing is different than the question that
Thomas is asking.
IvB: Discussions about a database for id/locator mapping. Aren't
we getting ahead of ourselves, how about fundamental stuff like
functional decomposition? Then these questions are much easier to
answer.
JT: Relates to idea of whether IDs have meaning across different hosts
or different applications on the same host. If ID has meaning for
different apps/sockets on the same host, you might choose to implement
it by caching at the application layer. Some of the socket info is
application layer, some of it is transport layer. That's part of why
socket isn't a good term, be more specific.
Qing LI (QL): Socket/application layer info is quite important for
proxy appliances - if ID is used for authorization it's important to
look it up.
EN: On the 2nd bullet: It might depend on other assumptions; if you
have a solution that has a seperate new ID space where you might not
be able to discover locators from an ID, making sure you don't throw
away the state too early might be critical - youc ould have a
transport connection to a HIP and you threw away the locators.
EN: On the other hand, if you can discover it again e.g. in the noid
case, you may discard the state early since you can recreate it. The
other question is, does allowing the two ends to forget state
independently introduce security implications, if one forgets and the
other doesn't? A has forgotten, so I can pretend to be A.
DC: We used to have access to one locator. Now we have a pool that go
to the "same place". The pool is the state. That's not even a new idea
at the IP layer. Routing tables are maintaining this kind of
state. I've always been thinking of this as transport question -
you're doing routing and state maintenance in multi6; we call it state
when it's only on the endpoints but it's not 'state' when it's
routing.
BC: Page 11: "Some Questions (4)". My questions about routing are much
like Geoff's; probably no need to spend much time on this slide.
GH <via Jabber>: Yep - I had put forward the view that site exit
router selection and a reliable mechanism for unicast reverse path
filtering were 2 aspects of the same outcome and the second was going
to be easier than the first.
TN: Another question of level: small change, perhaps.
EN: Definitely cannot depend on a change. What about asking the
routing protocol for "this path might be flaky"?
KL: Do we believe in Moore's law more than we believe in protocols?
Do we think it will be enough?
BC: And we're clearly not expecting someone to implement BGP 5.5.
IvB: it's too bad Geoff isn't here because he would have lots to
say on how BGP scales
EN: I wasn't trying to propose that routing solve the whole problem,
just communicate some bad news.
IvB: BGP *does* communicate the bad news.
BC: Page 12: Some questions (5):
Can we make a functional decomposition, e.g.
Component to establish mh session state
Component to trigger rehoming
Component to choose new address pair
Component to execute rehoming
Component to delete mh session state
BC: This is by no means a proposal, just an example of what we
might want to aim at.
EN: I think 2 and 3 are easier to seperate out than the others. To
what extent is management of session state tied in with informing the
other end? It can get hints from various places that can trigger
this.
JL: Is the point here to ask "should we do a functional
decomposition?"
BC: "will we have enough info to do functional decomposition?"
"should we do so?" "where should we do so?"
JL: We have enough to start making the decomposition. if we try to get
it complete we may never finish it. Take our best shot and live with it.
DC: And now we have 35 proposals and have to combine/transform them
into one result. Something like this is fundamental for a space like
this. We need a series of narrow-scope evaluations that we can then
combine. It leads to some decisions about what might be near-term vs
what might be long-term. It's not clear that near-term we can get by
with something utterly trivial and do the full thing long-term.
BC: I suggest we say "this is a question for the WG in general: whether
this approach is fruitful, when we should tackle it".
IvB: hard to answer this without some idea of what we're going to
select out of the 35 proposals.
BC: matrix problem, so I want to get on to Kurt's presentation.
IvB: Want to see how many of the 35 we can make disappear before we do
this.
BC: may find things that have already been proposed, clearly relates
to one of these components but not to the others.
GH <via Jabber>: Working on it.
BC: Last slide - "Some questions (6).
Can we group proposals into 3 or 4 classes and analyze them against
Goals
Things to think about
Threats
Architectural decomposition?
First cut at categorization of drafts:
Kurtis Lindqvist used his slides at
http://ops.ietf.org/multi6/multi6-interim-draft-list.ppt.
The adjusted list is at the end of this section.
KL: This list of drafts is not random: it is an attempt to categorize
them. And not everybody might agree with categorization; I might not
even
agree with them. I spent the morning in Starbucks drinking way too
much coffee; short recap of each draft on this. All on the first page
are based around structured addresses, structured address allocation
or such.
EN: Are you saying 1st list is things that say a single
locator/address?.
KL: Not necessarily; this is just a list of drafts.
KL: 2nd slide: various mobileip-based, rewrite, external rewrite,
tunnelling drafts.
KL: 3rd slide: transport-layer like sctp, also approaches like 8+8,
mast.
DC: You're trying to find categories to aggregate these into? I'd
think that Geoff's paper describes categories you could use, there
should be correlations between this exercise and Geoff's categories.
KL: I tried to use Geoff's appendix as a basis. But we are getting to
those slides.
GH <via Jabber> : I think these could be meshed to a single form of
categorization
KL: Going through slides, listing each type.
EN: Trying to understand what "tunnels" mean, since all have some
notion of seperate IDs and locators.
EN: Packet format on the wire is different, hack that NOID does to not
have any extra data could be extended to others; tunnelling could be
somewhat eliminated in the same way. Could say we have locators of
different flavors: home locator and temporary locators, somewhat like
mobileip. To me "tunnel" is not the most important characteristic.
GH <via Jabber> : Tunnelling for me is where the association is
carried in the packet, rather than in held endpoint state. I.e. where
you hold the association is a form of categorization
IvB: The reason I called my proposal tunnelling was because if you see
info that is aggregated away when packets were on the wire and you add
it back to the packet it looks like an ordinary tunnel.
BC: At one level, there's a functional equivalence between tunelling
and implied/shared state, but I think there's a real difference since
there's the problem of state synchronization; if the state is in the
packets then the problem is not necessarily there.
EN: One locator could be an alias for another locator.
KL: This is the first category. Does anyone think any of these
proposals are going to help us get any further? <silence>.
BC: We got two questions: do we agree on the categories, and second,
can we wipe out a few?
JL: Even if we kick out categories we should document them, people
tend to come back to the same ideas.
KL: It will be in the minutes.
TN: Agree with John.
Marcelo Bagnulo (MB): I don't understand this category. Singe address
solutions in there, multi address solutions, partial solutions...
KL: I've already taken out drafts that weren't proposals by
themselves. But, yes I agree this is the hard to categorize stuff.
TN: It would be good if the authors agree with the categorization.
BC: Name should capture common feature.
JL: We may want to reuse pieces from these drafts, but not spend too
much time.
KL: These are the drafts with the least support.
TN: But then that is the common feature. Say what part of the draft
doomed it.
BC: Too much work.
EL<?>: Merge everything into one proposal, have groups convince us that
their proposal is good.
KL: If we take things off this list it doesn't mean they disappear.
MB: If you want a category, there are two types, non-pa-compatible
(using one
address), other category is Ohta-san and his friends.
EN: To what degree are those drafts on the list still alive?
IvB: Two of those drafts are mine. One is old, forget about it, the
other has no support so if you want to drop it for that reason that's
ok, but don't tell me it is no good because i still believe in it...
David Kessens (DK): Approach authors. We basically have two classes:
drafts that are for discussion, these can be quickly killed by talking
to the author. Other type is where author strongly believes, this will
be more difficult. If people want to keep their stuff we should
encourage them to work together with others.
Jens Kristian Kjaergaard (JKK): Isn't it more important to agree on
the categories?
BC: I like the notion of challinging the authors within clases to come
up with a unified approach but deadline isn't San Diego.
JL: Drop proposals by default rather than keep them around by default.
TN: We want to encourage work in promising areas, discourage
un-promising. No sense in asking people to come up with a unified
proposal for categories we think are no good anyway. "Rough categories
and running code".
JT: Avoid kicking documents by category, people will want to move
KL: categories: - "intermediate systems".
MB: Can go, Michel is no longer active.
KL: host based, "host signaled".
IvB: Naros is valuable and only does one small thing, keep it and not
in this category.
EN: Naros not on the critical path.
KL: Create something for stuff like this - components rather than
solutions.
EN: Huitema draft is also a component draft. It says the main issue is
source address stuff and this is how to solve it. If we can put drafts
in multiple categories that would be be appropriate.
KL: Don't think I want that.
MB: Most proposals deal with a specific issue, we're going to take
away parts from more than one to build a solutions.
KL: Category "Aliasing" (instead of tunneling)
MB: Mobility draft explains why mip can't be used for multihoming, not
a solution.
AF: I've always thought of hip as a wedge solution, surprised to see
it listed as tunnel.
JT: I've always seen it as a tunnel
KL: Agree. Let's move it to "Fat IP / Wedgelayer 3.5".
KL: Category transport solutions.
KL: Category wedge layer 3.5
IvB: Geoff made distinction between wedge layer and modifying the
network layer but no such distinction here.
KL: We're going to have a component category. These aren't things that
we either want to kill off or work on, just stuff we want to look at
again later. We're down 3 proposals so we're making progress. Do we
split the 3.5 category into wedge layer and modifying ip?
GH <via Jabber>: The distinction was subtle - its was a case of
seperate syncronization wit the remote end vs coupled synchronization
of state with the transport session.
BC: The OSI reference model forgot to be recursive. Implementation as a
shim
or modify ip comes up later.
BC: Margaret Wasserman is supposed to call in, but apparently not
right now.
KL: I was expecting more discussion.
BC: John <JL> said that : NSIS people thought NSIS was a solution?
JL: NSIS is looking at on-path signalling. NSIS people want to have
something to handle multiple paths.
BC: NSIS is stil looking at the world as a soft state universe, right?
JL: Yes.
BC: Unless there is a draft, we have nothing to discuss here.
KL: Wedge layer class is now "FAT IP / Wedge layer 3.5".
KL: So can we kick out more drafts?
Aliasing / tunneling category is going away, remaining draft was ODT,
now going to wedge.
BC: I suggest that most of the de-aggregated proposals are not to be
pursued further.
BC: Only a few of these have been presented at the IETF. We still need
to take this to the mailing list.
BC: <have a large sheet of paper (not viewgraph) to discuss. evolved
during coffee break>.
BC: The next steps are obvious and not...
BC: The obvious part is we can see a path on how to make progress on 4
drafts which are deliverables. The 4 drafts - threats (Nordmark) ready
for San Diego. Things to think about - kept alive somewhat
longer. <alive = in progress; threats ready for last-call after san
diego>.
BC: How multihoming works in IPv4 - much needed; hopefully version
ready to discuss in SD.
GH <via Jabber>: I'll have architecture -01 raady in 1 -2 weeks from
now.
KL & BC: Will post about categories to mailing list; goal to
crystallize discussion and/or omit some.
BC: Needs to designate an editor in each area.
Margaret Wasserman <via telephone> (MW): Has it been determined which
drafts are still alive and which are to be dropped?
BC: Sort of; based on the categories.
??: Does this mean a editor for each category or multiples?
BC: Single editor per se is premature.
KL: Authors should agree to work as a group; can appoint someone from
that group.
BC: Need point-person ('stuckee') to ensure it all happens.
??: Multiple drafts = multiple 'stuckees'.
BC: Chairs won't micromanage. May appoint micromanagers.
MW: If we assign editors - one of the authors or neutral?
BC: It depends; some may agree, some may not.
MW: May go with design team approach.
BC: May formalize as design team in the process, but teams aren't
agreed as a good process method.
IvB: Merge parts of the docs?
BC: Hesitatingly agrees, but diplomatically suggests caution.
IvB: WG already behind on milestones
BC: Those milestones are gone.
IvB: We haven't done much technical progress today. Mostly procedural.
EL: Takes exception. There weren't 30 proposals 6 mos ago; lots of
good recent work, esp. due to chairs. Problem is complex. How do we
move forward? Brian and Kurt's proposals are constructive. If authors
are really interested in solving problem, they can do 1) work with
others, or 2) copy from others. Let's wait for running code; it's the
code that matters.
BC: Part of the challenge - show us running code. So far, except for
SCTP and HIP (only part of soln), no code yet.
JL: Creating categories is useful. Also ... if categories are
described well, still useful to have outside editor help
synthesize. Having Eric do that with noid, etc. was good in this
regard.
BC: Can this be integrated w/Geoff's doc, esp. w/Margaret's appendix?
JL: More concerned with content than process.
GH <via Jabber>: Yes - that was my understanding.
BC: Volunteers to help writing are welcome.
BC: What next?
DC: Let's spend some time defining layer 3.5 and picking the
number. that'll consume time.
BC: Thanks to Kurtis for the coffee
BC: Thanks Iljitsch for networking, et al. - very IETF style
GH <via Jabber>: And thank you jabber scribes.
KL: Thanks scribes!
KL: We're not chartered to come up with a full-fledged protocol;
important point to keep in mind.
BC: If this weren't hard, it wouldn't take 3 years to get to a
solution. That sounds horrible if you're "young and impatient". Problem
has
been lurking since beginning of IPv6.
Jordi Palet: One thing I'm missing is still 'set of use' cases; one
discussion
on mailing list w/fortune 500 companies. Is Multi6 for residential?
Small businesses? It would be useful to consider.
BC: I wish those use cases would just appear. We had the same problem
with scenarios in NGTRANS before V6OPS. Their scenarios work started a
long time
ago and has taken approximately forever. These are hard to come up
with. We know
there are multiple categories. fortune 1000, drive-by's, etc. - there
are a bunch. I'm scared of v6ops analogy to launch an effort. It's too
hard to get to a conclusion.
KL: Difference between multihoming and transition. Load sharing,
etc. They're the same for everyone. Transition has more cases.
BC: Don't want to commission "use cases doc"
BC: Are we done?
<room - yes>
The outcome of the discussion was a suggestion to split the proposals
in the following categories:
A. Addressing based
* draft-kurtis-multihoming-longprefix-00.txt
draft-savola-multi6-asn-pi-01.txt
draft-ohta-multihomed-isps-00.txt
draft-toyama-multi6-operational-site-multihoming-00.txt
draft-ohira-assign-select-e2e-multihome-01.txt
draft-van-beijnum-multi6-isp-int-aggr-01.txt
* draft-van-beijnum-multi6-2pi1a-00.txt
draft-ohira-multi6-multilink-auto-prefix-assign-00.txt
draft-teraoka-multi6-lin6-00.txt
B. "Intermediate systems"
* draft-bagnulo-multi6-mhexthdr-00.txt
draft-py-multi6-mhtp-01.txt
C. Hostbased
draft-huitema-multi6-experiment-00.txt
draft-huitema-multi6-hosts-03.txt
D. Tunnels
E. Transport
draft-coene-sctp-multihome-04.txt
draft-coene-multi6-sctp-00.txt
draft-arifumi-multi6-tlc-fm-00.txt
draft-ohta-e2e-multihoming-05.txt
draft-ohta-multi6-8plus8-00.txt
F. Wedgelayer 3.5 / Fat IP <KL to supply 2-3 sentence description>
draft-nordmark-multi6-cb64-00.txt
draft-nordmark-multi6-noid-01.txt
* draft-nordmark-multi6-sim-01.txt
draft-ylitalo-multi6-wimp-00.txt
draft-crocker-mast-proposal-01.txt
draft-nikander-multi6-hip-00.txt
draft-van-beijnum-multi6-odt-00.txt
G. Components
draft-de-launois-multi6-naros-00.txt
draft-crocker-celp-00.txt
The "Components" class are proposals which contains functional
elements, which can be incorporated in the above categories.
Way forward:
============
Find and define the categories and group the proposals
accordingly. Try to merge the proposals from each category.
The initial categorization of the current proposals is above
Kurtis and Brian formulates separate mail going to the multi6
mailinglist describing the categories and the split of the current
drafts into these categories.
After consolidating the list of drafts in each category the next step
is to workout a unified proposal for each category, and use this to
provide a set of alternative solutions.
7. Conclusions of meeting and where to move from here.
======================================================
1. Progress on drafts:
The "IPv4 multi..." and the "threats draft" should be revised to be
ready for working group last call after IETF meeting in San Diego.
The "things to think..." draft and the architecture draft need to stay
in sync with work on solutions and could be targeting working group
last call after the IETF meeting in Washington scheduled for November
2004.
2. Solutions
- Issue mail defining the categories (Kurtis + Brian)
- Challenge authors (in some cases)
- Suggest withdrawal
- Designate editor for each category.
Editor could be one of the document authors or some moderator.
Design team(s) could be used later in the process.
The synthesis from each of the categories could eventually go into
Geoffs document.
It could be good to document the multi6 use cases, but experience from
v6ops is not very good.
Acknowledgements from the meeting
=================================
To Autonomica AB for sponsoring refreshments, meeting room equipment
and connectivity.
To IPv6 Forum/US IPv6 Task Force for providing meeting room.
To Iljitsch van Beijnum for providing network connectivity during the
meeting and streaming
and recording the meeting.
Appendix - additional notes on discussion
=========================================
The following is a list of comments and statements issued during the
process leading to the above categories. Brian Carpenter's questions
at page 8 on in his presentation formed the basis for the discussion.
Elliot: Geoff architecture should be sufficient background to continue
evaluation.
Iljish: Initiating new session after an outage need further work.
John Loughney: Functional decomposition should be added to Geoff draft.
Otherwise not much missing.
Some comments slide 9
Transport needs to know of ID not multi homing.
Some modifications are needed for transport layers and applications.
Some comments slide 10
The question: "Is it reasonable that socket state can include MH state?"
Cannot be answered currently.
Some questions slide 11
Brian - most were already addressed by Geoff
Thomas - most of the questions depend upon the results - depending upon
the bang for your buck.
Erik - Maybe should ask what changes are dependent upon, but you may
not be able to depend upon the changes to be made.
Bill - Supports Thomas' view.
Illitsch - Wants to know why we are talking about BGP
Brian - this was just an example, not a proposal.
Kurtis - do we think it can scale? We are here because it doesn't scale.
- - small side discussion on BCP scalability ...
Some questions slide 12
can we make a functional decomposition?
Erik - points 2&3 may be easy.
John - are you proposing that we start a decomposition
Brian - Two questions - do we have enough info to make it & should we
make it?
Dave - I think we need to do this. We need to break it into pieces.
Brian - question to the WG - is function decomposition a good direction
& when to start the activity?
Illitsch - should we start this if we haven't started making a choice
on the solution. We should make some of the proposals disappear.
Brian - we may find out that some of the proposals relate to one of the
pieces.
Illitsch - we know some things that we want, but don't agree on all of
them. Narrowing down the choices will help.
Some questions 13
Can we group proposals into 3 of 4 classes and analyze them?
Kurtis has tried to order them according to Geoff's list.
list of drafts
various solutions based around the structure of the address;
various solutions based around mobility, routing, tunneling
various solutions based around transport layer solutions
Dave - are you trying to find categories to group them. I think
Geoff's draft has a grouping, and if the draft is wrong, then it
should be updated.
Comments on tunnels:
Is there a conceptual difference between tunnels and other multi6
solutions?
Is tunneling a category on its own?
Suggestion for renaming tunnel category to aliasing, representing the
cases where on locator may be aliasing another locator.
(end of minutes)
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBQOEWwaarNKXTPFCVEQJg0ACgqN81/KSugu5ciCpcz7TeVaJS9q4An25C
yJoVVqtMkhXM9LWRwK4R+aou
=E88P
-----END PGP SIGNATURE-----