[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of draft-ietf-v6ops-nap-02.txt
Margaret Wasserman wrote:
> FYI --
>
> Here is the message I mentioned in today's meeting. My questions are
> near the end.
>
> Margaret
>
> ---
>
> Begin forwarded message:
>
> > From: "Margaret Wasserman" <margaret@thingmagic.com>
> > Date: June 28, 2006 5:17:16 PM EDT
> > To: <v6ops@ops.ietf.org>
> > Cc: "'Tony Hain'" <alh-ietf@tndh.net>, "'Tim Chown'"
> > <tjc@ecs.soton.ac.uk>, "'Radia Perlman'" <Radia.Perlman@sun.com>,
> > "'Alex Zinin'" <zinin@psg.com>, "'Erik Nordmark'"
> > <erik.nordmark@sun.com>, <Donald.Eastlake@motorola.com>, "'Dave
> > Oran'" <oran@cisco.com>, "'Bill Fenner'" <fenner@research.att.com>,
> > "'Jari Arkko'" <jari.arkko@piuha.net>, <david.kessens@nokia.com>
> > Subject: RE: Review of draft-ietf-v6ops-nap-02.txt
> >
> >
> > Hi All,
> >
> > As I understand it, there is a current proposal in the v6ops WG (in
> > draft-ietf-v6ops-nap-03-draft0.txt) to publish the following
> > recommendation:
> >
> > There are other possible scenarios for the extreme situation when a
> > network manager also wishes to fully conceal the internal IPv6
> > topology. In these cases the goal in replacing the IPv4 NAT
> > approach
> > is to make all of the topology hidden nodes appear from the outside
> > to exist at the edge of the network, just as they would when
> > behind a
> > NAT.
> >
> > o One could use explicit host routes and remove the correlation
> > between location and IPv6 address. In the figure below the
> > hosts
> > would be allocated prefixes from one or more logical subnets,
> > and
> > would inject host routes to internally identify their real
> > attachment point. This solution does however show severe
> > scalability issues and should be limited to uses with
> > substantially fewer than the maximum number of routes that
> > the IGP
> > can support (generally about 50,000).
> >
> > [...snip...]
> >
> > Internet
> > |
> > \
> > |
> > +------------------+
> > | Simple Gateway | Logical subnet
> > | or Home Agent |-+-+-+-+-+-+-+-+--
> > +------------------+ for topology
> > | hidden nodes
> > |
> > Real internal -------------+-
> > topology | |
> > | -+----------
> > -----------+--------+
> > |
> >
> >
> >
> > The more I think about this proposal, the more questions arise,
> > such as:
> >
> > (1) Do we really mean that the router in this picture would be a
> > "simple
> > gateway or home agent"? I don't think that is consistent with the
> > idea that
> > it could handle 50,000 routes. Or that it would run an IGP, for that
> > matter.
Clearly if the network has 50,000 devices it is no longer 'simple'. The
mechanism works for the simple router case when the number of devices aligns
with the context of a 'simple' network.
> >
> > (2) What mechanism would hosts use to inject host routes into the
> > IGP?
They participate in the IGP as 'routers' for the set of addresses the host
might be using.
> > How is that secured?
In what ever mechanism the network uses for securing its IGP. If your real
question is about 'trust of hosts' vs. routers, the point that needs to be
kept in mind here is that in simple networks the policy manager is the same
between the hosts and routers.
> >
> > (3) How will local nodes know to use topology-specific ULA
> > addresses for
> > local communication?
RFC 3484 policy table entry biasing FC00::/7 as preferred over 2000::/3
> > What happens if they don't? Could this
> > result in a
> > large amount of internal traffic bouncing off of the "simple
> > gateway or home
> > agent"?
Yes, if a node doesn't prefer the addressing that will result in the
shortest path, then the traffic will bounce via the topology masking router.
> >
> > (4) How does this interact with multicast traffic and ND.
ND for the topology hidden unicast & general multicast traffic would route
via the topology masking router.
> > Can anode on the
> > "logical subnet" send a link-local multicast packet on the logical
> > subnet
> > and safely assume that it will reach all of the nodes on that
> > subnet and no
> > one else? If not, how does this interact with ND?
One needs to pay attention to the distinction between 'link' and 'subnet'.
If a node is part of a logical subnet and knows it is not directly connected
to the link attached to the hosting router (because the flag is set to
not-on-link for that prefix), then it should not assume anything about LL
reachability of any other member of the subnet. ND will work as defined, so
the topology hidden node will use its LL to talk to whatever router is on
the link, then use routing to get to anything else.
> >
> > (5) Would autoconfiguration be used on the logical subnet, or would
> > hosts be
> > expected to get those addresses through other means?
They would have to use other means because they need to also inform that
node that it is supposed to use that address rather than whatever might be
offered for where it attaches.
> >
> > (6) What advantages (if any) does this approach have over using a
> > single
> > subnet internally and using L2 switches and VLANs to handle
> > internal packet
> > delivery? What disadvantages does it have when compared to that
> > approach?
That works. We specifically took it out of the initial draft because it was
not an IP level mechanism. I put it back after hearing you were concerned
about it. The primary disadvantage is that all traffic has to route via the
topology hiding router, and the L2 has to have the means to create the vlan.
> >
> > (7) How does this proposal relate to the work currently underway in
> > the
> > TRILL WG?
It doesn't. TRILL is trying to logically concatenate links. This mechanism
is simply using MIPv6 or Host routes to make the host appear at the edge of
the network like it would in an IPv4/nat case.
> >
> > If we decide that we actually want to make this recommendation,
It is not a BCP, it is simply information.
> > I'd prefer
> > that we remove it from this document and make this recommendation in a
> > separate document that covers the scalability issues, the answers my
> > questions above, and any other factors that may affect the
> > applicability of
> > this solution.
A BCP should be a separate document. The full -03 round of edits covers the
scale issue. It is not clear to me that it needs to be a primer on IPv6 to
discuss the distinction between link and subnet and how ND works.
Tony
> >
> > Margaret
> >
> >
> >> -----Original Message-----
> >> From: Fred Baker [mailto:fred@cisco.com]
> >> Sent: Wednesday, June 28, 2006 4:00 PM
> >> To: Margaret Wasserman; Dave Oran; radia.perlman@eng.sun.com
> >> Cc: 'Tony Hain'; 'Tim Chown'; v6ops@ops.ietf.org
> >> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt
> >>
> >> Radia and Dave:
> >>
> >> There is a dispute going on regarding the scalability of
> >> topology hiding by what amounts to IS-IS level 1 routing
> >> (identifying hosts in a multi-LAN network by their host
> >> identifier and using a common subnet ID for the domain). Do
> >> you know of available documentation of IS-IS level 1 routing
> >> and its tested scalability?
> >>
> >> As Radia knows, this question is also being looked at in IEEE
> >> 802.1, which presumes that there is only a single
> >> multi-LAN-LAN, and that MAC addresses are used to route within it.
> >>
> >> Fred
> >>
> >> On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote:
> >>
> >>> 50K is an order of magnitude higher than the analysis in
> >> Alex Zinin's
> >>> presentation would seem to indicate. His presentation
> >> indicates that
> >>> flat
> >>> routing will only scale to something on the order of 1K nodes.
> >>> Please feel
> >>> free to check with Alex, though, as he certainly has more
> >>> understanding of IGP scaling than I do.
> >>> [snip]
> >>> If this document is going to recommend doing flat routing
> >> for topology
> >>> hiding, I think that the WG needs to do the analysis to
> >> determine that
> >>> this is a valid and scalable technique.
> >>
> >
> >