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

From: <[email-masked]>
Date: Tue, 8 Mar 2022 12:00:08 +0800 (CST)

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 8 Mar 2022 13:03:59 +0100

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 <[email-masked]> wrote:

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

---

From: Eduard Metz <[email-masked]>
Date: Sun, 13 Mar 2022 14:04:02 +0100

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 <[email-masked]> wrote:

>> [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?
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Mar 2022 18:04:16 -0400

Hi Robert

Agreed.  A new SAFI for VPN and even MVPN application service encoding with
multiple transports adds quite lot of complexity.

The P2P one hop nature of MP Reach has been a Day 1 issue that has been
problematic to troubleshoot and that would be great if you have a solution
that does a dynamic capabilities discovery and push maybe a Pub/Sub model
would work.

The security implications of SRv6 transport encoding of what normally would
be in MPLS shim and with the label stack is automatically limited to the
MPLS domain.  However  with SRV6 BGP prefix SID attribute encoding of VPN
label into the ARG field of the SRV6 SID is a definite security
consideration which was identified in RFC 8402 to take the best practices
of securing the edges.

I think with Ketan update of the verbiage in the security considerations
should highlight to operators that this issue exists and to carefully
protect against the leakage.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*