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

["Luyuan Fang (lufang)" <[e-mail]>]

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


On 10/31/12 6:19 PM, "Robert Raszuk" <[e-mail]> wrote:

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