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

[Martin Duke via Datatracker <[e-mail]>]

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.


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

(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]