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

[Robert Raszuk <[e-mail]>]

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.

> 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?





On Wed, Oct 31, 2012 at 10:59 PM, Lucy yong <[e-mail]> wrote:
> 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
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: Eric Rosen [mailto:[e-mail]]
>> Sent: Wednesday, October 31, 2012 3:45 PM
>> To: Lucy yong
>> Cc: Robert Raszuk; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01
>>
>> 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 ...)
>>
>> > 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.
>>
>> 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 ...