Subject: comment on draft-fang-l3vpn-virtual-pe-framework-01

From: Lucy yong <[email-masked]>
Date: Wed, 31 Oct 2012 16:40:49 +0000

Hi Co-authors on this draft,

I read the document and have some comments and suggestions.

1)  The intention of the draft is to extend L3VPN PE to a vPE on end devices in DC.  We need to distinct about two cases clearly in the framework, one is that a L3VPN applies to intra DC; another is a L3VPN in DC connecting L3VPN in WAN which connects to Enterprise site. We can fully describe vPE function in the first case. the second case is about L3VPN interworking across different underlying networks, which is orthogonal to vPE functions. The draft seems mix two together. In the nvo3 use case draft, we have clearly described two use cases. (draft-mity-nov3-use-case-04)

2)  Text for the key requirement in section 1.2 :
   3) Support end-to-end L3VPN connectivity, e.g. L3VPN can start from a
   service network end device, connect to a corresponding L3VPN in the
   WAN, and terminate in another service network end device.

   Not sure why this is the key requirement. If this is to allow end-to-end L3VPN span across multiple DC sites, DC providers may prefer to use WAN to interconnect DC underlying networks first. Then they can create end-to-end L3VPN (overlay) without WAN operator interferes. This is, in turn, to become the first case in two case mentioned in the first comment. IMO: the key requirements is to support case 1 and case 2 in my first comments.

3)  What does the true network abstraction mean?

4)  The third paragraph in section 2.1. comment: if vPE allows L3VPN control plane and forwarding function residing on different physical devices, a protocol is necessary between control plane and forwarding entity. This is a significant change for L3VPN PE function. The draft should point out.

5)  The fourth paragraph in section 2.1. Comment: When vPE and VM on one end device, it simplifies the control plane and data plane functions between PE and CE in RFC4364. The draft should clarity that.

6)  Since we need to decouple the underlying network and the overlay network, i.e. end-to-end L3VPN in this document, modeling a virtualized service network in figure 1 to include Gateway PE, Transport Device and vPE in end device is misleading. The virtualized service network should not include Transport device at all.

7)  Again, this model should be generic to show that a virtualized service network may include vPEs, PE, or Gateway PE to cover both case 1 and case 2 in my first comment.

8)  Again, this model architecture should separate DC physical network and DC virtualized service network like the nvo3 architecture model in the nvo3 framework draft. This will let you describe a WAN L3VPN that may connect to DC underlying network and DC virtualized service network. Please see the draft-hy-nvo3-vpn-gap-analysis draft.

9)  If vPE can reside on different physical devices as described in the draft, using a VRF block to describe the VPN entity on a vPE is not proper because you can't split them further. So Figure 2 need to separate the VRF into two entities and describe that two entities may be on one end device or may on separated devices. IMO: this is significant different from the L3VPN in RFC4364.

10)         Figure 3 can only express option A in RFC4364. Option B does not use gateway PE, it only uses ASBR. ASBR is very different from a PE. Although in option B, L3VPN control plane can advertise the VPN routes from a PE in an AS to the PE in another AS. It does not mean that the P nodes in an AS know how to route to the PE in another AS. This will be an issue when use IP GRE tunnels. To use MPLS LSP tunnel, option B requires pre-build MPLS LSP tunnel between two PEs that belong to different ASes, which requires two SPs pre-provisioning process that may not apply to here. The framework need to clarify that. In addition, WAN may use MPLS LSP tunnel and DC may use IP based tunnel.

11)         In section 3, regarding to Centralized routing controller, it is good to enable SDN approach in L3VPN. However, RFC4364 does not enable SDN approach. This is regardless use of vPE or PE. This is significant change to the L3VPN in my opinion.

12)         As the result, the framework contains significant extension or changes to existing L3VPN. We should require the WG recharter to include this pieces first.

Cheers,
Lucy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Oct 2012 17:54:49 +0100

Lucy.

> To use MPLS LSP tunnel, option B requires pre-build MPLS
> LSP tunnel between two PEs that belong to different ASes, which requires two
> SPs pre-provisioning process that may not apply to here.

Incorrect.

Option B does not require "pre-build MPLS LSP tunnel between two PEs
that belong to different ASes" - that would be option C.

In fact option B does not require any pre established LSP or IP tunnel
between PE-PE. Option B ASBR set's next hop self on VPNv4/v6 routes
hence it terminates any corresponding transport encapsulation used in
it's own domain.

Cheers,
R.

---

From: Lucy yong <[email-masked]>
Date: Wed, 31 Oct 2012 18:50:46 +0000

Hi Robert,

Here is the text from RFC4364 regarding to option B. 

