Mailing List Archive

On 22/Jun/20 16:30, adamv0025@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 only the relevant subset of all the routing info is
> sent to each receiver.
> 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.

The only nodes in our network that have ALL the NLRI is our RR's.

Depending on the function of the egress/ingress router, the RR sends it
only what it needs for its function.

This is how we get away using communities in lieu of VRF's :-).

And as Adam points out, those RR's will swallow anything and everything,
and still remain asleep.

Mark.

>> 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 Mon, Jun 22, 2020 at 7:18 PM Randy Bush <randy@psg.com> 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 is anywhere in the multiverse where fat pipes and
dumb switches doesn't win.



--
Fletcher Kittredge
GWI
207-602-1134
www.gwi.net

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, best practice is in iBGP.
>
> Some operators may still be using an IGP for this. It would work, but
> scales poorly.

The amount of flooded traffic is not so different.

>> Then, it should be a lot better to let customer edges encapsulate
>> L2 or L3 over IP, with which, routing information within customers
>> is exchanged by customer provided VPN without requiring extra
>> overhead of maintaining customer local routing information by the
>> ISP.
>
> You mean like IP-in-IP or GRE? That already happens today, without any
> intervention from the ISP.

I know, though I didn't know ISP's are not offering SLA for it.

> There are few ISP's who would be able to terminate an IP or GRE tunnel
> on-net, end-to-end.
>
> And even then, they might be reluctant to offer any SLA's because those
> tunnels are built on the CPE, typically outside of their control.

The condition to offer SLA beyond a network of an ISP should not
"trusted NNI" but policing by the ISP with ISP's own equipment,
which prevent too much traffic enter the network.

> If ISP's didn't make money from MPLS/VPN's, router vendors would not be
> as keen on adding the capability in their boxes.

It is like telco was making money by expensive telephone exchangers
only to be replaced by ISPs, I'm afraid.

> Label stacking is fundamental to the "MP" part of MPLS. Whether your
> payload is IP, ATM, Ethernet, Frame Relay, PPP, HDLC, e.t.c., the
> ability to stack labels is what makes an MPLS network payload agnostic.
> There is value in that.

What? You are saying "payload" not something carrying "payload"
is MP.

Then, plain Ethernet is MP with EtherType, isn't it?

Masataka Ohta

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 to be
able to offer complex calculator service including
trigonometric/exponential/logarithmic functions, which was
impossible by handheld calculators at that time.

My favorite example when I explain the E2E principle.

Masataka Ohta

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 have been proposed.

I don't know, either, as it's Adam who said:

> But MPLS can be made flow driven (it can be made whatever the
> policy dictates), for instance DSCP driven$B!D(B

Masataka Ohta

adamv0025@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.

Flooding nature of BGP requires all the related entities treat
everything, regardless of whether they need it entirely or not.

Masataka Ohta

> On Jun 23, 2020, at 4:16 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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 it’s still using the first 16 bits to specify the prefix, same as IPv4.

Owen

Owen DeLong wrote:

>> Saying /16 is ambiguous depends on IP version.
>
> Not really$B!D(B 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 an organization with 10000s of users, which is
: at least our case here at titech.ac.jp.

the number of remaining bits save the first 16 matters, which depends
on IP version.

Masataka Ohta