Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Robert,

Thanks for sharing your detailed consideration on BGP capability and new NLRI.
A few comments about the BGP capability solution. Please see inline [YAO].

==============================================================================

In BGP protocol any new service deployment using existing AFI/SAFI is not
easy. Especially when you are modifying content of MP_REACH or MP_UNREACH
NLRI attributes. Main reason being is that using capabilities only goes one
hop. In full mesh it all works perfect, but the moment you put RR in
between BGP speakers things are getting ugly as capabilities are not
traversing BGP nodes. /* Even in full mesh mixing transports for the same
service is a serious challenge for routers when say multihomes sites are
advertised from different PEs with different transport options */.

[YAO] As you mentioned, in the scenario multihomes sites are advertised from different PEs with different transport options without RR, e.g, CE1 are connected to PE1 and PE2, PE1 supports MPLS VPN while PE2 support SRv6 VPN, PE3 is the peer of PE1 and PE2, imagine PE3 supports both capabilities,  I don't think this brings much difference between the configuration approach and BGP capability approach.
If BGP capability is introduced, PE3 will receive both MPLS VPN and BGP VPN routes, how to process them is based on user's requirement,e.g, choosing one fixed type of routes, using the lastest routes, ECMP and so on.
If configuration approach is used, how to configure is based user's requirement as well. Before configuration on PE1 and PE2, one should first decide whether PE3 wants to receive only one type of route or to receive both routes. And if PE3 receive both routes, the processing rule also should be considered. 
In a word, in scenario like this, the consideration on user's requirement is similar in both approach.

Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily
sends a new format of the UPDATE messages. Well as today we also do not
have a notion of conditional capabilities (only send when received from
all) so if some of the RR peers do not support it you end up in partial
service. One can argue that in this case the only deterministic model is to
push the configuration from the management station and control partial
deployment of the new service from mgmt layer.

[YAO] By saying "RR peers", do you mean that in the scenario that there're multiple RRs, and they're peers of each other, if some of the RRs don't support the new BGP capability, the SRv6 service routes will not be sent to them thus result in losing part of the routes? 
If this is the case, I don't think it's a serious problem. No matter what new BGP capability one wants to introduce in this scenario, RRs are always required to support it if we want to get it right. 
If "RR peers" means other PEs, it is the expected result that PEs don't support the new capability will not receive the new kind of UPDATE messages.  So the dropping the  new routes sent to these PEs is not a problem. 
On the other hand, the management approach is always a practical option by not sending new messages to these PEs .


Regards,
Yao