In this procedure, the PE routers use IBGP to redistribute
         labeled VPN-IPv4 routes either to an Autonomous System Border
         Router (ASBR), or to a route reflector of which an ASBR is a
         client.  The ASBR then uses EBGP to redistribute those labeled
         VPN-IPv4 routes to an ASBR in another AS, which in turn
         distributes them to the PE routers in that AS, or perhaps to
         another ASBR which in turn distributes them, and so on.

This procedure requires that there be a label switched path
         leading from a packet's ingress PE to its egress PE.  Hence the
         appropriate trust relationships must exist between and among
         the set of ASes along the path.  Also, there must be agreement
         among the set of SPs as to which border routers need to receive
         routes with which Route Targets.
-end

Option C request set up two LSP tunnel, one from ingress PE to egress PE, second from ingress PE to ASBR to solve the issue in IGP.

Lucy
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Wednesday, October 31, 2012 11:55 AM
> To: Lucy yong
> Cc: Luyuan Fang (lufang); [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01
> 
> Lucy.
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 31 Oct 2012 19:05:03 +0000

Lucy,

Robert is right. In option B, IGP LSP is terminated on ASBRs and the label
switching is performed using VPN labels. The paragraph that you quoted
from 4364, just says appropriate trust relationship need to exist between
ASes for EBGP route redistribution.

Cheers,
Ali

On 10/31/12 11:50 AM, "Lucy yong" <[email-masked]> wrote:

>Option C request set up two LSP tunnel, one from ingress PE to egress PE,
>second from ingress PE to ASBR to solve the issue in IGP.
>
>Lucy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Oct 2012 21:16:05 +0100

Lucy,

Your interpretation of the RFC is wrong.

Moreover your understanding of option C is also incorrect.

> second from ingress PE to ASBR to solve the issue in IGP.

That may refer only to local within given AS LSP hierarchy for example
using RFC3107 for external PE loopbacks distribution rather then
injecting them to the local IGP.

Note that that non of those concerns apply when you use IP
encapsulation between PEs what is the preferred encapsulation anyway
in the data center environments when tenants need to extend their VPNs
across WAN.

Cheers,
R.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 Oct 2012 16:44:41 -0400

I think there's a misunderstanding of the sentence from RFC4364: "This
procedure requires that there be a label switched path leading from a
packet's ingress PE to its egress PE."  

If a VPN packet is traveling the following path:

    PE1--->P1--->ASBR1--->ASBR2--->P2--->PE2

where the ASBRs are supporting option B, then there is necessarily an LSP
consisting of the following sequence of routers: <PE1,ASBR1,ASBR2,PE2>.
What makes this sequence of routers an LSP is that they all operate on the
"VPN label".  (See section 3.15 of RFC 3031 for the precise definition of
"Label Switched Path".  Note that "LSP" is defined relative to the position
of a particular label in the stack of a particular packet.)  PE1 pushes on
the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2 swaps it
with a label assigned by PE2, PE2 pops it.  We could call this the "VPN
LSP", because it follows the path of distribution of a VPN-IP route.

The cited text is intended to distinguish option B from option A; in option
A, the sequence <PE1,ASBR1,ASBR2,PE2> is not an LSP, because ASBR2 does not
distribute labels to ASBR1.  

> which requires two SPs pre-provisioning process that may not apply to
> here. 

The LSP exists by virtue of the distribution of the labeled VPN-IP routes.

Note that, although <PE1, ASBR1, ASBR2, PE2> is an LSP according to the
definition in RFC 3031, each router in the sequence only has to know which
router is next in the sequence; the ingress router does not need to know how
to reach to the egress router.  Also, there is no requirement that an LSP is
used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2.  Either or
both of those "hops" could be via a GRE tunnel, or any other method of
transport.

It's true that in a typical deployment, there is a "top-level" LSP
<PE1,P1,ASBR1> and another "top-level" LSP <ASBR2,P2,PE2>. Neither of these
is the VPN LSP; rather, each is used to carry packets from one member of the
VPN LSP to the next member in sequence.  But option B is independent of how
packets get between adjacent members of the VPN LSP.

> WAN may use MPLS LSP tunnel and DC may use IP based tunnel.

That is compatible with RFC4364 option B, because the LSP
<PE1,ASBR1,ASBR2,PE2> still exists.

> This will be an issue when use IP GRE tunnels.

It's only an issue if you want to have a single GRE tunnel that goes from
PE1 to PE2.  If that is what you want, then you should probably be using
option C.  Option B does not tell the ingress PE who the egress PE is.
(Well, not unless RFC 6513/6514 is also in use ...)

> second from ingress PE to ASBR to solve the issue in IGP. 

In option C, the "VPN LSP" would be <PE1,PE2>.  If one wants to use MPLS to
move the packets from PE1 to PE2, one needs a "top-level" LSP like
<PE1,P1,ASBR1,ASBR2,P2,PE2>; but this is not the "VPN LSP".  I think you
interpreted the text from RFC 4364 as requiring this top-level LSP for
option B, but it is only intended to require the VPN LSP
<PE1,ASBR1,ASBR2,PE2>.

I'm not sure whether this makes things any clearer or not ...

---

From: Lucy yong <[email-masked]>
Date: Wed, 31 Oct 2012 21:59:34 +0000

Hi, Eric, Robert, and Ali,

Thank you very much for the explanations. They are very helpful.

You are right. The label switch path in the text means the VPN label. Individual labels are used over each segment and swapped at ASBR in option B. This is not related to underlying tunnel mechanism at all. ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR. Option A, B, C are about VPN interworking (or say virtual overlay network).

For another scenario is that, if a WAN VPN is used to interconnect DC provider underlying networks at different sites, i.e. PE-CE case, DC provider should be able to build a L3VPN among vPEs at DC sites directly, in which it seems necessary to have a tunnel between a pair of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN existence, which creates a true virtual environment. vPE host address /32 is required to advertised from one CE to another CE, will RFC4364 support this?

Regards,
Lucy  

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2012 3:45 PM
> To: Lucy yong
> Cc: Robert Raszuk; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Oct 2012 23:07:13 +0100

Hi Lucy,

To your below question the answer is yes. This is a flavor of CSC
which standard 4364 supports just fine.

Best regards,
R.

---

From: Lucy yong <[email-masked]>
Date: Wed, 31 Oct 2012 22:17:57 +0000

Another silly question, What does CSC stand for?
Lucy

> Sent: Wednesday, October 31, 2012 5:07 PM
> To: Lucy yong
> Cc: [email-masked]; [email-masked]; [email-masked];
> > For another scenario is that, if a WAN VPN is used to interconnect DC
> provider underlying networks at different sites, i.e. PE-CE case, DC
> provider should be able to build a L3VPN among vPEs at DC sites
> directly, in which it seems necessary to have a tunnel between a pair
> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN
> existence, which creates a true virtual environment. vPE host address
> /32 is required to advertised from one CE to another CE, will RFC4364
> support this?
> 
> 
> 
> 
> 
> > You are right. The label switch path in the text means the VPN label.
> Individual labels are used over each segment and swapped at ASBR in
> option B. This is not related to underlying tunnel mechanism at all.
> ASBR1 is the next hop for the PE1, a tunnel is terminated at ASBR.
> Option A, B, C are about VPN interworking (or say virtual overlay
> network).
> >
> > For another scenario is that, if a WAN VPN is used to interconnect DC
> provider underlying networks at different sites, i.e. PE-CE case, DC
> provider should be able to build a L3VPN among vPEs at DC sites
> directly, in which it seems necessary to have a tunnel between a pair
> of vPEs. This makes that DC GW and WAN VPN are not aware of DC L3VPN
> existence, which creates a true virtual environment. vPE host address
> /32 is required to advertised from one CE to another CE, will RFC4364
> support this?
> >
> > Regards,
> > Lucy
> >
> >
> >
> >
> >
> >
> >
> >> where the ASBRs are supporting option B, then there is necessarily
> an
> >> LSP
> >> What makes this sequence of routers an LSP is that they all operate
> on
> >> the
> >> "VPN label".  (See section 3.15 of RFC 3031 for the precise
> definition
> >> of
> >> of a particular label in the stack of a particular packet.)  PE1
> pushes
> >> on
> >> the label, ASBR1 swaps it with a label assigned by ASBR2, ASBR2
> swaps
> >> it
> >> A, the sequence <PE1,ASBR1,ASBR2,PE2> is not an LSP, because ASBR2
> does
> >> not
> >> to reach to the egress router.  Also, there is no requirement that
> an
> >> LSP is
> >> used to carry packets from PE1 to ASBR1, or from ASBR2 to PE2.
> Either
> >> or
> >> <PE1,P1,ASBR1> and another "top-level" LSP <ASBR2,P2,PE2>. Neither
> of
> >> these
> >> is the VPN LSP; rather, each is used to carry packets from one
> member
> >> of the
> >> VPN LSP to the next member in sequence.  But option B is independent
> of
> >> how
> >> > Option C request set up two LSP tunnel, one from ingress PE to
> egress
> >> PE,

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Oct 2012 23:19:45 +0100

Section 9.  Carriers' Carriers

Best,
R.

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 1 Nov 2012 02:13:50 +0000

Hi Lucy, Robert, Eric, Ali, and all,

Thanks for your comments.

We got hit by Hurricane Sandy very hard in NJ. We've been out of power
since Monday, with many roads blocked by downed power lines and trees, and
extensive flooding.
We have no cell phones and no landlines working.

Lucy, I'll get to your comments as soon as the situation is under control.
Thanks for your understanding.

Luyuan

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 1 Nov 2012 02:50:39 +0000

Luyuan - good luck!
Lucy - CsC stands for Carrier supporting Carrier

Regards,
Jeff