headers
John G. Scudder | 3 Nov 17:53
Favicon

Minute taker for upcoming meeting

Folks,

We have a full agenda for next week (see http://www.ietf.org/proceedings/09nov/agenda/idr.txt 
) and so it would be even more helpful than usual for someone to  
volunteer ahead of time to take minutes.  We can't start the meeting  
without at least one note taker, and if we have any extra time I'd  
rather use it for discussing drafts than badgering the group for  
volunteers.

Let's not always see the same hands, now.

Thanks in advance,

--John
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 1 comment |
headers
John G. Scudder | 8 Nov 02:05
Favicon

IDR charter update

Folks,

The IDR charter is overdue for an update.  Here is our proposal, we've  
tried to keep it short and sweet:

   The Inter-Domain Routing Working Group is chartered to standardize
   and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
   4271] capable of supporting policy based routing for TCP/IP
   internets.

   The objective is to promote the use of BGP-4 to support IP version
   4 and IP version 6.  The working group will continue to work on
   improving the robustness and scalability of BGP, and extending the
   protocol as otherwise needed to support the growth and success of
   the Internet.

We'll discuss this at Tuesday's meeting.  Comments on the mailing list  
are also welcome of course.  I'm hoping to send this to the IESG for  
approval ASAP.

Milestones and so on will also be updated, but the process for doing  
that is lightweight.

--John & Sue
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
John G. Scudder | 9 Nov 01:07
Favicon

Fwd: Minute taker for upcoming meeting

Nobody has stepped forward to volunteer yet.  Anyone, anyone?

--John

Begin forwarded message:

> From: John Scudder <jgs <at> juniper.net>
> Date: November 4, 2009 1:53:20 AM GMT+09:00
> To: idr List <idr <at> ietf.org>
> Subject: [Idr] Minute taker for upcoming meeting
>
> Folks,
>
> We have a full agenda for next week (see http://www.ietf.org/proceedings/09nov/agenda/idr.txt
> ) and so it would be even more helpful than usual for someone to
> volunteer ahead of time to take minutes.  We can't start the meeting
> without at least one note taker, and if we have any extra time I'd
> rather use it for discussing drafts than badgering the group for
> volunteers.
>
> Let's not always see the same hands, now.
>
> Thanks in advance,
>
> --John

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jie Dong | 10 Nov 06:31
Favicon

Response to comments on generalized RT constrain solution

Hi Robert,

 

Thanks for your comments.

 

My three points here:

1. By carefully configuring the RTs may resolve the issues raised in our draft (e.g., in small/simple networks, there are not so much VPNs deployed in the network).  But with the increment of the size/VPNs of the network, it requires that the operators have to assign RTs very carefully to make sure there is no overlapping between RT spaces of different kind of VPNs, this sometime may be a big burden for SPs. And this might be easy for networks which is operated by only one operator, but is quite difficult for networks operated by many ISPs.

 

2. With the current mechanisms, there is possibility that the deployment of a new VPN affects the existing network, and sometimes it may lead to unexpected situations. IMO this is the worst thing that operators do not want to see.

                                                                                                                                                                                                                                                        

3. BTW, there is another issue regarding to the length of the RT filed, the IPv6 address specified RT is covered in rfc4684.

 

Regards

Jie

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 27 comments |
headers
Robert Raszuk | 10 Nov 07:48
Picon
Favicon

Re: Response to comments on generalized RT constrain solution

Hi Jie,

 > 1. By carefully configuring the RTs may resolve the issues raised in our
 > draft (e.g., in small/simple networks, there are not so much VPNs
 > deployed in the network).  But with the increment of the size/VPNs of
 > the network, it requires that the operators have to assign RTs very
 > carefully to make sure there is no overlapping between RT spaces of
 > different kind of VPNs,

I don't think this is of any mandatory requirement to make sure that RTs 
are specified unique between different kinds of VPNs of a given customer.

In particular if you have customer interested in using IPv4 and IPv6 
addressing I would in fact very much suggest to set the RTs to be a 
descriptive reflection of such customer sites and be of the same value.

For customers using l2VPN and L3VPNs or MVPNs those also will be 
congruent with a given customer sites. In fact it would be a mistake to 
specify different RTs for IP unicast and for MVPN in most cases.

Of course between different customer's VPNs you need different RT values 
but this is basic provisioning requirement for BGP VPNs application.

 > this sometime may be a big burden for SPs. And
 > this might be easy for networks which is operated by only one
 > operator, but is quite difficult for networks operated by many ISPs.

There is already very well defined set of procedures to provide inter-as 
VPNs for any type of VPN. I am not sure if your draft would make it any 
easier to send RTs separately for different SAFIs.

In worst case the consequence of splitting RT space may result in 
duplicating identical RT information to be distributed many times.

 > 2. With the current mechanisms, there is possibility that the
 > deployment of a new VPN affects the existing network, and sometimes it
 > may lead to unexpected situations. IMO this is the worst thing that
 > operators do not want to see.

I don't see what unexpected situations may arise. Can you provide some 
examples here ?

 > 3. BTW, there is another issue regarding to the length of the RT
 > filed, the IPv6 address specified RT is covered in rfc4684.

Can you clarify what is the issue ?

Many thx,
R.

