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

[Jeff Tantsura <[e-mail]>]

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

Regards,
Jeff

On Oct 31, 2012, at 22:36, "Luyuan Fang (lufang)" <[e-mail]> wrote:

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