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

[Robert Raszuk <[e-mail]>]

Section 9.  Carriers' Carriers

Best,
R.

On Wed, Oct 31, 2012 at 11:17 PM, Lucy yong <[e-mail]> wrote:
> Another silly question, What does CSC stand for?
> Lucy
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert
>> Raszuk
>> Sent: Wednesday, October 31, 2012 5:07 PM
>> To: Lucy yong
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: comment on draft-fang-l3vpn-virtual-pe-framework-01
>>
>> 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 ...