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

Hi Robert,

Curious to learn your proposal on this, as you mentioned earlier defining
new AFI/SAFI may be the cleanest, but as I understand there are also some
hurdles to be taken there.I think it its necessary to be able to identify
different dataplane capabilities unambiguously in some way.

cheers,
  Eduard

On Tue, Mar 8, 2022 at 1:04 PM Robert Raszuk <robert@raszuk.net> wrote:

> 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 <liu.yao71@zte.com.cn> 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
>>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>