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

[Robert Raszuk <[e-mail]>]

Hi John,

You have highlighted below a very important point. It was discussed among
co-authors, but perhaps not sufficiently during the BESS process as the
issue is really not a BESS WG problem.

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 */.

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.

The natural alternative would be to never modify NLRI format once shipped
by RFC. When needed issue a new SAFI. Yes that is an option (and has always
been) but it also comes with its own set of issues. New SAFI is really
great to define for new service/feature etc ... Here however in the context
of this discussion we are changing transport for existing service.  And
just like it was the case with MPLS over UDP or  tunnel attribute etc ...
using a new SAFI would be very hard to deploy as there would need to be
well defined behaviour of BGP speakers receiving duplicate information for
the same VPN prefixes or receiving at one time only from single SAFI then a
bit later from the other one .. Of course one solution is to permit only
one SAFI for a given service at any given time, but that seems way too
restrictive too.

So to summarize while I am personally a huge proponent of new SAFI and new
capabilities to be defines for new service here I do have  some
reservations. It seems to me that deployment of new transport for VPN
service should be either network management driven or enabled when all
participating PEs support it. Enabling it automagically with one hop
capabilities seems to me like not a good thing as the data being sent in
the UPDATES is not optional and dropping it means dropping actual routes.

So at the current time the subject draft took a management approach.

Many thx,
Robert.

On Thu, Feb 24, 2022 at 2:04 AM John Scudder <[e-mail]> wrote:

> Further to this point:
>
> > On Feb 18, 2022, at 3:32 PM, John Scudder <[e-mail]> wrote:
> >
> >> On Feb 17, 2022, at 3:19 AM, Ketan Talaulikar <[e-mail]>
> wrote:
> >>
> >>> 2. One area of concern I would have hoped IDR might have looked into
> is, the
> >>> document makes a creative use of the MPLS Label field of the NLRI to
> carry the
> >>> Function part of the SID. This means the SID is effectively split
> across the
> >>> NLRI and the Prefix-SID attribute. What are the potential error modes
> if the
> >>> Prefix-SID attribute should be lost from the route, while the NLRI is
> retained?
> >>>
> >>> (An obvious way of addressing this particular concern would be to
> define a new
> >>> NLRI type with the desired semantics, instead of creatively
> repurposing fields
> >>> within an existing NLRI type contrary to their definitions. Such an
> NLRI type
> >>> would, for example, presumably state in its specification that if it
> was
> >>> received without an accompanying Prefix-SID attribute, that would
> constitute an
> >>> error.)
> >>>
> >> KT> This document follows the approach similar as taken for extending
> MPLS EVPN RFC7432 by RFC8365.
> >
> > I take it you’re referring to RFC 8365 §5.1.3 which talks about using
> the MPLS Label field (or MPLS1 Label field) to carry the VNI in the
> presence of a BGP Encapsulation Extended Community? Yes, that seems like a
> pretty close analogue. And given this particular trick is only with
> VPN-type address families one can also argue that there’s not a risk of
> affected routes leaking into the big-I Internet, which is the typical
> associated concern.
>
> In a separate reply, the authors of
> draft-lz-bess-srv6-service-capability-02 pointed out that it provides a
> critique of bess-srv6-services which is similar to this discuss point. (The
> authors dropped the IESG from the cc, so I’m following up here instead of
> to their original note.)
>
> On first reading, the critique in draft-lz-bess-srv6-service-capability-02
> seems well argued and responsive to my question above about potential error
> modes. In section 3 of their draft, the authors provide a worked scenario
> where a VPN route carrying a SRv6 service SID using the Transposition
> scheme, if received by an MPLS-only PE, could result in misdelivered
> traffic. At minimum, that seems worth surfacing in the Security
> Considerations section, since historically we’ve considered misdelivered
> VPN traffic to be a Bad Thing that could expose confidential information.
>
> The authors do acknowledge that bess-srv6-services proposes a mitigation:
>
>    To avoid these problems, [I-D.ietf-bess-srv6-services] specifies that
>    implementations SHOULD provide a mechanism to control advertisement
>    of SRv6-based BGP service routes on a per neighbor and per service
>    basis.
>
> but they go on to argue that this mitigation isn’t fit for purpose:
>
>    The above method may be feasible in small-scale networks, but are not
>    applicable to large-scale networks.
>
>    [etc]
>
> It’s not my preference to get into the minutiae of this argument as part
> of this discuss. However, I’d like to ask: was this consideration something
> the WG discussed? I looked for discussion of
> draft-lz-bess-srv6-service-capability in the archives and didn’t find much —
>
> - When an earlier version was posted to the list it resulted only in
> discussion between the original author, Liu Yao, and Eduard Metz, who
> became co-author, but there wasn’t any discussion I saw of the actual issue
> that the draft identified, but rather refinement of the mitigation it
> proposes (which I don’t want to discuss in this note).
> - There was an agenda slot request for the draft at IETF-111. It was on
> the agenda in the “if time allows” section. I assume time did NOT allow
> because I don’t see mention of it in the minutes. (I did find the slides,
> slides 3 and 4 summarize the critique,
> https://datatracker.ietf.org/meeting/111/materials/slides-111-bess-sessa-srv6-service-capability-00
> ).
>
> But of course, the issue raised might have been discussed by the WG in a
> different thread, that doesn’t match a search for
> draft-lz-bess-srv6-service-capability. If so, I’d appreciate a pointer to
> it.
>
> If there wasn’t any discussion in the WG of the authors’ critique, I think
> it deserves to be discussed a bit as part of this thread. In particular,
> does the “this is the same as the trick EVPN does in RFC 8365” reply apply
> equally? Probably it does, although that might boil down to “gosh, we
> should have caught this when publishing 8365, shouldn’t we?”
>
> Even if the outcome of the discussion is that the limitation was discussed
> by the WG/isn’t a big deal because reasons/maybe it’s a big deal but we’ll
> fix it in a followup… as I mentioned earlier, covering it in the Security
> Considerations seems worthwhile.
>
> Thanks,
>
> —John