[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Minutes / Notes
-----BEGIN PGP SIGNED MESSAGE-----
Please find attached Geoff minutes from yesterday. Please send comments
to me _off list_ and I will add them.
You have one week to comment.
- - kurtis -
> Multi6 - Wednesday AM
> Wednesday slot
> - - Administrivia, Chairs, 5 min
> Notes: Geoff Huston
> Agenda change: Add Pekka's second presentation that was deferred from
> ** Humming to keep the v4 multi-homing it in the charter.
> ** Vince Fuller volunteered to review Joe Abley's Draft.
> ** Christian Huitema to accept a role in a second design team using an
> approach drawing on mobile-IP mechanisms with multi-addressing
> - - draft-savola-multi6-nowwhat-00.txt, Pekka Savola, 15 min
> The assumptions in this draft is that one size does not fit all
> its very long term, and different sites have different requirements
> priorities. The draft advocates a piecemeal approach to the problem.
> Break down the problem into a set of generic 'sites' and for each
> at their motivations, timeframes and timeframe. Then look at shorter
> measures that may be applicable. The classification is 'minimal,
> 'small', 'large' and 'international and the slides / draft has the
> details of the classification
> Matasaka Ohta: Do you mean that a site may be geographically separated?
> Pekka Savola: yes
> Matsakata Ohta: So full internal connectivity is a requirement for a
> Pekka Savola: yes
> Erik Nordmark: Its been very fuzzy as to what is a site and its in the
> charter. Its ranged from campus to organization with internal
> connectivity, and we don't need to decide what it is here again.
> The motivations listed include ISP independence, redundancy, load
> sharing, and the various aspects of these three areas. Looking at the
> solutions and how they map to this classification it appears that
> connecting (same ISP) has some relevance to some shorter timeframes
> some instances. The presentation listed some mechanisms against
> timeframes (see presentation).
> Matsakata Ohta: How long is "short" etc in terms of time
> Pekka Savola: no firm definition, but 'short' means around a year
> Matsakata Ohta: I think that is very long.
> Conclusions in the draft were that multi-connecting is good and
> be used more for bigger enterprises. Id/Locator separation in hosts
> prevail, but it is not a universal solution to the entire problem.
> Minimal sites may not have a high demand for multi-homing. Smaller
> may use multi-connecting, and larger cases may use host-centric with
> multiple PA space. At the larger size PI space with AS is a more
> solution. The presentation has a large list of work to be done (see
> presentation). Advocate working on short term solutions with host-
> centric/site-exit when ISPS use Ingress Filtering and how to work
> a 1500 octet bounded MTU to the external provider. Pekka advocates
> working on documenting how to do renumbering or how to, at the least,
> make renumbering easier. His list of open issues are one size fits
> or piecemeal solutions, specific architectured solutions vs available
> tools, and how to deal with 'difficult' requirements.
> Matsakata Ohta: What is meant by 'available'
> Pekka Savola: something that has not been made up specifically. If its
> implemented its available.
> - - Presentation from the design team, Iljitsch van Beijnum, 20 min
> Design team members: Tony Li, Erik, Pekka, Mike O'Dell, Sean Doran,
> Katz, Brian Carpenter, Iljitsch van Beijnum.
> Look at the general overview rather than specific details. Their
> definition of multihoming is connection to same ISP more than once,
> more than 1 ISP. Expectations of redundancy/failover without
> reconfiguration or manual intervention, load sharing across available
> external connections and some concept of 'provider independence", by
> being easily 'moveable' from ISP to ISP. The IPv4 approach was to
> use PI
> space and announce it in BGP through upstreams. This had an observed
> routing table pressure. Current assignment policies limit this to
> sites with the minimum allocation size and minimum immediate take-up
> levels. For others the approach is to use PA space and multi-announce
> the PA fragment. This still requires renumbering on ISP mobility,
> together with filtering issues and ISP policy associated with PA
> Multiaddressing is claimed to not really work in a multi-homed
> in V4. NAT has been advocated in this context as well, and it may
> some aspects easier, but it fails to gain real traction in V4. The
> translation to IPv6. The claim is less than 25,000 multi-homed
> in the V4 network today. The projection given in the presentation
> to 10M to 1G routing table as an eventual outcome, and its claimed
> this is processing infeasible. Very large routing tables was claimed
> have other hardware-related limits in terms of CAM sizes. For longer
> term scalability the presentation advocated multiaddressing with
> provider aggregateable address blocks and following provider
> aggregation. Multiaddressing is not multihoming. The reachability
> is (source addr, exit ISP, dest addr). The preference is to be able
> set these independently, but with ingress filtering on source address
> there is a need to match source addr to the selected exit ISP, and
> exit ISP depends on the destination address. The Socket API expects
> sessions with a 128 bit destination and source identifier field.
> Breaking the API is not a path for multihoming. The V4 to V6 API
> migration is advocated as a one-off exercise, rather than a precedent
> for further API changes for multi-homing. The conclusion drawn is
> applications at the API wants to see 1 address and the network needs
> multiple addresses. This was called out as an opportunity for a
> level of indirection (David Wheeler)
> Fijikawa: So you are saying that you don't want to change the API?
> Iljitsch van Beijnum: Having to change the API for multihoming is a
> big problem that may not be deployed for a long time
> Fujikawa: So multihoming should be done without modifying the API?
> Iljitsch van Beijnum: yes
> Christian Huitema: I was interested in 2 points: multi-addressing does
> work and the solution has to be based on multiaddressing. A draft of
> points that break in multiaddressing today is a good idea.
> Iljitsch van Beijnum: the focus is on TCP and you can't have a TCP that
> switches addresses mid-flow because you don't have API support
> Christian Huitema: The reason here is the protocol specification of
> not the API
> Iljitsch van Beijnum: Obviously we can modify TCP without the API but
> see modifying the network layer
> Christian Huitema: The socket API constrains the solution you are
> that the socket API is the problem. A large number of applications
> use a
> higher level API. There are other APIS such as "connect by name"
> we cannot move on the API is not necessarily true.
> Iljitsch van Beijnum: that's a viewpoint of course but I'm resorting
> design team
> Kurtis Lindqvist: Is Christian's comment specific or generic?
> Christian Huitema: It would be nice to have a list of things that are
> working in multiaddressing, so if you have to go down this path you
> what must be done.
> Erik Nordmark: Maybe we are confusing things with terminology here.
> Multiaddressing is not a clearly defined term, and it is used in a
> specific context in this presentation. Location / identifier
> observes that identifies are stable objects used by transport
> and applications, Locators are dynamic objects used to forward
> through the network. The approach is to map a domain name to an
> identifier and map the identifier to one or more locators. One
> is tunneling of an inner identifier with an outer locator packet
> More complex methods use 64 bit locators and 64 bit identifiers in
> IPv6 address. This may ring some bells for some people as it similar
> earlier proposals. The 'big' approach is 128 bit locators and
> identifiers, and only one of these is in the 'outer' header at any
> point in time, but they can be swapped. Tunneling is simple and
> implementable, but have problems with the 40 byte per packet
> the co-location of tunnel endpoint to end host, and
> issues. The 'small' (64 bit) is that the host needs only know its
> identifier, but there is an unstructured MAC address namespace that
> cannot aggregate easily. Can't trust incoming locator/identifier
> associations when you receive them. An attack path is to send an own
> locator with a target identifier to divert traffic to the attacker.
> There are changes to both hosts and routers to keep transport
> working, and this can be slow. The 'big' (128 bit) has no per-packet
> overhead, and can be implemented in either hosts or middle boxes. But
> additional mechanisms and state are required for this mapping to be
> maintained. All mechanisms use a distributed database to find current
> locators for a given identifier. The source locator in incoming
> is used as a default destination locator, but the source is
> responsible for selecting a functional destination locator. This is
> a IP
> level association, not a per session association. ISP ingress
> could be addressed with source locator rewrite, and the question is
> whether this is wanted, and what information is lost. Other methods
> be to use ICMP messages or NAROS approach. Consensus in the design
> is the locator/identifier separation. There is agnostic response to
> location within the site where multihoming happens. Don't trust
> associations and the source is responsible for selecting the
> identifier. The practice approach us a name lookup to an identifier,
> and pass this to transport. The transport sender maps source and
> destination identifiers to locator. The receiver maps the locators
> (source and dest) back to identifiers and pass to the application.
> issues are selection of which approach - no design team consensus.
> is the source of the locator and identifier space. Is this an overlap
> with 'regular IPv6" none. Better path selection is necessary in
> terms of
> locator selection, and there are open issues with interdomain
> and in which order to so multihoming in IPSEC
> Matsakata Ohta: What is autoconfiguration?
> Erik Nordmark: RFC2462
> Fujikawa: Its not correct that 'small' needs host and router
> Iljitsch van Beijnum: The way the design team saw it there were changes
> Fujikawa: We believe this is possible without changes to routers.
> Iljitsch van Beijnum: The drafts are yet to be written, so there is a
> problem to describe this in detail
> Sean Doran: Not made the assumption that the first part is necessarily
> CIDR, and if we are not routing on this basis then changes are
> Fujikawa: I don't understand at all
> Alain Durand: Is there strucvture in these spaces or is it required to
> Iljitsch van Beijnum: This was not considered in the design team
> Alain: Is there reverse mapping required from locator to identifier to
> Iljitsch van Beijnum: locators would be regular IP addresses and you
> use the IP6.arpa space, but it did not come up in the design team
> Matsakata Ohta: How large will the routing table be in V6?
> Iljitsch van Beijnum: not discussed in the design team and there are
> different ways to optimize this
> Brian Carpenter: As a design team member, the answer is one of the
> principle reasons for this separation is aggregatable locators, and
> are hoping for a log(n) routing table because of this separation
> Iljitsch van Beijnum: There are different ways to delegate here
> Brian Carpenter: reverse lookup - locator to identifier lookup is
> going to be ambiguous and reverse is probably not going to be
> Erik Nordmark: The structure of identifier was not considered in the
> design team. Personal thoughts are site or larger environments may
> require some simple site / entity structure, but its yet to be
> Lixia Zhang: Pointed to the comments about the untrustable nature of
> locator/identifier associations on incoming packets, yet the design
> is advocating this separated approach. Is this consistent?
> Iljitsch van Beijnum: What is the problem here?
> Erik Nordmark: Don't assume that there is a strongly bound association
> between the two just by looking at received packets.
> - - Open Mike, Chairs, 60 min
> - - Future path for the mutli6 WG, Chairs, 20 min.
> Kurtis Lindqvist:
> We've seen a number of presentations, including that of the design
> There are a few things to discuss first here, and there are WG
> milestones that are lagging.
> There is a requirements document, but there are more on the charter.
> The other document remaining is version 4 multihoming to document
> current multihoming practices Joe Abley has volunteered to complete
> document, and Pekka's document may help. This document has expired.
> Question: should we complete this document or not?
> Iljitsch van Beijnum: forget about it - its too challenging
> Brian Carpenter: its a good document, but its not in V6 scope. Maybe
> negotiate the charter to remove. Its a reasonable thing to take it
> of the charter. There is benefit in documenting IPv6 multihoming.
> Sean: go to the list and ask for it to be dropped or complete it>
> Vince Fuller: The only real multi-homing is IPv4 - what works, does not
> work and scale and does not scale. Its worth progressing
> Iljitsch van Beijnum: no experience that it does not scale
> Vince Fuller: Disagree - we know what does not scale from experience.
> Sean: keep the document?
> ** Humming to keep it in the charter.
> ** Vince Fuller volunteered to review Joe Abley's Draft.
> Kurtis Lindqvist:
> How to move this forward... There are a number of proposals made and
> can't adopt them all as WG items. There is a proposal grouping (4)
> the WGs, based on a single-link (NAROS), Mobile, rest as bottom up,
> do what we already have. Propose to cull them down in terms of
> and move them forward as documents before spending WG time on this.
> we want to stick with a single outcome or multiple solutions. Should
> work in parallel with evaluation or serial? The mailer shows some
> diversity of view as to how to do this. Is there a WG consensus
> Christian Huitema: there is not that much difference between these
> approaches. MobileIP is an instantiation of what the design team
> 'big'. The separation of locator to identifier is a special case of
> multiaddressing. The identifier is pretty much a home address, and in
> this context you can recycle the MobileIP work, including associating
> checking. It is entirely possible to design a path using
> using optimizations with mobile IP and consider a path in which we
> create a virtual address realm of identifier as one of the multi-
> addressing option - this is a simple movement without delaying
> on the way.
> Erik Nordmark: So you were comparing mobile IP with the big approach on
> the slides - but that's not what the design team was talking about.
> Mobile IP all used addresses that are used interchangeably and its
> stitched together using tunnel. 'big' is different here - the
> identifiers are not packet forwarding targets, and that's the
> distinction between this approach and mobileIP. There is useful
> IP technology , but it IS different
> Christian Huitema: On the reason why I claimed this was the same
> it is in fact possible to send a packet to an identifier using a
> distributed hash table technology. You send a packet to the
> without ever mapping it to an address by forwarding it on another
> This is equivalent to multi-homing with another address.
> Kurtis Lindqvist: The classification was not a technical one - we were
> simply wanting to limit the number of proposals coming to the WG. If
> there was a 2nd design team working on this other approach then this
> something that we are looking for
> Matsakata Ohta: mobile IPv6 is hopeless and broken. It has timeout of
> second to switchover which is most cases too long. Its server based
> host based. It is tunneling. (?)
> Brian Carpenter; lets not debate mobile IPv6. I wanted to say that I'm
> the tunnel side of the debate with the design team is that its a fast
> way to do id / locator separation and we need to put V1 of an id-to-
> locator mapping and the rest is straightforward. Did no clean up the
> meaning of multiaddressing.
> Sean Doran: Christian would be a good leader for the mobile IP /
> multiaddressing approach design team. If they converge then great, if
> not then lets understand it.
> Randy Bush: write up proposals and allow us to compare them.
> Christian Huitema: part of the reasons I gave the feedback is that I
> believe that the justification for separation is all that high. 1
> is multi-addressing does not work, and we need feedback on this
> claim to
> understand it. The other reason is an API issue and going into an
> architecture rewrite due to an API issue appears to be over the top.
> Matsakata Ohta: a name should lookup to locators - you don't need to
> identifier middle step. we don't need to much mapping.
> Erik Nordmark: on the motivation for the split. The current tools we
> on the table is pass from routing to apps, and applications can't
> Architecturally its a mistake. This additional layer is useful and
> us scale. This is a similar argument with site-locals in V6.
> Kurtis Lindqvist: Can we expect the design team to include this?
> Lixia: what is an identifier? What does it identify?
> Erik Nordmark: Its called "stack" by the NSRG work. To be determined.
> Brian Carpenter: it is exactly a NSRG "stack"
> Lixia: evidence that multi-homing does not work?
> Iljitsch van Beijnum: There are combinations of selection of source and
> destination that do not support a connection. Applications are
> to work across multiple addresses for 'self' and 'remote'. You don't
> want to solve this in every app, and doing this in 1 point is the IP
> layer in terms of the design team choice.
> Lixia: As of today this is not clear. Lets get some facts on this.
> Iljitsch van Beijnum: location and identifier in the packet could
> Matsakata Ohta: (8+8) a host accepts a packet with the low order 64
> matching the local identifier. API is not an issue.
> Christian Huitema: apps do handle multiple addresses - VPNS, etc. Apps
> have awareness today.
> Sean McCLeary: Address the issue of identifier / locator association.
> There are other mechanisms for association that we can use. This
> be a security association in some form. Keeping these separate is
> good -
> you don't care what the locator is as long as it provides confidence
> about remote identity
> Erik Nordmark: Its not proveable multi-addressing does not work. The
> choice appears to be 'add another layer of indirection" or "push it
> the apps layer". Also if you apply IPSEC all the time then you don't
> care about the addresses in every packet as you already have an IPsec
> Vince Fuller: This address mapping today is NOT a form of security, and
> the routing system does not and will not solve this, and the
> split makes the problem more apparent, not any worse. The confusion
> the ID/locator split is a consequence of growing up in a schizo
> world of
> addresses, and we simply have not thought about using them
> Its a TCP identifier in the TCP protocol. The ISO OSI model did
> transport and network. Overload addresses don't work well. You cannot
> change the underlying addresses because they are bound in transport!
> agenda item is that of changing the transport layer. What really
> here is a richer transport layer, and using the identifier to hide
> from the upper layers. Common usage is to bind an id to a host. Is
> Christian Huitema: SCTP shows that transport can be designed to handle
> more than one address. Having an identifier for a session is claimed
> Christian to be more useful than having an identifier for a host.
> Pekka Nikander: Much of this discussion is getting well beyond the
> charter. Security is not just identification - its also denial of
> service. There is a mobile IPv6 security background draft that
> this topic.
> Sean McCleary: Using identifiers to identify hosts rather than
> It is common practices to assign addresses to loop back addresses to
> this explicit host association. This is also a virtual hosting
> Erik Nordmark: Having this additional identifier that is not a domain
> and not a locator is something we need to take really seriously.
> Brian Carpenter: There is an incorrect view that the name is the
> identifier. We don't need a repeat of 9 drafts like Monday with a
> parade. There are probably 3 proposals to sketch out
> - design team approach
> - mobileIP
> - another multi-addressing that is neither of the above
> Erik Nordmark: to early to cut the proposals when we don't appear to
> understand this space well enough. The ID/loc has security and
> issues - how do the practical pieces fit together?
> Sean: You are saying: Please identify when you are making a trade-off-
> what the trade-off may actually be.
> Iljitsch van Beijnum: Propose to concentrate on the design team and
> at other approaches in a manner that is relative to the design team
> output. The consider whether we work on many in parallel, or focus
> WG activity.
> Kurtis Lindqvist: There is some need to aggregate these drafts right
> now -
> we need less rather than more.
> ** Christian Huitema to accept a role in a second design team
> Christian Huitema: willing to accept the 'other' design team proposal.
> There were 4 drafts that were in the context of this multi-addressing
> proposal. There is actually a difference in philosophy here -
> claims the multi-address proposal as being incremental, and that it
> requires no major new piece of software or new infrastructure. The
> locator / identifier split is a major impact on the stacks, it is
> claimed. It is claimed that this will take large amounts of time to
> develop. It is claimed that the loc/id approach is much longer term
> Kurtis Lindqvist: Thanks Christian to accept to lead the design team.
> need some more work on the part of the design teams to assess the
> designs and their impact.
> Peter Lothberg: Claim that this does not solve the routing problem.
> is an assumption of separation. Lets trash V6 and collect
> and start over.
> Erik Nordmark: would like to avoid competing proposals - there is a
> difference of incrementalism and architecture differences. The
> competition approach is not the best way to get mindshare across the
> Kurtis Lindqvist: the design team does need to produce text to allow
> us to
> look at it closely.
> Iljitsch van Beijnum: Words of caution about heading off into an
> new direction.
> Kurtis Lindqvist: we need to get the other approach documented to a
> that they are comparable. There is nothing from the design team as
> and nothing at all from the other group to write up an approach.
> Sean: there is value in looking at various ways of undertaking
> here, and this approach is of value to the effort.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2
-----END PGP SIGNATURE-----