On 6/8/13 4:17 AM, Owen DeLong wrote:
2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28). That's only
1.5M /48s, and they have about 10x that many customers. They likely can't use /48 plus
semantic prefixes, because if ARIN doesn't accept semantic prefixes as using
On Jun 6, 2013 8:58 PM, Owen DeLong o...@delong.com wrote:
While my statements in this forum are my opinion alone and not intended
to represent ARIN or the AC, I think I bring a pretty good knowledge of
both the letter and the intent of the policies as they exist today.
Thus, it should be easy
On Jun 6, 2013, at 10:40 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Like almost everything things in engineering, it's a cost/benefit tradeoff.
This discussion about not enough bits is simply attempting to quantify some
of the costs involved. I keep harping about it
On 6/6/13 10:09 AM, Lorenzo Colitti wrote:
On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon ted.le...@nominum.com
mailto:ted.le...@nominum.com wrote:
Saying it says nothing of the sort without even citing it is
not a very convincing argument. If you want to state convincingly
that it
By the way, ISPs are only one kind of network operators who are
interesting
in semantic prefix. Enterprise network operators are another group of
network operators who can benefit from embedded semantics. And the
enterprises do not have subscribers who potentially need extra bits.
Your use
2. Comcast only appears to have a /29 and a /28 (2001:558::/29, 2601::/28).
That's only 1.5M /48s, and they have about 10x that many customers. They
likely can't use /48 plus semantic prefixes, because if ARIN doesn't accept
semantic prefixes as using space efficiently (and word from ARIN
On 2013-06-07 19:17, Owen DeLong wrote:
2. Comcast only appears to have a /29 and a /28 (2001:558::/29,
2601::/28). That's only 1.5M /48s, and they have about 10x that
many customers. They likely can't use /48 plus semantic prefixes,
because if ARIN doesn't accept semantic prefixes as using
On Thu, Jun 6, 2013 at 6:10 PM, Niall O'Reilly niall.orei...@ucd.ie wrote:
On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:
indeed, the letter of the policy above suggests that a /48 is
acceptable only in the case of extra large end sites
How do you read that into the extract you
Yes, this discussion has become far way from my original motivation of
analysing semantic prefix mechanism. I am going to stop replying to the
discuss regarding to the avaibilities of bits. In the future version, I
will add the bits consumption as one of the pitfalls.
By the way, ISPs are only
Hi,
By the way, ISPs are only one kind of network operators who are interesting
in semantic prefix. Enterprise network operators are another group of network
operators who can benefit from embedded semantics. And the enterprises do not
have subscribers who potentially need extra bits.
Now
On Jun 5, 2013, at 11:26 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Thus, using semantic prefixes makes it much harder to assign /48s to users -
indeed, the letter of the policy above suggests that a /48 is acceptable only
in the case of extra large end sites, and
On Thu, Jun 6, 2013 at 8:25 PM, Ted Lemon ted.le...@nominum.com wrote:
You should reread the text. It says sites that need _more_ than a /48
are extra large end sites.
Yes, Niall pointed that out to me. But the argument is the same, see my
reply to him.
On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Personally, I'm waiting for us to agree that due to current RIR policies, if an
ISP chooses to use semantic prefixes, then it will not be able to give users as
much space as it would be able to give
Personally, I'm waiting for us to agree that due to current RIR policies, if
an ISP chooses to use semantic prefixes, then it will not be able to give
users as much space as it would be able to give them if it chose not to use
semantic prefixes.
You will have to wait until someone from
On Jun 6, 2013, at 7:48 AM, Lorenzo Colitti lore...@google.com wrote:
Sorry, but no. This is clearly spelled out in the policy which I quoted
earlier. Surely you're not saying that hearsay from an employee who happens
to work in the research group of an RIR is more authoritative than than the
On Thu, Jun 6, 2013 at 10:14 PM, Ted Lemon ted.le...@nominum.com wrote:
Sorry, but no. This is clearly spelled out in the policy which I quoted
earlier. Surely you're not saying that hearsay from an employee who happens
to work in the research group of an RIR is more authoritative than than
On Jun 6, 2013, at 9:35 AM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Saying it says nothing of the sort without even citing it is not a very
convincing argument. If you want to state convincingly that it says nothing of
the sort, then why not start from the text I
On Thu, Jun 6, 2013 at 10:56 PM, Ted Lemon ted.le...@nominum.com wrote:
Saying it says nothing of the sort without even citing it is not a
very convincing argument. If you want to state convincingly that it says
nothing of the sort, then why not start from the text I posted earlier and
On 6 Jun 2013, at 04:26, Lorenzo Colitti wrote:
indeed, the letter of the policy above suggests that a /48 is acceptable
only in the case of extra large end sites
How do you read that into the extract you cited, Lorenzo?
Niall O'Reilly
On Jun 6, 2013, at 10:09 AM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Start by saying how the statement I point to as justification does not, in
fact, mean what I say, and why it does not?
The text doesn't say that ARIN won't allocate bits for semantic prefixes. It
On Jun 6, 2013, at 03:39 , Sheng Jiang shengji...@gmail.com wrote:
Yes, this discussion has become far way from my original motivation of
analysing semantic prefix mechanism. I am going to stop replying to the
discuss regarding to the avaibilities of bits. In the future version, I will
On Jun 6, 2013, at 04:34 , Ted Lemon ted.le...@nominum.com wrote:
On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti lore...@google.com wrote:
Personally, I'm waiting for us to agree that due to current RIR policies, if
an ISP chooses to use semantic prefixes, then it will not be able to give
On Jun 6, 2013, at 2:57 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
If you claim you gave a customer a /48 and the customer reports that they are
not allowed to exercise control over the use of that /48, then, you have not,
in fact, delegated authority over that /48 as you have
On Fri, Jun 7, 2013 at 10:26 AM, Ted Lemon ted.le...@nominum.com wrote:
If you claim you gave a customer a /48 and the customer reports that
they are not allowed to exercise control over the use of that /48, then,
you have not, in fact, delegated authority over that /48 as you have
claimed
On May 30, 2013, at 11:28 PM, Sheng Jiang jiangsh...@huawei.com wrote:
Agree. The network providers should know they cannot get more addresses
because they use their block for semantic, which lead to lower address
utility rate.
Will make this clear in the new section potential pitfalls.
On Jun 6, 2013, at 9:38 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
What about the APNIC policy I cited a few emails ago? You have not explained
why you think it supports your point of view that using semantic bits does not
make it harder for ISPs to assign /48s to
On Fri, Jun 7, 2013 at 10:54 AM, Ted Lemon ted.le...@nominum.com wrote:
What about the APNIC policy I cited a few emails ago? You have not
explained why you think it supports your point of view that using semantic
bits does not make it harder for ISPs to assign /48s to users.
The policy
Yes, this discussion has become far way from my original motivation of
analysing semantic prefix mechanism. I am going to stop replying to the
discuss regarding to the avaibilities of bits. In the future version, I will
add the
bits consumption as one of the pitfalls.
By the way, ISPs are only
Agree. The network providers should know they cannot get more addresses
because they use their block for semantic, which lead to lower address utility
rate.
Will make this clear in the new section potential pitfalls.
Sheng -
It would be very helpful to put that clarifying point into the
On Jun 6, 2013, at 11:44 PM, Sheng Jiang jiangsh...@huawei.com wrote:
Hi, John,
Thanks for your message. Yes, I will add lower address utility rate as one of
the major pitfalls. However, I don't want to make an absolute statement of
cannot. As a neutral analysis, it is better to just make
Hi,
On Wed, Jun 05, 2013 at 07:55:25AM +0800, Sheng Jiang wrote:
As far as I know, most of Tier1 providers gets /24, /26 or bigger.
No :-)
As this has nothing to do with the Tier1-ness, but with the number of
customers that the provider will provide /48s to.
So if a Tier1 is only connecting
i don't believe that I said support.
but when you select cases as representative, you are biasing the result.
people place all sorts of semantic clues in the methods of addressing… more so
when the addresses themselves are too large to be memnonic.
I happen to believe that the idea of
Hi Ted,
Op 5 jun. 2013, om 04:46 heeft Ted Lemon ted.le...@nominum.com het volgende
geschreven:
Be that as it may, ISPs all seem to be deploying networks with /56's to the
home, not /48's.
Not in my part of the world (Netherlands). They all give at least a /56. These
I know:
- XS4ALL: /48
On Jun 4, 2013, at 11:42 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
I still don't understand. What the above sentences seem to be saying is that
there are bits available for semantic prefix assignment because RIRs assume
/48 but users don't actually get /48. Is that
than
locator?//draft-jiang-v6ops-semantic-prefix-03
Resent-To: boyang...@huawei.commailto:boyang...@huawei.com, Ian Farrer
ian.far...@telekom.demailto:ian.far...@telekom.de,
jiangsh...@huawei.commailto:jiangsh...@huawei.com,
sunqi...@ctbri.com.cnmailto:sunqi...@ctbri.com.cn
On Wed, Jun 5, 2013
On Jun 5, 2013, at 10:23 AM, Sander Steffann san...@steffann.nl wrote:
So they playing field is mixed. Some do /56, but the major players do (or
will do) /48.
Sure, but you're just confirming my point that if a provider wants to do
semantic prefixes, they can get enough bits to do them by
] Could IPv6 address be more than
locator?//draft-jiang-v6ops-
semantic-prefix-03
On Jun 5, 2013, at 10:23 AM, Sander Steffann san...@steffann.nl wrote:
So they playing field is mixed. Some do /56, but the major players do (or
will do) /48.
Sure, but you're just confirming my point
Hi Ted,
On Jun 5, 2013, at 10:23 AM, Sander Steffann san...@steffann.nl wrote:
So they playing field is mixed. Some do /56, but the major players do (or
will do) /48.
Sure, but you're just confirming my point that if a provider wants to do
semantic prefixes, they can get enough bits to
On Jun 5, 2013, at 12:04 PM, Sander Steffann san...@steffann.nl wrote:
Keep in mind that RIRs won't give you extra address space though. If you
assign /56s to your users then that is what the RIR need-base calculations
are based on (according to current policy).
So if the ISP says we need a
-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ted
Lemon
Sent: Wednesday, June 05, 2013 12:12 PM
To: Sander Steffann
Cc: v6...@ietf.org WG; draft-jiang-v6ops-semantic-pre...@tools.ietf.org;
ipv6@ietf.org 6man-wg
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft
On Jun 5, 2013, at 3:28 PM, Manfredi, Albert E albert.e.manfr...@boeing.com
wrote:
Actually, I was about to make that suggestion myself. We can stop this
infinite thread by simply saying, do whatever semantic tricks you want with
the address blocks allocated to you, but know that you won't
@ietf.org,
draft-jiang-v6ops-semantic-pre...@tools.ietf.org
draft-jiang-v6ops-semantic-pre...@tools.ietf.org, Ralph Droms
rdroms.i...@gmail.com
Subject: Re: [v6ops] Could IPv6 address be more than
locator?//draft-jiang-v6ops-semantic-prefix-03
Resent-To: boyang...@huawei.com, Ian Farrer
On Jun 5, 2013, at 09:11 , Ted Lemon ted.le...@nominum.com wrote:
On Jun 5, 2013, at 12:04 PM, Sander Steffann san...@steffann.nl wrote:
Keep in mind that RIRs won't give you extra address space though. If you
assign /56s to your users then that is what the RIR need-base calculations
are
On Jun 5, 2013, at 15:55 , Ted Lemon ted.le...@nominum.com wrote:
On Jun 5, 2013, at 6:27 PM, Owen DeLong o...@delong.com wrote:
Also note that if you give residential customers /56s, you will need to be
able to justify /48s for businesses in terms of the number of /56s they need
at each
On Wed, Jun 5, 2013 at 11:54 PM, Ted Lemon ted.le...@nominum.com wrote:
I still don't understand. What the above sentences seem to be saying is
that there are bits available for semantic prefix assignment because RIRs
assume /48 but users don't actually get /48. Is that your point?
No.
On Thu, Jun 6, 2013 at 1:11 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 5, 2013, at 12:04 PM, Sander Steffann san...@steffann.nl wrote:
Keep in mind that RIRs won't give you extra address space though. If you
assign /56s to your users then that is what the RIR need-base calculations
On Jun 5, 2013, at 6:27 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
Also note that if you give residential customers /56s, you will need to be able
to justify /48s for businesses in terms of the number of /56s they need at each
end site in order to qualify for an additional
Mark Smith wrote:
- Original Message -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: manning bill bmann...@isi.edu
Cc: ipv6@ietf.org; v6...@ietf.org WG v6...@ietf.org
Sent: Tuesday, 4 June 2013 6:27 AM
Subject: Re: [v6ops] Could IPv6 address be more than
locator
Message-
From: joel jaeggli [mailto:joe...@bogus.com]
Sent: Tuesday, June 04, 2013 6:27 AM
To: Ivan Pepelnjak
Cc: Andrew McGregor; Brian E Carpenter; v6...@ietf.org WG; ipv6@ietf.org;
manning bill
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-
jiang-v6ops-semantic-prefix
i've heard that too. hardware designers going for the 80% solution. However
/64 is -NOT- part of the IPv6 spec.
the hardware is supposed to support bit masking across the range.
/bill
On 3June2013Monday, at 13:27, Brian E Carpenter wrote:
On 04/06/2013 03:44, manning bill wrote:
On
are you intending to document -all- variants of the semantics address holder
may use to address and organize their assigned numbers?
or are you intending to document a preferred version of address semantics?
/bill
On 4June2013Tuesday, at 6:24, Sheng Jiang wrote:
Hi, George,
Yes, network
I believe this is fraught with danger.
It perhaps better to identify semantic constructs than to presuppose
representative cases.
things like even/odd for in/out-bound links,
lat/log encoding or other geo-location
etc.
as a survey of technique.
/bill
On 4June2013Tuesday, at 7:32, Sheng
I don't rule out anything. I state that the bits should be there so that
automated topologies can be made to function in an arbitrary plug-and-play
environment.
If it can be used for other purposes, that's fine, but I do not suggest that we
should support those other purposes officially.
bill
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-
jiang-v6ops-semantic-prefix-03
On 6/3/13 7:11 PM, Ivan Pepelnjak wrote:
Read the recent p2p /64 thread of ipv6-ops cluenet mailing list
You are refering to:
http://lists.cluenet.de/pipermail/ipv6-ops/2013-June
I do understand your hierarical allocation is only topology. But do you
think that's the only way subscriber, who has 16 bits, may organize their
subnets. How could you rule out all other posibilities by suggesting you
have one of the good ways to do things?
Cheers,
Sheng
On 4 June 2013 11:53,
Hi, George,
Yes, network operators have the freedom to plan the address in their prefer
ways. There are many different ways to organize address schemas. Different
network operators (including both ISPs and enterprises) has various
considerations. Some consideration may be important for one
For sure, we cannot document all variants, but we can document the most
representative ones. My current plan is three categeries: ISP's,
enterprise's and subscribe's. Each categery has one example (in
appendexes), I guess.
Cheers,
Sheng
On 4 June 2013 21:51, manning bill bmann...@isi.edu
On Jun 4, 2013, at 11:12 AM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
I don't rule out anything. I state that the bits should be there so that
automated topologies can be made to function in an arbitrary plug-and-play
environment.
If it can be used for other purposes, that's
Hi,
On Tue, Jun 04, 2013 at 09:29:52AM +0800, Sheng Jiang wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
Where are these
From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Tuesday, June 04, 2013 3:45 AM
To: Vízdal Aleš
Cc: Joel M. Halpern; Sheng Jiang; v6...@ietf.org;
draft-jiang-v6ops-semantic-pre...@tools.ietf.org; ipv6@ietf.org
Subject: Re: [v6ops] Could IPv6 address be more than
locator?//draft-jiang
We do NOT support anything. This would be an analysis document. The
motivation is to document existing typical semantic IP address mechanisms
and analyze them, both good and bad side. I will make this very clear in
the new version.
Sheng
On 4 June 2013 22:44, manning bill bmann...@isi.edu
As far as I know, most of Tier1 providers gets /24, /26 or bigger.
For RIR's policy, please see recent email from George Michaelson. Although
he did not speak in any formal, he explained RIR policy is much flexiable
than most of us thought.
On Wed, Jun 5, 2013 at 2:05 AM, Ted Lemon ted.le...@nominum.com wrote:
So even though we have solutions to allocate prefixes efficiently in
arbitrary home network topologies
We don't have solutions. We only have ideas on how solutions might be
built, and it must be noted that those ideas
On Jun 4, 2013, at 10:14 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
Addressing policy cannot be shaped on what the IETF thinks might happen in the
best case. It must be done taking into account real world constraints. If
efficiently-addressed, routed home networks
On Wed, Jun 5, 2013 at 11:46 AM, Ted Lemon ted.le...@nominum.com wrote:
Be that as it may, ISPs all seem to be deploying networks with /56's to
the home, not /48's. Edge-rooted PD is an ops doc—no new protocol work is
required.
So then your argument should be RIRs should not plan to
On Jun 4, 2013, at 10:53 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
So then your argument should be RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /56s to subscribers anyway?
No, it shouldn't. My argument is that the belief that no
Hi,
I see some issues when using non-topological address hierarchies:
1. For example, if you use addresses
ISPlocationuser classuser#subnet
then you can have one route entry to route all traffic to a location, i.e.
ISPlocation
But, it is harder to send traffic of one user class over
On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon ted.le...@nominum.com wrote:
So then your argument should be RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /56s to subscribers anyway?
No, it shouldn't. My argument is that the belief that no bits are
available
On Jun 4, 2013, at 11:11 PM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon
ted.le...@nominum.commailto:ted.le...@nominum.com wrote:
So then your argument should be RIRs should not plan to assign /48s to
subscribers because ISPs
On Wed, Jun 5, 2013 at 12:20 PM, Ted Lemon ted.le...@nominum.com wrote:
So the point isn't that a /48 is a waste of space. It's that a /48 is
assumed, and because it is assumed, there are definitely bits available for
semantic prefix assignment.
I still don't understand. What the above
You're looking at the internet of today.
Think about 10, 15, 20 years out when everything you buy at the grocery store
has an IP address and most audio amplifiers act as routers to head-end the
other entertainment devices in the cluster.
Think about a time when HDMI is supplanted by
On Jun 2, 2013, at 11:21 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
Yes. A fine engineering solution for demonstration purposes, but not a good
solution for us to recommend for deployment in the long term. Because it
commits wide prefixes to sub-delegations, it wastes
On Jun 2, 2013, at 11:24 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
No, there is no use case where this is better than doing the delegations from
the router that received the initial delegation (since we're apparently just
arguing by vigorous assertion).
Is your opinion. I
On Jun 2, 2013, at 11:26 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
My point is that it should be up to the person running the home net (or other
end site) to decide what is better for their site and that we should not be
making the choice for them.
So, to recap, RIR policies
On Jun 3, 2013, at 7:27 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 2, 2013, at 11:21 PM, Owen DeLong o...@delong.com wrote:
Yes. A fine engineering solution for demonstration purposes, but not a
good solution for us to recommend for deployment in the long term.
Because it
On Jun 3, 2013, at 7:32 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 2, 2013, at 11:24 PM, Owen DeLong o...@delong.com wrote:
No, there is no use case where this is better than doing the delegations
from the router that received the initial delegation (since we're
apparently just
If I am reading this correctly, in the end this is riven by the fact
that existing boxes can easily filter on addresses (although it will
take a lot of filters), but can not apply ACLs to DSCPs or extension
headers?
It seems like what we need is a draft that clearly explains why trying
to
Hi,
On 31.05.2013 11:46, Ray Hunter wrote:
But why are people coming up with these schemes for encoding semantics
in the address prefixes in the first place? That's what I'd like to
understand first and foremost: what lack of functionality is
motivating/forcing these people to adopt such
On Jun 3, 2013, at 9:46 AM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
I believe that making bits available for greater flexibility in consumer
networking is a good use of bits.
I believe that stealing bits from the consumer for purposes of allowing the
provider to overload the
On Jun 3, 2013, at 9:22 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 3, 2013, at 9:46 AM, Owen DeLong o...@delong.com wrote:
I believe that making bits available for greater flexibility in consumer
networking is a good use of bits.
I believe that stealing bits from the consumer for
address be more than
locator?//draft-jiang-v6ops-
semantic-prefix-03
If I am reading this correctly, in the end this is riven by the fact that
existing boxes
can easily filter on addresses (although it will take a lot of filters), but
can not apply
ACLs to DSCPs or extension headers
Hi, Shane,
Actually, we do assume the SP deploys unicast filters to drop incoming
packets with illegitimate source IP address/prefix. After then, the packets
become trusted.
It is the filter who makes sure the prefix right. The filter should link
back to other states of the user, like user
I have to say the hierarchical assignment is a such great way to waste
address space or prefix bit. I cannot real see much benefits or use cases
of it. Why may home site 3 subordinate routers? How many subnets or devices
may a /48 prefix serve in this model?
Cheers,
Sheng
On 3 June 2013 00:39,
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is actually
using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going to inject a route. One route. why do
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going to inject a route. One route. why do
On 3June2013Monday, at 8:51, Sander Steffann wrote:
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
manning bill
Pragmatically, much of the IPv6 protocol/application development has
ignored half the 128bit space and treats IPv6 as a 64bit address platform.
Exactly.
It's time to
On 04/06/2013 03:44, manning bill wrote:
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going
- Original Message -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: manning bill bmann...@isi.edu
Cc: ipv6@ietf.org; v6...@ietf.org WG v6...@ietf.org
Sent: Tuesday, 4 June 2013 6:27 AM
Subject: Re: [v6ops] Could IPv6 address be more than
locator?//draft-jiang
That's completely true; many switch chips cannot route on longer than /64
prefixes, so attempting to do so starts to either heat up the software slow
path, or consume ACL entries, or is simply not supported at all. While
this is arguably a bug, it is also pretty much ubiquitous in the current
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than
/64 prefixes, so attempting to do so starts to either heat up the
software slow path, or consume ACL entries, or is simply not supported
at all. While this is arguably a bug, it is
Ok maybe I'm overstating it a bit... but there are a lot of those chips out
there, and they are painful.
On Tue, Jun 4, 2013 at 9:08 AM, joel jaeggli joe...@bogus.com wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than /64
This looks a typical double standard for me. You are willing to allow
homenet (the network operator in this case is subscribers) to play semantic
in their networks with the bits from 48 to 63, while you disallow ISPs to
set the semantic bits in their networks with the bits from 20 to 48 or 56.
You
Exactly. I agree we should not block the possibility for the future.
However, I don't agree we should block the current requirements to make the
way for the uncertainties of future. We should first serve the needs today,
then we the better current network will become a better fundamental for our
Hi, Roland,
Thanks for your comments. Yes, the authors will restructure this draft -
making it more an analysis draft rather than a proposal. The pitfalls will
be an very important part for a neutral analysis.
Cheers,
Sheng
On 3 June 2013 22:09, Bless, Roland (TM) roland.bl...@kit.edu wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
For me, the consumer flexibility looks more uncertain although I don't have
much
On Mon, Jun 3, 2013 at 11:59 PM, Vízdal Aleš ales.viz...@t-mobile.czwrote:
If I am reading this correctly, in the end this is riven by the fact
that existing boxes
can easily filter on addresses (although it will take a lot of filters),
but can not apply
ACLs to DSCPs or extension
On Tue, Jun 4, 2013 at 10:29 AM, Sheng Jiang shengji...@gmail.com wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
The
Read the recent p2p /64 thread of ipv6-ops cluenet mailing list
=
Mistyped and autocorrected on a clunky virtual keyboard
On 4. jun. 2013, at 01:08, joel jaeggli joe...@bogus.com wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on
Just to remind people, RIR policy is community driven. If the operations
people feel they need a policy for IPv6 allocations and assignments which
takes accounts of semantic bits, they can derive consensus driven policies
to do it. Its not done in the IETF. There might be an issue with how it
1 - 100 of 171 matches
Mail list logo
