Owen DeLong wrote:
Saying /16 is ambiguous depends on IP version.
Not really… A /16 in IPv6 is a lot more addresses, but its still
using the first 16 bits to specify the prefix, same as IPv4.
As I wrote:
: But, it should be noted that a single class B routing table entry
: often serves for
> On Jun 23, 2020, at 4:16 AM, Masataka Ohta
> wrote:
>
> Mark Tinka wrote:
>
>>> But, it should be noted that a single class B...
>> CIDR - let's not teach the kids old news :-).
>
> Saying /16 is ambiguous depends on IP version.
Not really… A /16 in IPv6 is a lot more addresses, but
On Mon, Jun 22, 2020 at 7:18 PM Randy Bush wrote:
> how did that work out for the ptts? :)
>
Though its release slipped by three years, by 1995 ATM had started to
replace IP as the protocol of choice. By 1999, IP was used only by a small
number of academic networks.
Nah, I don't think there
adamv0...@netconsultings.com wrote:
The key takeaway however is that no single entity in SP network, be it PE,
or RR, or ASBR, ever needs everything, you can always slice and dice
indefinitely.
So to sum it up you simply can not run into any scaling ceiling with MP-BGP
architecture.
Masataka Ohta wrote:
The point of Yakov on day one was that, flow driven approach of
Ipsilon does not scale and is unacceptable.
Though I agree with Yakov here, we must also eliminate all the
flow driven approaches by MPLS or whatever.
I still don't see them in practice, even though they may
Mark Tinka wrote:
Personally, the level of intelligence we have in routers now beyond
being just Layer 1, 2, 3 - and maybe 4 - crunching machines is just as
far as I'm willing to go.
Once upon a time in Japan, NTT proudly announced to have
developed and actually deployed telephone exchangers
Mark Tinka wrote:
But, it should be noted that a single class B...
CIDR - let's not teach the kids old news :-).
Saying /16 is ambiguous depends on IP version.
And, if I understand BGP-MP correctly, all the routing information of
all the customers is flooded by BGP-MP in the ISP.
Yes,
>> The requirement from the E2E principle is that routers should be
>> dumb and hosts should be clever or the entire system do not.
>> scale reliably.
>
> And yet in the PTT world, it was the other way around. Clever switching
> and dumb telephone boxes.
how did that work out for the ptts? :)
On 22/Jun/20 16:30, adamv0...@netconsultings.com wrote:
> Not quite,
> The routing information is flooded by default, but the receivers will cherry
> pick what they need and drop the rest.
> And even if the default flooding of all and dropping most is a concern -it
> can be addressed where
> Masataka Ohta
> Sent: Monday, June 22, 2020 1:49 PM
>
> Robert Raszuk wrote:
>
> > Moreover if you have 1000 PEs and those three sites are attached only
> > to 6 of them - only those 6 PEs will need to learn those routes (Hint:
> > RTC -
> > RFC4684)
>
> If you have 1000 PEs, you should be
Masataka Ohta wrote on 22/06/2020 13:49:
But, it should be noted that a single class B routing table entry
"a single class B routing table entry"? Did 1993 just call and ask for
its addressing back? :-)
But, it should be noted that a single class B routing table entry
often serves for an
On 22/Jun/20 15:17, Masataka Ohta wrote:
>
>
> The point of Yakov on day one was that, flow driven approach of
> Ipsilon does not scale and is unacceptable.
>
> Though I agree with Yakov here, we must also eliminate all the
> flow driven approaches by MPLS or whatever.
I still don't see
On 22/Jun/20 15:08, Masataka Ohta wrote:
>
> The requirement from the E2E principle is that routers should be
> dumb and hosts should be clever or the entire system do not.
> scale reliably.
And yet in the PTT world, it was the other way around. Clever switching
and dumb telephone boxes.
> From: Masataka Ohta
> Sent: Monday, June 22, 2020 2:17 PM
>
> adamv0...@netconsultings.com wrote:
>
> > But MPLS can be made flow driven (it can be made whatever the policy
> > dictates), for instance DSCP driven.
>
> The point of Yakov on day one was that, flow driven approach of Ipsilon
On 22/Jun/20 14:49, Masataka Ohta wrote:
>
> But, it should be noted that a single class B...
CIDR - let's not teach the kids old news :-).
> If you have 1000 PEs, you should be serving for somewhere around 1000
> customers.
It's not linear.
We probably have 1 edge router serving
adamv0...@netconsultings.com wrote:
But MPLS can be made flow driven (it can be made whatever the policy
dictates), for instance DSCP driven…
The point of Yakov on day one was that, flow driven approach of
Ipsilon does not scale and is unacceptable.
Though I agree with Yakov here, we must
Mark Tinka wrote:
So, with hierarchical routing, routing protocols can
carry only rough information around destinations, from
which, source side can not construct detailed (often
purposelessly nested) labels required for MPLS.
But hosts often point default to a clever router.
The requirement
Robert Raszuk wrote:
Neither link wise nor host wise information is required to accomplish say
L3VPN services. Imagine you have three sites which would like to
interconnect each with 1000s of users.
For a single customer of an ISP with 1000s of end users. OK.
But, it should be noted that a
> Masataka Ohta
> Sent: Sunday, June 21, 2020 1:37 PM
>
> > Whether you do it manually or use a label distribution protocol, FEC's
> > are pre-computed ahead of time.
> >
> > What am I missing?
>
> If all the link-wise (or, worse, host-wise) information of possible
destinations
> is distributed
in this handbasket? (was Devil's Advocate - Segment
Routing, Why?)
The problem of MPLS, however, is that, it must also be flow driven,
because detailed route information at the destination is necessary
to prepare nested labels at the source, which costs a lot and should
be attempted only for detected
On 21/Jun/20 14:36, Masataka Ohta wrote:
>
>
> That is a tragedy.
Well...
> If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat (host) routing, which scales poorly.
>
>
Let's clarify a few things ...
On Sun, Jun 21, 2020 at 2:39 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
If all the link-wise (or, worse, host-wise) information of possible
> destinations is distributed in advance to all the possible sources,
> it is not hierarchical but flat
It is destination based flat routing distributed 100% before any data
packet within each layer - yes. But layers are decoupled so in a sense this
is what defines a hierarchy overall.
So transport is using MPLS LSPs most often hosts IGP routes are matched
with LDP FECs and flooded everywhere in
Mark Tinka wrote:
If information to create labels at or near sources to all the
possible destinations is distributed in advance, may be.
But this is what happens today.
That is a tragedy.
Whether you do it manually or use a label distribution protocol, FEC's
are pre-computed ahead of
On 21/Jun/20 13:11, Masataka Ohta wrote:
>
> If information to create labels at or near sources to all the
> possible destinations is distributed in advance, may be.
But this is what happens today.
Whether you do it manually or use a label distribution protocol, FEC's
are pre-computed ahead
Robert Raszuk wrote:
MPLS LDP or L3VPNs was NEVER flow driven.
Since day one till today it was and still is purely destination based.
If information to create labels at or near sources to all the
possible destinations is distributed in advance, may be. But
it is effectively flat routing, or,
On 20/Jun/20 17:12, Robert Raszuk wrote:
>
> MPLS is not flow driven. I sent some mail about it but perhaps it
> bounced.
>
> MPLS LDP or L3VPNs was NEVER flow driven.
>
> Since day one till today it was and still is purely destination based.
>
> Transport is using LSP to egress PE (dst IP).
On 20/Jun/20 17:08, Robert Raszuk wrote:
>
>
> But with that let's not forget that aggregation here is still not
> spec-ed out well and to the best of my knowledge it is also not
> shipping yet. I recently proposed an idea how to aggregate SRGBs ..
> one vendor is analyzing it.
Hence why I
On 20/Jun/20 15:39, Masataka Ohta wrote:
> Ipsilon was hopeless because, as Yakov correctly pointed out, flow
> driven approach to automatically detect flows does not scale.
>
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the
On 20/Jun/20 01:32, Randy Bush wrote:
> there is saku's point of distributing labels in IGP TLVs/LSAs. i
> suspect he is correct, but good luck getting that anywhere in the
> internet vendor task force. and that tells us a lot about whether we
> can actually effect useful simplification and
> The problem of MPLS, however, is that, it must also be flow driven,
> because detailed route information at the destination is necessary
> to prepare nested labels at the source, which costs a lot and should
> be attempted only for detected flows.
>
MPLS is not flow driven. I sent some mail
> there is saku's point of distributing labels in IGP TLVs/LSAs. i
> suspect he is correct, but good luck getting that anywhere in the
> internet vendor task force.
Perhaps I will surprise a few but this is not only already in RFC formats -
it is also shipping already across vendors for some
Randy Bush wrote:
MPLS was since day one proposed as enabler for services originally
L3VPNs and RSVP-TE.
MPLS day one was mike o'dell wanting to move his city/city traffic
matrix from ATM to tag switching and open cascade's hold on tags.
And IIRC, Tag switching day one was Cisco overreacting
33 matches
Mail list logo
