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

[Lucy yong <[e-mail]>]

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