+1 This is something I was a little confused about since its been referenced in these emails time and again, and I was wondering if I had missed something, but, I’ve checked to be 100% certain, RFC8950 which is what this document refers to explicitly states that the NLRI encoding of the destination must not change – and since the IPv4 NLRI leaves no provision for labels – and makes it clear that SAFI 4 is used for MPLS – MPLS doesn’t fall into SAFI 1. In fact, what is described in 5.3 only results from the nature of SRv6, it states:
SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The SRv6 Endpoint behavior of the SRv6 SID is entirely up to the originator of the advertisement. In practice, the SRv6 Endpoint behavior is End.DX4 or End.DT4. Since 5.3 can operate in SAFI 1 (it explicitly refers to Global IPv4 over SRv6 core – which by correlation to 8950 is SAFI 1) and based on the wording of the above, this actually puts MPLS type functionality into SAFI 1 where it never was before, by using the SID as a normal address which is then dealt with as a SID inside the domain. But no – this is not providing equal functionality for MPLS – this is extending MPLS style functionality into SAFI 1, which, if my reading of Warren’s discuss is accurate, is pretty much the essence of the problem. Thanks Andrew From: Robert Raszuk <rob...@raszuk.net> Sent: Sunday, February 13, 2022 3:48 PM To: Gyan Mishra <hayabusa...@gmail.com> Cc: Andrew - IETF <andrew-i...@liquid.tech>; BESS <bess@ietf.org>; Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; The IESG <i...@ietf.org>; Warren Kumari <war...@kumari.net>; bess-cha...@ietf.org; draft-ietf-bess-srv6-servi...@ietf.org Subject: Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT) Gyan, MPLS is never sent in SAFI 1. Thx, R. On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> wrote: Hi Robert On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Gyan, Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop encoding. In this case using GRT transport underlay layer now carry’s the customer routes and that is what Warren and Andrew concern is as far as BGP leaks. I would have the same concern so would VPN customers. No one is selling L2 or L3 VPN service to them distributing their reachability in the global routing table. They can do that all by themselves and there is lot's of really solid tools or products to do that already without being locked to a single telco. Gyan> MPLS provides the capability for GRT native routing SAFI 1 as well as SAFI 128, so in my opinion both should be supported by SRV6 as operators look to use SRv6 for a variety of use cases. That’s my point as there should be complete feature parity between MPLS and SRv6 as to AFI / SAFI support. Global Internet routing would not be the best use case for SAFI 1 GRT due to the attack vector - agreed, but enterprise networks with internal customers where there is a trust level is a huge use case. So when GRT is used the same edge filtering protection mechanisms used today for MPLS and SR-MPLS would apply to SRv6 for GRT use case. Not possible. It is not about filtering ... it is all about using globally routable SAFI vs private SAFIs to distribute customer's reachability, IMO that should still be OTT only. Gyan> As SRv6 source node is requirement to encapsulation with IPv6 outer header and decapsulation at egress PE for SRv6-BE and SRv6-TE path steering the security issue brought up related to 5.3 and 5.4 is not an issue requiring filtering per RFC 8402. So routable and private SAFI scenario would be the same now due to encapsulation overlay for both. Do you agree ? I don’t think we are saying 5.3 or 5.4 should not be allowed but just to tighten up verbiage as far securing the domain. BGP filtering or policy is in hands of many people. As has been proven you can not tighten them strong enough not to leak. The only natural way to tighten them is to use different plane to distribute private information what in this context means at least different BGP SAFI. So no - I do not agree with your observations. Gyan> I am not promoting use of SAFI 1 however I SRv6 should provide complete parity with MPLS to support both SAFI 1 and 128. There are plenty of use cases for SAFI 1 and it should be supported with SRv6. However I am for providing overlay reachability over global IPv6 Internet to interconnect customer sites. But routing within those sites should not be traversing Internet routers and using SAFI 1. Rgs, Robert. -- [Image removed by sender.]<http://www.verizon.com> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