> My three points here:
> 
> 1. By carefully configuring the RTs may resolve the issues raised in our 
> draft (e.g., in small/simple networks, there are not so much VPNs 
> deployed in the network).  But with the increment of the size/VPNs of 
> the network, it requires that the operators have to assign RTs very 
> carefully to make sure there is no overlapping between RT spaces of 
> different kind of VPNs, this sometime may be a big burden for SPs. And 
> this might be easy for networks which is operated by only one operator, 
> but is quite difficult for networks operated by many ISPs.
> 
>  
> 
> 2. With the current mechanisms, there is possibility that the deployment 
> of a new VPN affects the existing network, and sometimes it may lead to 
> unexpected situations. IMO this is the worst thing that operators do not 
> want to see.
> 
>                                                                                                                                                                                                                                                          
> 
> 
> 3. BTW, there is another issue regarding to the length of the RT filed, 
> the IPv6 address specified RT is covered in rfc4684.
> 
>  
> 
> Regards
> 
> Jie
> 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 26 comments |
headers
Mach Chen | 10 Nov 17:10
Favicon

Re: Response to comments on generalized RT constrain solution

Hi Robert,

Fogive me to chime in.

Please see inline...

> Hi Jie,
>
> > 1. By carefully configuring the RTs may resolve the issues raised in our
> > draft (e.g., in small/simple networks, there are not so much VPNs
> > deployed in the network).  But with the increment of the size/VPNs of
> > the network, it requires that the operators have to assign RTs very
> > carefully to make sure there is no overlapping between RT spaces of
> > different kind of VPNs,
>
> I don't think this is of any mandatory requirement to make sure that RTs 
> are specified unique between different kinds of VPNs of a given customer.

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.

>
> In particular if you have customer interested in using IPv4 and IPv6 
> addressing I would in fact very much suggest to set the RTs to be a 
> descriptive reflection of such customer sites and be of the same value.
A fine decription of a specific RT may help the opertor to admin their VPNs 
deloyment, but it could not change the essence of the existing RT-constrian 
that it may lead to RTs overlap or conflicts among dififferent VPNs.

>
> For customers using l2VPN and L3VPNs or MVPNs those also will be congruent 
> with a given customer sites. In fact it would be a mistake to specify 
> different RTs for IP unicast and for MVPN in most cases.
>
> Of course between different customer's VPNs you need different RT values 
> but this is basic provisioning requirement for BGP VPNs application.
Different customers serviced with the same kinds of VPN, of cause, RT should 
be set to different values. As I said above, different customers serviced 
with different kinds of VPNs, it SHOULD not be required to use different 
values anymore.

>
> > this sometime may be a big burden for SPs. And
> > this might be easy for networks which is operated by only one
> > operator, but is quite difficult for networks operated by many ISPs.
>
> There is already very well defined set of procedures to provide inter-as 
> VPNs for any type of VPN. I am not sure if your draft would make it any 
> easier to send RTs separately for different SAFIs.

In our draft, we firstly propose to send RTs separately for different AFIs, 
and of cause, if we could differentiate different SAFIs(it is also proposed 
in the draft), that will be better. With these extensions, there will (and 
SHOULD) be no affection/relationship among different kinds of VPNs anymore.
>
> In worst case the consequence of splitting RT space may result in 
> duplicating identical RT information to be distributed many times.

IMO, compare to the unwanted routes sending/processing and the underlying 
affection among VPNs, it could be ignored.
>
> > 2. With the current mechanisms, there is possibility that the
> > deployment of a new VPN affects the existing network, and sometimes it
> > may lead to unexpected situations. IMO this is the worst thing that
> > operators do not want to see.
>
> I don't see what unexpected situations may arise. Can you provide some 
> examples here ?

For a BGP router, with the current BT-constrian mechansims, it's possilbe 
that it may received some out-of-expectation routes, and these routes may 
make the number of the routes of that router reaching to a threshold that 
may triger the router to disconnect BGP sessions.

>
> > 3. BTW, there is another issue regarding to the length of the RT
> > filed, the IPv6 address specified RT is covered in rfc4684.
>
> Can you clarify what is the issue ?

Here is the RT difinition in RFC4684:
+-------------------------------+
| origin as        (4 octets)   |
+-------------------------------+
| route target     (8 octets)   |
+                               +
|                               |
+-------------------------------+

There is only 8 octets left for route target.

Best regards,
Mach

>
> Many thx,
> R.
>
>
>> My three points here:
>>
>> 1. By carefully configuring the RTs may resolve the issues raised in our 
>> draft (e.g., in small/simple networks, there are not so much VPNs 
>> deployed in the network).  But with the increment of the size/VPNs of the 
>> network, it requires that the operators have to assign RTs very carefully 
>> to make sure there is no overlapping between RT spaces of different kind 
>> of VPNs, this sometime may be a big burden for SPs. And this might be 
>> easy for networks which is operated by only one operator, but is quite 
>> difficult for networks operated by many ISPs.
>>
>>  2. With the current mechanisms, there is possibility that the deployment 
>> of a new VPN affects the existing network, and sometimes it may lead to 
>> unexpected situations. IMO this is the worst thing that operators do not 
>> want to see.
>>
>> 
>> 3. BTW, there is another issue regarding to the length of the RT filed, 
>> the IPv6 address specified RT is covered in rfc4684.
>>
>>  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
Permalink | Reply | 25 comments |
headers
Pedro Marques (roque | 10 Nov 17:31
Picon
Favicon

Re: Response to comments on generalized RT constrain solution

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

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.

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.

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.

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.

  Pedro.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
Permalink | Reply | 19 comments |
headers
Jie Dong | 11 Nov 02:59
Favicon

Re: Response to comments on generalized RT constrain solution

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
Permalink | Reply | 18 comments |
headers
Robert Raszuk | 11 Nov 03:17
Picon
Favicon

Re: 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
Permalink | Reply | 17 comments |
headers
Mach Chen | 11 Nov 05:30
Favicon

Re: 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
Permalink | Reply | 3 comments |

Gmane