The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Eric,

    There are a few things to say in response to this:

        o    This seems to be an artifact of an off-beat (and probably not
            well supported) use of RRs,
        o    This IS a BGP specific issue and
        o    I said there is no reason not to embed a VPN ID (which is 7
            bytes long) in an RD (which is 8) - I did not say they are
            interchangeable (though - with the exception of trying to
            support some strange corner cases - they could be).

As I understand it, the 'real' configuration is something like this (watch
me pull a rabbit out of my hat):

                                   A
                                  /
        R1---.              .---R3
       /      \            /      \
      |        \          /        |
      |         \        /         |
      |          \      /          |
       \     S1   |    |   S2     /
        \         |    |         /
         \        |    |        /
          \       |____|       /
           \     /      \     /
            `--R2        R4--'
           /                  \
          |        (RR1)       |
           \                  /
            `-_      H     _-'
               `---____---'


Presumably,  S1, S2 and H are Autonomous Systems, right?  In this case,
how do S1 and H share a route reflector with S2?  Also, it is important to
note that S1, S2 and H do not think about routes, R1 through R4 do.  In
the above case, R3 and R4 might share an RR, as might R2 and R4 and R1 and
R2.  But it seems a bad idea to have them all sharing the same RR.

Assume for a minute, however, that this configuration of ASs is all under
the same administrative domain and someone decides to use a single RR
(Can they even do this?  How would advertisements from R3 get refelected
to R1, for instance, without going through R4 and R2?).  Logically, this
RR would have to look like this:


                                   A
                                  /
        R1---.              .---R3
       /      \            /      \
      |        \          /        |
      |         \        /         |
      |          \      /          |
       \     S1   |    |   S2     /
        \RR1-a    |    |    RR1-c/
         \        |    |        /
          \       |____|       /
           \     /      \     /
            `--R2        R4--'
           /                  \
          |        RR1-b       |
           \                  /
            `-_      H     _-'
               `---____---'

The route reflector itself needs to be logically partitioned so that the same
RR (physical device) can reflect a route for A from R3 to R4, from R4 to R2
and from R2 to R1.  Having the RR reflect the route advertised by R3 directly
to R1 sure seems seriously broken.  It would not work in normal BGP, so why
would anyone expect it to work in BGP-VPNs?  The RR simply has to know
what sets of routers it can share advertisements among for each AS, or it
should not be shared across multiple ASs.

Practically, however, I can see that trying to support many ASs without using
a cheat like this might mean having to either have very many RRs, or put a lot
of smarts into each RR.  Let me guess, we don't sell smart RRs, do we? :-)

None of this has anything to do with the response I made to Jay, however.  The
fact that MPLS/BGP VPNs defines an address format suited to solving this
BGP specific problem has nothing to do with why another label distribution
approach might not be useful in support of VPNs based on something other than
BGP.

Nor does this problem seem to prevent anyone from embedding a VPN ID in their
RD until they get to the point where they need more than 255 distinct RDs for
a single VPN.  By that time, they may have other problems anyway...

--
Eric Gray

You wrote:

> In  the  "hub  and spoke"  case  that  Ajay  mentioned,  the intent  is  the
> following.
>
> Let H be the  hub, S1 and S2 the spokes.  Let A be  the address prefix for a
> subnet that attaches to S2.  What we want is:
>
> - S1 thinks the route to A is via H.
>
> - H thinks the route to A is via S2.
>
> Thus traffic from S1 to A goes via H and then on to S2.
>
> To make this work, S2 must distribute a route RD1:A, and H must distribute a
> route RD2:A.   Both these  routes have to  be able  to pass through  a route
> reflector, since  RD1:A must make  it to  H, and RD2:A  must make it  to S1.
> This  implies that  RD1  must be  different  than RD2;  otherwise the  route
> reflector could not pass on both routes.
>
> Given that S1,  S2, and H are in the  same VPN, this is a  case in which you
> couldn't just replace the RD with a VPN-id.  There might also be other cases
> in which  you want to pass around  two different routes to  the same address
> prefix, using  policy to decide which  to install where  (presumably in some
> manner that ensures loop-freedom).