Fwd: Minutes / Notes

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>

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.

Best regards,

- - kurtis -


> Multi6 - Wednesday AM
>
>
> Wednesday slot
> **************
>
>
>
> - - Administrivia, Chairs, 5 min
>
> Notes: Geoff Huston
> Agenda change: Add Pekka's second presentation that was deferred from
>   Monday
>
>
> ** 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
>
>
> Notes:....
>
> - - draft-savola-multi6-nowwhat-00.txt, Pekka Savola, 15 min
>
>   The assumptions in this draft is that one size does not fit all 
> unless
>   its very long term, and different sites have different requirements 
> and
>   priorities. The draft advocates a piecemeal approach to the problem.
>   Break down the problem into a set of generic 'sites' and for each 
> look
>   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
>   'site'?
> 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 
> multi-
>   connecting (same ISP) has some relevance to some shorter timeframes 
> in
>   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 
> should
>   be used more for bigger enterprises. Id/Locator separation in hosts 
> will
>   prevail, but it is not a universal solution to the entire problem.
>   Minimal sites may not have a high demand for multi-homing. Smaller 
> sites
>   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 
> likely
>   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 
> within
>   a 1500 octet bounded MTU to the external provider. Pekka advocates 
> also
>   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 
> all
>   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, 
> Dave
>   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, 
> or
>   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 
> larger
>   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 
> space.
>   Multiaddressing is claimed to not really work in a multi-homed 
> context
>   in V4. NAT has been advocated in this context as well, and it may 
> make
>   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 
> 'sites'
>   in the V4 network today. The projection given in the presentation 
> looks
>   to 10M to 1G routing table as an eventual outcome, and its claimed 
> that
>   this is processing infeasible. Very large routing tables was claimed 
> to
>   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 
> tuple
>   is (source addr, exit ISP, dest addr). The preference is to be able 
> to
>   set these independently, but with ingress filtering on source address
>   there is a need to match source addr to the selected exit ISP, and 
> the
>   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 
> that
>   applications at the API wants to see 1 address and the network needs
>   multiple addresses. This was called out as an opportunity for a 
> further
>   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 
> very
>   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 
> not
>   work and the solution has to be based on multiaddressing. A draft of 
> the
>   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 
> TCP,
>   not the API
> Iljitsch van Beijnum: Obviously we can modify TCP without the API but 
> we
>   see modifying the network layer
> Christian Huitema: The socket API constrains the solution you are 
> saying
>   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" 
> Saying
>   we cannot move on the API is not necessarily true.
> Iljitsch van Beijnum: that's a viewpoint of course but I'm resorting 
> the
>   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 
> not
>   working in multiaddressing, so if you have to go down this path you 
> know
>   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 
> separation
>   observes that identifies are stable objects used by transport 
> protocols
>   and applications, Locators are dynamic objects used to forward 
> packets
>   through the network. The approach is to map a domain name to an
>   identifier and map the identifier to one or more locators. One 
> approach
>   is tunneling of an inner identifier with an outer locator packet 
> header.
>   More complex methods use 64 bit locators and 64 bit identifiers in 
> the
>   IPv6 address. This may ring some bells for some people as it similar 
> to
>   earlier proposals. The 'big' approach is 128 bit locators and
>   identifiers, and only one of these is in the 'outer' header at any 
> one
>   point in time, but they can be swapped. Tunneling is simple and
>   implementable, but have problems with the 40 byte per packet 
> expansion,
>   the co-location of tunnel endpoint to end host, and 
> ICMP/Firewall/PMTU
>   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 
> protocols
>   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 
> packets
>   is used as a default destination locator, but the source is 
> ultimately
>   responsible for selecting a functional destination locator. This is 
> a IP
>   level association, not a per session association. ISP ingress 
> filtering
>   could be addressed with source locator rewrite, and the question is
>   whether this is wanted, and what information is lost. Other methods 
> may
>   be to use ICMP messages or NAROS approach. Consensus in the design 
> team
>   is the locator/identifier separation. There is agnostic response to 
> the
>   location within the site where multihoming happens. Don't trust 
> incoming
>   associations and the source is responsible for selecting the 
> destination
>   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. 
> Open
>   issues are selection of which approach - no design team consensus. 
> Where
>   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 
> multicast,
>   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 
> modification.
> Iljitsch van Beijnum: The way the design team saw it there were changes
>   required
> 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 
> required
> Fujikawa: I don't understand at all
> Alain Durand: Is there strucvture in these spaces or is it required to 
> be
>   flat?
> Iljitsch van Beijnum: This was not considered in the design team
> Alain: Is there reverse mapping required from locator to identifier to
>   name
> Iljitsch van Beijnum: locators would be regular IP addresses and you 
> could
>   use the IP6.arpa space, but it did not come up in the design team
>   issues.
> 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 
> we
>   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 
> probably
>   going to be ambiguous and reverse is probably not going to be 
> possible
> 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 
> discussed
> Lixia Zhang: Pointed to the comments about the untrustable nature of
>   locator/identifier associations on incoming packets, yet the design 
> team
>   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 
> team.
>   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 
> this
>   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 
> out
>   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 
> we
>   can't adopt them all as WG items. There is a proposal grouping (4) 
> from
>   the WGs, based on a single-link (NAROS), Mobile, rest as bottom up, 
> or
>   do what we already have. Propose to cull them down in terms of 
> numbers
>   and move them forward as documents before spending WG time on this. 
> DO
>   we want to stick with a single outcome or multiple solutions. Should 
> we
>   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 
> emerging
>   here?
>
> Christian Huitema: there is not that much difference between these
>   approaches. MobileIP is an instantiation of what the design team 
> called
>   '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 
> multiaddressing
>   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 
> anything
>   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 
> mobile
>   IP technology , but it IS different
>
> Christian Huitema: On the reason why I claimed this was the same 
> problem
>   it is in fact possible to send a packet to an identifier using a
>   distributed hash table technology. You send a packet to the 
> identifier
>   without ever mapping it to an address by forwarding it on another 
> layer.
>   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 
> is
>   something that we are looking for
>
> Matsakata Ohta: mobile IPv6 is hopeless and broken. It has timeout of 
> 30
>   second to switchover which is most cases too long. Its server based 
> not
>   host based. It is tunneling. (?)
>
> Brian Carpenter; lets not debate mobile IPv6. I wanted to say that I'm 
> on
>   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 
> don't
>   believe that the justification for separation is all that high. 1 
> reason
>   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 
> use
>   identifier middle step. we don't need to much mapping.
>
> Erik Nordmark: on the motivation for the split. The current tools we 
> have
>   on the table is pass from routing to apps, and applications can't 
> cope.
>   Architecturally its a mistake. This additional layer is useful and 
> helps
>   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 
> expected
>   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 
> improve
>   something.
>
> Matsakata Ohta: (8+8) a host accepts a packet with the low order 64 
> bits
>   matching the local identifier. API is not an issue.
>
> Christian Huitema: apps do handle multiple addresses - VPNS, etc. Apps 
> do
>   have awareness today.
>
> Sean McCLeary: Address the issue of identifier / locator association.
>   There are other mechanisms for association that we can use. This 
> could
>   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 
> to
>   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
>   association.
>
> 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 
> ID/locator
>   split makes the problem more apparent, not any worse. The confusion 
> over
>   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 
> separately.
>   Its a TCP identifier in the TCP protocol. The ISO OSI model did 
> separate
>   transport and network. Overload addresses don't work well. You cannot
>   change the underlying addresses because they are bound in transport! 
> The
>   agenda item is that of changing the transport layer. What really 
> needs
>   here is a richer transport layer, and using the identifier to hide 
> this
>   from the upper layers. Common usage is to bind an id to a host. Is 
> this
>   correct?
>
> Christian Huitema: SCTP shows that transport can be designed to handle
>   more than one address. Having an identifier for a session is claimed 
> by
>   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 
> explores
>   this topic.
>
> Sean McCleary: Using identifiers to identify hosts rather than 
> interfaces.
>   It is common practices to assign addresses to loop back addresses to 
> get
>   this explicit host association. This is also a virtual hosting
>   technique.
>
> Erik Nordmark: Having this additional identifier that is not a domain 
> name
>   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 
> beauty
>   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 
> mapping
>   issues - how do the practical pieces fit together?
>
> Sean: You are saying: Please identify when you are making a trade-off- 
> and
>   what the trade-off may actually be.
>
> Iljitsch van Beijnum: Propose to concentrate on the design team and 
> look
>   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 
> the
>   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 - 
> Christian
>   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 
> in
>   practice.
>
> Kurtis Lindqvist: Thanks Christian to accept to lead the design team. 
> We
>   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. 
> There
>   is an assumption of separation. Lets trash V6 and collect 
> requirements
>   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
>   group.
>
> 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 
> entirely
>   new direction.
>
> Kurtis Lindqvist: we need to get the other approach documented to a 
> state
>   that they are comparable. There is nothing from the design team as 
> yet
>   and nothing at all from the other group to write up an approach.
>
> Sean: there is value in looking at various ways of undertaking 
> trade-offs
>   here, and this approach is of value to the effort.
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBPxZS4qarNKXTPFCVEQKOWwCfQApi0/okQgr2jVpfdwLWNYLtczwAoKyy
LBt9pzL7MjrlpvLlys0QnwF5
=ryIW
-----END PGP SIGNATURE-----