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

[Ketan Talaulikar <[e-mail]>]

Hi Martin,

Thanks for your review and your feedback/comments. We have posted an update
to address some of the comments and please also check inline below for
responses.

https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12

On Wed, Feb 23, 2022 at 7:02 AM Martin Duke via Datatracker <
[e-mail]> wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-bess-srv6-services-11: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (3.2.1)
> "BGP speakers that do not support this specification may misinterpret,
>    on the reception of an SRv6-based BGP service route update, the part
>    of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
>    for MPLS-based services.  Implementations supporting this
>    specification MUST provide a mechanism to control the advertisement
>    of SRv6-based BGP service routes on a per-neighbor and per-service
>    basis.  The details of deployment designs and implementation options
>    are outside the scope of this document."
>
> The idea that BGP hosts are going to be made non-interoperable because
> you're
> re-purposing the MPLS label, and so hosts are just going to have to
> remember
> who it's OK to exchange this TLV with, sounds unsatisfactory to me. Is
> there no
> way to negotiate this? Perhaps the solution John Scudder proposes in his
> second
> DISCUSS would solve this problem too: just have a new type for these
> overloaded
> MPLS labels.
>

KT> As explained on other threads, this mechanism/technique is not being
introduced for the first time in BGP. This is a well-known, implemented,
and well-deployed technique for BGP services for other encapsulations as
well. We've clarified and provided pointers in the updated version. Please
also see this discussion thread:
https://mailarchive.ietf.org/arch/msg/bess/SwXz7Ya0jyZ1g2TSf2ABsEoRz4g/


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This document was very difficult to follow without a thorough grounding in
> the
> references, but I managed to have some comments anyway:
>
> - I support John Scudder's second DISCUSS.
>
> - Please expand VRF, SLA, RIB, NLRI, and all other acronyms on first use.
>
> (3.2.1) "      The Transposition Offset MUST be less than LBL+LNL+FL+AL
>
>       The sum of Transposition Offset and Transposition Length MUST be
>       less than LBL+LNL+FL+AL"
>
> The second condition makes the first redundant for all Transposition
> Length >=
> 0! It makes me think there's a typo.
>

KT> Agree that the first condition is redundant and we've fixed this.


>
> (5) and (6) "The SRv6 Service SID SHOULD be routable within the AS of the
> egress
>    PE"
>
> SHOULD? Under what circumstances would it be OK for it not to be routable?
> [I
> see Alvaro also commented on this, but I'd like to call out that Sec 6
> does the
> same thing]
>

KT> We've added clarification with a reference to RFC8986 as to why it is
not necessary for all SRv6 SIDs to be routable.

Thanks,
Ketan