<div dir="ltr"><div dir="ltr">Let's clarify a few things ...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020 at 2:39 PM Masataka Ohta <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If all the link-wise (or, worse, host-wise) information of possible<br>
destinations is distributed in advance to all the possible sources,<br>
it is not hierarchical but flat (host) routing, which scales poorly.<br>
<br>
Right?<br></blockquote><div><br></div><div>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. </div><div><br></div><div>So all you are exchanging as part of VPN overlay is three subnets. </div><div><br></div><div>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)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is because detailed information to reach destinations<br>
below certain level is advertised not globally but only for<br>
small part of the network around the destinations.<br></blockquote><div><br></div><div>Same thing here. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That is, with hierarchical routing, detailed information<br>
around destinations is actively hidden from sources.<br></blockquote><div><br></div><div>  Same thing here.  </div><div><br></div><div>That is why as described we use label stack. Top label is responsible to get you to the egress PE. Service label sitting behind top label is responsible to get you  through to the customer site (with or without IP lookup at egress PE).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, with hierarchical routing, routing protocols can<br>
carry only rough information around destinations, from<br>
which, source side can not construct detailed (often<br>
purposelessly nested) labels required for MPLS.<br></blockquote><div><br></div><div>Usually sources have no idea of MPLS. MPLS to the host never took off. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
According to your theory to ignore routing traffic, we can be happy<br>
with global *host* routing table with 4G entries for IPv4 and a lot<br>
lot lot more than that for IPv6. CIDR should be unnecessary<br>
complication to the Internet<br></blockquote><div><br></div><div>I do not think any one saying it here. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">With nested labels, you don't need so much labels at certain nesting<br>
level, which was the point of Yakov, which does not mean you don't<br>
need so much information to create entire nested labels at or near<br>
the sources.<br></blockquote><div><br></div><div>Label stack is here from day one. Each layer of the stack has a completely different role. That is your hierarchy. </div><div><br></div><div>Kind regards,<br>R.</div><div><br></div><div><br></div><div> </div></div></div>