<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 21/Jun/20 14:58, Baldur Norddahl
      wrote:<br>
      <br>
    </div>
    <blockquote type="cite"
cite="mid:CAPkb-7AghNBeWOFK_MLEsxzR637QvGQ3WFceB2BjTTj9C7=U7Q@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Not really the same. Lets say the best path is through
            transit 1 but the customer thinks transit 1 sucks balls and
            wants his egress traffic to go through your transit 2. Only
            the VRF approach lets every BGP customer, even single homed
            ones, make his own choices about upstream traffic.</div>
          <div><br>
          </div>
          <div>You would be more like a transit broker than a
            traditional ISP with a routing mix. Your service is to buy
            one place, but get the exact same product as you would have
            if you bought from top X transits in your area. Delivered as
            X distinct BGP sessions to give you total freedom to send
            traffic via any of the transit providers.</div>
        </div>
      </div>
    </blockquote>
    <br>
    We received such requests years ago, and calculated the cost of
    complexity vs. BGP communities. In the end, if the customer wants to
    use a particular upstream on our side, we'd rather setup an EoMPLS
    circuit between them and they can have their own contract.<br>
    <br>
    Practically, 90% of our traffic is peering. We don't that much with
    upstreams providers.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAPkb-7AghNBeWOFK_MLEsxzR637QvGQ3WFceB2BjTTj9C7=U7Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>This is also the reason you do not actually need any
            routes in the FIB for each of those transit VRFs. Just a
            default route because all traffic will unconditionally go to
            said transit provider. The customer routes would still be
            there of course.</div>
        </div>
      </div>
    </blockquote>
    <br>
    Glad it works for you. We just found it too complex, not just for
    the problems it would solve, but also for the parity issues between
    VRF's and the global table.<br>
    <br>
    Mark.<br>
  </body>
</html>