Subject: Re: Questions on multiprovider VPN operations in RFC2547bis

From: [email-masked]
Date: Wed, 3 Jan 2001 12:07:03 +0000

James and Yakov,

According to my understanding, RFC2547bis specifies a RD structure which is globally unique to allow for uncoordinated administration of this resource amongst service providers. Therefore surely the simple answer is: "No. There is no need to change the RD
at the boundary indeed such an uneccesary VPN-IP4 address translation should be deprecated." Administratively the service provider receiving the request to add a site will determine the RD to be used and should be able to expect other participating SPs to
work with that. What is more difficult to understand is Yakov's reply "...However, P1 *may* do the
conversion.....". Under what circumstances is it envisaged that a conversion may be required?

I suppose a SP is free to operate his service in a way which does not conform with global addressing conventions with regard to RDs and in this case the nonconforming SP would have to assume the burden of VPN-IP4 address translation. Do you have any more
realistic scenarios in mind? To complete the simple story however there should be some explicit support for advertising RDs between the EBGP-talking route reflectors (if indeed this does not exist already). I suppose that, except for taking the precaution
of defining an RD structure which can support global uniqueness while remaining free of implied semantics (itself something of a contradiction) the wider issues surrounding interconnection at MPLS boundaries are all out of scope for the moment and "for
further study".

The question does lead on to some more fundamental issues which arise at MPLS administrative domain boundaries. In addition to reachability advertisements there is the probable need for some sort of Bandwidth Broker or policy manager to deal with extending
SLAs accross the boundary. This may force an architecture that requires LSPs to terminate at the bounday to be reinitiated in the connected domain just so that IP layer header information may be re-examined to support policing etc. potentially frustrating
much of the MPLS scalability gains at core gateways. Alternatively it will be necessary to elaborate on SLAs based on (or easily mappable to) LSPs carrying aggregated (eg similar service level) flows implying per LSP OAM flows. Irrespective of such service
level issues, basic problem resolution in a multi-provider service environment will likely demand per LSP OAM flows which can be observed and acted upon at such boundaries.

Regards,

Mike Sexton

[email-masked] on 02/01/2001 20:12:46

 To:      [email-masked]                                         
                                                              
 cc:      (bcc: Michael J SEXTON/GB/ALCATEL)                  

 Subject: Questions on multiprovider VPN operations in        
          RFC2547bis                                          

Hello,
     RFC2547bis supports multiprovider VPNs in which a VPN customer has two
sites each served by a distinct VPN service provider.  The VPN service providers
serving the customer are themselves served by yet another VPN service provider.
Suppose we have the following VPN deployment,

     CE1  ---  (PE11  --  P1  -- PE12)  ==  (PE21 --  P2  -- PE22)  ==  (PE31
--  P3  -- PE32)  --  CE2

PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, and
PE32 are in AS3.
Assuming that  P1 and P3 are route reflectors and are talking EBGP to each
other.  So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in turn
advertise the route to P1.  When P1 receives the advertisement, it will then
send the advertisement to PE11 and PE12.

Here are my questions:
     (1) A VPN service provider can assign route distinguisher (RD) at its own
discretion.  So the VPN customer's RD in AS1 will likely be different from its
RD in AS3.  When P1 receives the VPN-ipv4 route advertisement from P3, does the
RD in the advertisement need to be converted first before being sent to PE11 and
PE12?
     (2) How about route target extended communities?  Do they need to be
converted too?
     (3) Can anyone show me a detailed diagram with both the control plane
set-up and the data plane forwarding for the above VPN deployment scenario?

Regards,
-- James Huang

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 04 Jan 2001 07:24:14 -0800

Mike,

> According to my understanding, RFC2547bis specifies a RD structure
> which is globally unique to allow for uncoordinated administration
> of this resource among st service providers. Therefore surely the
> simple answer is: "No. There is no need to change the RD at the
> boundary indeed such an uneccesary VPN-IP4 address translation
> should be deprecated." Administratively the service provider
> receiving the request to add a site will determine the RD to be
> used and should be able to expect other participating SPs to work
> with that. What is more difficult to understand is Yakov's reply
> "...How ever, P1 *may* do the conversion.....". Under what
> circumstances is it envisaged that a conversion may be required?

I can't think of any *practical* circumstances when such a conversion
may be required. But from this it doesn't follow that there are
no such practical circumstances - it is just that I am not aware
of them.

The point I'd like to make is that if such circumstances will
arise, one may convert RDs.
  
Yakov.