Hi Robert I am not saying MPLS is sent in SAFI 1.
Let me try to explain. In the use case we are discussing in section 5.3 and 5.4 is when there is no VPN overlay as the PE-CE AC sits in the global routing table native BGP unlabeled prefixes and the label stack is just a single label deep with the topmost transport label. In that scenario 5.4 is IPv6 unicast SAFI 1 NLRI is carried over an IPv6 core transport label LSP. In the MPLS analogy use case of global table routing there is no bottom of stack service label as is required for L3 VPN where we have a label as we have an VPN overlay present. So the BGP routes are carried in the BGP RIB natively in the global routing table unlabeled. So that is what we are talking about for the 5.4 use case now with SRv6 no VPN label and so NO SRv6 L3 service TLV encoded in BGP prefix SID attribute. The MPLS label stack L3 VPN service label in SRv6 scenario in FUNCT field is now not present with SAFI 1 IPV6 Unicast “Global IPv6 over IPv6 core”. In section 5.1 and 5.2 BGP-LU SAFI 4 is required because the SRv6 L3 Service TLV for L3 VPN overlay service route must encoded in BGP prefix SID as it must be sent as labeled. So in section 5.3 Global IPv4 over SRv6 core is similar to a 6PE RFC 4798 scenario analogy where the IPv6 prefixes are carried over an IPv4 core with IPv4 signaled LSP with additional bottom of stack label as IPV6 prefixes are labeled with BGP-LU SAFI 4 2/4 and must be sent labeled due to PHP requirement as stated in RFC 4798. So we have in section 5.3 the same scenario as 6PE but now over SRv6 using RFC 8950 IPv6 next hop encoding to carry the BGP LU SAFI 4 labeled IPv4 prefixes. So in 5.3 that section would need to be updated to state that BGP-LU labeled IPv4 prefixes is necessary with encoded SRv6 L3 service TLV in BGP prefix SID attribute so the IPv4 prefixes can be sent as labeled prefixes over SRv6 core. Upon exiting the SRv6 domain at the egress PE the outer IPv6 header is removed that contains the SRv6 programming endpoint behavior semantics with native payload forwarded by the PE to the CE similar to MPLS label disposition at egress PE exiting the domain. So here no issue with filtering as once you exit the domain the SRv6 forwarding plane semantics are stripped from the packet. Hopefully this clarifies. Many Thanks, Gyan On Sun, Feb 13, 2022 at 7:48 AM Robert Raszuk <rob...@raszuk.net> wrote: > Gyan, > > MPLS is never sent in SAFI 1. > > Thx, > R. > > On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > >> Hi Robert >> >> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk <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. >>> >>> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* >> >> >> >> *M 301 502-1347* >> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
