[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] Response to comments on generalized RT constrain solution
Hi Rajiv,
> Firstly, assigning the same RT to two different customers' VPN inside
> the SP network must be avoided (unless the intent is that two VPNs need
> each others' routes). It is indeed a misconfiguration. In fact, this is
> explicitly outlined in section 4.3.5 of RFC4364.
>
> <excerpt>
> Then each site is associated with a VRF, a single Route Target
> attribute is chosen, that Route Target is assigned to each VRF as
> both the Import Target and the Export Target, and that Route Target
> is not assigned to any other VRFs as either the Import Target or the
> Export Target.
> </excerpt>
Thanks for the references.
IMO, this description is about different customers' VPN of the same address
family (because this rfc only describes the procedures of L3VPNv4). But the
procedures of RT assignment among different kinds of VPNs are not explicitly
described.
>
> Secondly, assigning the same RT to different (sub) address-families
> belonging to the same customer' VPN inside the SP network should not be
> permitted unless they result in the congruent topologies. If they don't,
> then the customer sites should be perceived to belonging to different
> VPNs (one for IPv4 and the other for IPv6, say), requiring two different
> RT value(s).
>
> In the contrary, if each customer site needs both
> IPv4 and IPv6 routes, then each site participates
> in congruent IPv4 and IPv6 topologies. Hence, same
> RT (set) could be utilized in the VRF.
>
> Unfortunately, RFC4364 is not explicit about this. While one may deduce
> the above from the section 4.3.5 of RFC4364, the section 4.3.1 paints a
> different picture:
>
> <excerpt>
>
> A Route Target attribute can be thought of as identifying a set of
> sites. (Though it would be more precise to think of it as
> identifying a set of VRFs.) Associating a particular Route Target
> attribute with a route allows that route to be placed in the VRFs
> that are used for routing traffic that is received from the
> corresponding sites.
>
> </excerpt>
>
> Unfortunately, the RFC4659 (VPNv6) is moot on this topic. We need to
> write a document to clarify this better,
I agree that currently there is no clear description on RT assignment among
different kinds of VPNs. For this purpose, a document on this topic is good.
> otherwise the lack of clarity
> on this topic would continue to stir the confusion, resulting in the
> undesired proposals and efforts.
It depends on whether the requirement is valid or not, and with detailed
analysis of the problems, it would make it clearer and may give us more
inputs to determine whether the proposals and efforts are needed.
Regards
Jie
>
> Cheers,
> Rajiv
>
>
> > -----Original Message-----
> > From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
> Mach
> > Chen
> > Sent: Tuesday, November 10, 2009 11:30 PM
> > To: Robert Raszuk (raszuk); Jie Dong
> > Cc: idr at ietf.org
> > Subject: Re: [Idr] Response to comments on generalized RT constrain
> solution
> >
> > Hi Robert,
> >
> > > I think what you are trying to express is to assing on one PE 100:1
> for
> > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for
> customer
> >
> > Exactly, this is one of the issues that may lead to sending/receiving
> > unnecessary VPN routes.
> >
> > > Y. That would be IMHO a misconfiguration.
> >
> > Why do you think this is misconfiguration? By your logic, does it mean
> the
> > configuration of one type of VPN will restrict and/or be restricted by
> other
> > types of VPNs. If things like this, it will affect the flexibility of
> the
> > deployment/provisioning of VPNs. And that, especially in inter-domain
> > scenarios, it may be difficult/impossible to apply this restriction.
> >
> >
> > Best regards,
> > Mach
> >
> > --------------------------------------------------
> > From: "Robert Raszuk" <raszuk at cisco.com>
> > Sent: Wednesday, November 11, 2009 10:17 AM
> > To: "Jie Dong" <dongjie_dj at huawei.com>
> > Cc: "'Pedro Marques (roque)'" <roque at cisco.com>; "'Mach Chen'"
> > <mach at huawei.com>; <idr at ietf.org>
> > Subject: Re: [Idr] Response to comments on generalized RT constrain
> solution
> >
> > > Jie,
> > >
> > >> But with normal rt-constrain PEs of these sites will receive VPN
> > >> routes of all these services, including the unwanted ones.
> > >
> > > I don't understand the definition of "unwanted routes" in the draft
> and in
> > > your email description.
> > >
> > > If RT is assigned that matches the routes they are received and
> accepted.
> > > If RT attached to the route is not part of import of any VRF of the
> PE
> > > they are dropped today and with rt-constrain will not be sent.
> > >
> > > I really don't see how this is related to SAFIs/services provided.
> > >
> > > In fact if you don't have service ABC configured on such PE in
> question it
> > > will not receive any routes either today or with rt-constrain.
> Please
> > > observe that rt-constrain is just a filter not the request for
> routes.
> > >
> > > I think what you are trying to express is to assing on one PE 100:1
> for
> > > L3VPNs for customer X and on the other PE 100:1 for L2VPNs for
> customer Y.
> > > That would be IMHO a misconfiguration.
> > >
> > > Cheers,
> > > R.
> > >
> > >
> > >> Hi, Thanks for your comments. Please see inline...
> > >>
> > >>>> The issue we really concern is that the RTs overlap among
> different
> > >>>> customers. Different VPNs for different customers may be
> configiured
> > >>> to
> > >>>> used
> > >>>> same RT, that means the RT of one type of VPN may attracted
> unwanted
> > >>>> routes
> > >>>> belong to other types of VPNS, and that the RT
> > >>>> configuration/modification of
> > >>>> one type VPN may affect the other VPNs that are totally not
> relevant
> > >>> to
> > >>>> that
> > >>>> VPN.
> > >>> I'm not sure I follow your argument. Clearly if we are talking
> about
> > >>> VPNs with the same address family you can't use the same RT for
> > >>> different VPNs. For a VPN service to operate correctly the
> provisioning
> > >>> mechanism should be able to assign an unique RT per VPN.
> > >>>
> > >> Yes, for VPNs with the same AFI/SAFI, different RT should be
> assigned for
> > >> different customers.
> > >>> Now, even if you had the ability to use the same RT value across
> > >>> different address families you most likely wouldn't want to use
> it. For
> > >>> example, if customer A has a VPN with v4 service and customer B
> has a
> > >>> VPN with v6 service it would be a *really bad idea* to assign the
> same
> > >>> value to both because A may want to have v6 service in the future
> or
> > >>> vice-versa.
> > >> What we mean here is for different AFI/SAFIs the allocation of RT
> should
> > >> be
> > >> able to operate independently. Operators can choose to use same or
> > >> different
> > >> RT for different kinds of VPNs, either for same customer or
> different
> > >> customers. The assignment of RT can be quite flexible. Especially
> in
> > >> mutli-ISP scenarios, different ISP may use the same RT for
> different kind
> > >> of
> > >> VPNs.
> > >>
> > >>> The main point here is that in practice RT assignment is not per
> AF but
> > >>> per VPN. That is the reason the rt constraint draft handles the RT
> > >>> independently of the AF.
> > >> If one customer belongs to L3VPN-1 and also L2VPN-2, the RTs for
> these
> > >> two
> > >> VPNs are independent, they could use either different RT or same RT
> based
> > >> on
> > >> the policy of the operator.
> > >>> It seems to me that attempts to have RT constraint have per AF
> semantics
> > >>> are misguided in the least. A VPN will very likely have multiple
> > >>> services that use different BGP AFI,SAFIs and while in theory they
> could
> > >>> use multiple RTs there is no practical value in doing so. That
> would
> > >>> result in having to advertise multiple times the same information
> when
> > >>> using rt-constraint
> > >> Using same RT for multiple services is reasonable, however the
> sites may
> > >> not
> > >> be identical for all these services. Some sites may only be
> interested in
> > >> some of these services, and more unneeded routes may get their PEs
> into
> > >> trouble. But with normal rt-constrain PEs of these sites will
> receive VPN
> > >> routes of all these services, including the unwanted ones. This can
> > >> happen
> > >> especially during network migration and deployment of new services.
> As
> > >> you
> > >> said, using different RT is not recommended, and using same RT some
> PEs
> > >> need
> > >> the ability to notify others only some kind of routes are needed.
> > >>
> > >> And as Mach has said before, compared with the quantity of unwanted
> > >> routes
> > >> being advertised, the amount of RT-constrain information can be
> ignored.
> > >>
> > >>> In my mind, the question we should ask is: would a service
> provider use
> > >>> the same customer id for 2 different customers (even if they have
> > >>> different services ?). The answer is no. The same way the SP
> > >>> provisioning system should be able to assign unique RTs per
> customer so
> > >>> that ops can retrieve the customer-id from the RT.
> > >> Operators can choose how to manage their networks, and also
> different
> > >> operators can choose different ways. IMO we should provide methods
> to
> > >> lighten operators' burden on VPN service provisioning and assure
> that
> > >> different services will not affect each other.
> > >>
> > >> Regards
> > >> Jie
> > >>
> > >>
> > >> _______________________________________________
> > >> Idr mailing list
> > >> Idr at ietf.org
> > >> https://www.ietf.org/mailman/listinfo/idr
> > >>
> > >
> > _______________________________________________
> > Idr mailing list
> > Idr at ietf.org
> > https://www.ietf.org/mailman/listinfo/idr