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

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

On Tue, Mar 8, 2022 at 7:04 AM 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
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*