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

[Robert Raszuk <[e-mail]>]

Dear Yao,

The issue is not related to support or no support of a new feature
although that is also not well addressed in current BGP-4 specification.
The question is about coexistence of multiple transports and
service encoding for the same application.

I have a separate proposal on this, but did not post it before the cut off
date. So expect more on this after IETF in Vienna.

Best,
R.










On Tue, Mar 8, 2022 at 5:00 AM <[e-mail]> wrote:

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