Short version: Discussion of variants of Strategy A.
Further suggestions of text which would better
describe the Ivip variants - though it may be
too late to change the page now.
http://bill.herrin.us/network/rrgarchitectures.html
Hi Bill,
On 22 December, you wrote:
>> The paragraph directly after "Strategy A." is applicable to Ivip.
>>
>> A1a. This doesn't seem to apply to any proposal I know of.
> A1a. the RLOC = the ISP's AS#
I don't clearly understand this. Do you mean the ISP's Autonomous
System number is used by the existing BGP interdomain routing system
in some way which relates to addressing? Can you give some examples
or point to any solutions which this describes?
# A1b. Each core ISP has a small number of RLOCs for traffic
# engineering (TE). The RLOCs' existence and reachability is
# flood-propagated to the rest of the core.
>> A1b. This applies to Ivip and I guess to LISP, APT and TRRP.
> A1b. Just like A1a except each ISP gets two or three AS#'s that
> they can use and they sort which GUIDs go under which RLOC and the
> priority at which each RLOC is announced to each peer to optimize
> their routing.
I don't interpret A1b in this way at all. My interpretation is that
each ISP has one or more prefixes advertised in the DFZ, typically
one or more per site (such as the ISP's operations in a different
city or country). All ETRs have addresses within these prefixes, so
amongst other things, all RLOC addresses are within these prefixes.
The numbers of these prefixes are something the BGP interdomain
routing system can cop with. ISPs do inbound TE for their various
prefixes by changing how they advertise them to upstream ISPs.
Meanwhile, the Strategy A solution provides globally reachable
address space for most or all end-user networks (for multihoming,
inbound TE and portability) in a form which does not place such
burdens on the BGP interdomain routing system (the DFZ) as does the
only current way of doing it: individually advertising each such
end-user prefix in the DFZ. Specifically, Ivip has a relatively
small number of Mapped Address Blocks, each of which is advertised in
the DFZ, but each of which provides thousands to hundreds of
thousands of separate micronets for end-user networks.
There is nothing in my description concerning AS numbers. It is
basically the current DFZ, with the addition of Ivip and more and
more end-user networks using micronet address space to provide
multihoming, TE and portability.
>> A1c. I don't clearly understand this.
>
> A1a. the RLOC = the ISP's AS#
>
> A1c. Each ISP gets a big block of locators, such as 251.1.0.0 -
> 251.1.255.255. They don't announce each one to the core; they announce
> the aggregated set, such as 251.1.0.0/16.
OK - that is one way of doing my understanding of A1b. The ISP
advertises as many prefixes as it needs for its sites to have the
degree of TE they require.
If most end-user networks are on micronet spaces, then these do not
need to be particularly large blocks of addresses, since the ISP will
primarily use them for RLOCs (ETR addresses) - and presumably ETRs
won't need to be anywhere as numerous as the IP addresses of the
end-user networks.
Still, ISPs will probably have large blocks of address space, because
in addition to using this space for ETR addresses (RLOCs) and for
their own servers etc. they would also presumably still have large
numbers of customers who are not multihomed and are using PA
prefixes. This includes especially the large number of residential
and small business customers who get a single IPv4 address via DSL,
cable modem or fibre.
> I haven't really checked but I suspect most of the proposals these
> days look like A1c. We can probably reject A1a and A1b on the grounds
> that A1c has the same or lower implementation price and is obviously
> better.
I don't see A1c as having any important architectural distinctions
from A1b.
>> A3b. End-user networks are responsible for controlling the
>> mapping of their EID address space. Each EID prefix
>
> I'll add the sentence, "The external analysis element may be under the
> control of the end-user destination network, the RLOC network or a
> third party under contract to one of them."
OK. Hopefully people will recognise this includes Ivip and that the
"depreferencing or removing the affected RLOC" is not a good
description of Ivip's approach, which is:
To have only one RLOC in the mapping information: the one that all
ITRs should currently use, since it is the one chosen directly or
indirectly by the end-user network, and sent in real time
to all the ITRs which need this mapping information.
>> OK, the current A4d is a terse description. Folks will need to refer
>> to http://www.firstpr.com.au/ip/ivip/pmtud-frag/ to see how Ivip does
>> this. I think no other proposal currently incorporates proper
>
> I'd prefer "concise," but I guess I'll settle for terse. :)
OK, but there is more to it, such as being able to cope gracefully
with the transition to jumboframes in the DFZ, and the lack of
support for fragmentable packets longer than a certain length.
>>> A4f. The IPv6 flow label or some other component(s) of the IPv6 header
>>> are used to contain the RLOC. The flow label is set before the packet
>>> enters the core. Non-local packets are routed based on the flow label.
>>> IPv4 is abandoned.
>>
>> This, your current A4f, doesn't describe Ivip's Prefix Label
>> Forwarding at all: http://www.firstpr.com.au/ip/ivip/ivip6/
>>
>> There is no concept of abandoning IPv4 in this.
>
> I'll replace "IPv4 is abandoned" with "Use a different A4 variant for IPv4."
OK - for IPv6 there is a broadly similar system, but with some
important distinctions.
>> The full RLOC can't fit in the IPv6 header, but 19 bits of it can,
>> which is sufficient to forward the packet across the DFZ.
>
> I don't follow the distinction. If what's in the header gets the
> packet to the ISP and then the ISP does something internally to move
> it to it's destination then that number in the header was the RLOC.
It is an RLOC only across the DFZ as far as the ISP's border router.
With the IPv4 approach:
http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw
the RLOC is the ETR address, so with upgraded internal routers, the
modified packet is forwarded as far into the ISP network as
necessary, without any further lookups, until it reaches the ETR.
A4f and A4g roughly describe my IPv6 and IPv4 forwarding approaches.
In A4f, the text:
"The flow label is set before the packet enters the core. Non-local
packets are routed based on the flow label."
is not quite right. A better description would be:
"Internal routers upstream of the RLOC encoder, and all DFZ
routers, forward the packet according to this new RLOC address to
an ISP border router which advertises the matching prefix. There,
the packet is either sent to a single RLOC decoder, or a second
lookup is performed so the ISP can use its own methods of
transporting the packet to the correct one of multiple RLOC
decoders."
In A4g, the text:
"Discard those components and set the RLOC when the packet enters
the core. Restore the original bits when the packet leaves the
core."
is not quite right. This would be better:
"Discard those components and set the RLOC when the packet is
forwarded from the RLOC encoder [ITR]. Restore the original bits
when the packet arrives at the RLOC decoder [ETR]. Upgraded
routers between RLOC encoder and decoder - DFZ and internal
routers - forward the packet according to the RLOC address
rather than the destination address."
>> A major characteristic of Strategy A your page doesn't mention is
>> that it can be introduced smoothly, without requiring changes in
>> hosts.
>
> A4a. A4b. Proposals based on e and f may call for deprecating IPv4.
OK - A4e (Six/One Router) involves abandoning IPv4, so this does
involve major host changes. Apart from that, the map-encap
approaches (LISP, APT, Ivip and TRRP) and the forwarding approaches
(Ivip) are for both IPv4 and IPv6 and involve no host changes. This
is a major distinction between Strategy A and Strategy B, which can
only be implemented with changing hosts to a modified form of IPv6,
with new host stacks, API and applications.
> Tell you what, if A4c and A4d are the only compatibility variants to
> survive the rejection phase, I'll add a note to the strategy A
> description to the effect that host changes are not required.
OK - but the nature of the host changes is my primary argument for
why Strategy B should be rejected. The difficulty of having such
changes developed and widely adopted is a secondary argument.
>> Ideally, I think, the document you are creating would contain:
>>
>> 1 - Fuller descriptions of the proposals, with the appropriate
>> terminology, ETR, ITR, QSD, PTR, OITRD etc.
>
> This terminology only applies to specific strategy-A proposals and
> only some of them. It does not apply, for example, to Six/One Router.
Yes - Six/One Router is the exception. I am not sure how much
Christian is working on it now. I understand your need to generalise
to cover all the approaches.
>> 2 - Clear labelling of which proposals match which descriptions.
>
> That's a job for another document.
I will write a message to do this.
>> 3 - Either a much more fully developed set of critiques,
>> appraisals etc. than you have at present - or none at all.
>>
>> The "Major Criticisms" of Strategy A do not apply to Ivip
>
> If correct, you're ahead of the game. You're still gonna have to sell it
> though.
Those major criticisms don't apply to Ivip. I am doing my best to
promote understanding of Ivip and to encourage critiques.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
