Hi Andrew, Most of what you say is true, so is my statement that MPLS labels are never carried in SAFI 1 in BGP.
However, let me explain why I think a bit different view may work better here ... First let's clearly divide MPLS labels used for transport (which create actual LSPs) from MPLS labels used for services (which are used to demux packets at the egress PEs into appropriate context tables - typically VRFs but not only (can be directly CEs too)) So the draft in the discussion is about overlay VPN services and therefore the analogy made to MPLS labels are only related to SAFI 128 or SAFI 70. Nothing here travels in unicast SAFI 1 nor in any IGP. So in the context of this draft we should never allow to put the new attribute neither in SAFI 1 nor even SAFI 4. But now comes the part which makes this discussion mangled ... unlike in MPLS where LSPs need to be signalled in SRv6 you do not need any signalling and IPv6 reachability is all that is needed for transport. So in SRv6 what is in MPLS world signalled in LDP or RSVP-TE or SAFI 4 is indeed carried in AFI 2 & SAFI 1. /* SAFI 4 comes helpful when you build hierarchical LSPs but in this discussion it is completely irrelevant. */ So I can see why some people may have thought oh since transport in SRv6 comes for free let's load it with services in an attribute and be done. Yes I can see that flattening this make it potentially easier (one less SAFI to enable), but I am not sure we have reached a broad agreement here. This comes as a consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format and new SAFI) to an attribute. Thx, R. On Sun, Feb 13, 2022 at 2:50 PM Andrew - IETF <andrew-i...@liquid.tech> wrote: > +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> 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. > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com> > > *Gyan Mishra* > > *Network Solutions Architect * > > *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
