nanog mailing list archives
RE: [c-nsp] LDPv6 Census Check
From: <adamv0025 () netconsultings com>
Date: Mon, 15 Jun 2020 10:24:20 +0100
David Sinn Sent: Friday, June 12, 2020 4:42 PMOn Jun 12, 2020, at 8:26 AM, Saku Ytti <saku () ytti fi> wrote: On Fri, 12 Jun 2020 at 18:16, David Sinn <dsinn () dsinn com> wrote:The label stack question is about the comparisons between the two extremes of SR that you can be in. You either label your packet just for
it's
ultimate destination or you apply the stack of the points you want to pass through. In the former case you are, at the forwarding plane, equal to what you see with traditional MPLS today, with every node along the path needing to know how to reach the end-point. Yes, you have lowered label space from traditional MPLS, but that can be done with site-cast labels already. And, while the nodes don't have to actually swap labels, when you look at commodity implementations (across the last three generations since you want to do this with what is deployed, not wholesale replace the network)
a
null swap still ends up eating a unique egress next-hop entry. So from a hardware perspective, you haven't improved anything. Your ECMP group count is high.
Yes this is where each node needs to have a label uniquely identifying every LSP passing through it. Saku, With IP header you don't need this, Consider this: PE1 to PE2 via 3 P-core nodes With ECMP in IP, then PE1 just needs single FEC the DST-IP of PE2, which will be load-shared across all 3 paths. Using MPLS If you need to uniquely identify each path you need 3 FECs (3 LSPs one via each P core node), now imagine you have 100K possible paths across the fabric -that's a lot of FECs on PE1 or any node in the fabric where each has to have a unique label for every possible unique path via the core that the particular node is part of.
In the extreme latter case, you have to, on ingress, place the full stack
of
every "site" you want to pass through. That has the benefits of "sites"
only
need labels for their directly connected sites, so you have optimized the implications on commodity hardware. However, you now have a label stack that can be quite tall. At least if you want to walk the long-way around
the
world, say due to failure. On top, that depth of label stack means devices
in
the middle can't look at the original payload to make ECMP decisions. So
you
can turn to entropy labels, but that sort of makes matters worse.
David, You can use hierarchy of tunnels to help with the deep label-stack imposition problem. adam
Current thread:
- Re: [c-nsp] LDPv6 Census Check, (continued)
- Re: [c-nsp] LDPv6 Census Check Nick Hilliard (Jun 11)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 11)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 11)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 12)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 12)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 12)
- Re: [c-nsp] LDPv6 Census Check Andrey Kostin (Jun 12)
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 12)
- Message not available
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 12)
- Re: [c-nsp] LDPv6 Census Check Mark Tinka (Jun 13)
- Message not available
- RE: [c-nsp] LDPv6 Census Check adamv0025 (Jun 15)
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 15)
- RE: [c-nsp] LDPv6 Census Check adamv0025 (Jun 15)
- Re: [c-nsp] LDPv6 Census Check Saku Ytti (Jun 15)
- RE: [c-nsp] LDPv6 Census Check adamv0025 (Jun 15)
- Re: [c-nsp] LDPv6 Census Check Mark Tinka (Jun 15)
- RE: [c-nsp] LDPv6 Census Check adamv0025 (Jun 16)
- Re: [c-nsp] LDPv6 Census Check Mark Tinka (Jun 16)
- RE: [c-nsp] LDPv6 Census Check adamv0025 (Jun 16)
- Re: [c-nsp] LDPv6 Census Check Mark Tinka (Jun 17)
- Re: [c-nsp] LDPv6 Census Check Mark Tinka (Jun 15)