Telechat Review of draft-ietf-bess-srv6-services-10
review-ietf-bess-srv6-services-10-intdir-telechat-bonica-2022-02-14-01

Request Review of draft-ietf-bess-srv6-services
Requested revision No specific revision (document currently at 15)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-02-13
Requested 2022-02-03
Requested by Éric Vyncke
Authors Gaurav Dawra , Ketan Talaulikar , Robert Raszuk , Bruno Decraene , Shunwan Zhuang , Jorge Rabadan
I-D last updated 2022-02-14
Completed reviews Rtgdir Last Call review of -05 by Sasha Vainshtein (diff)
Rtgdir Last Call review of -08 by Sasha Vainshtein (diff)
Secdir Last Call review of -08 by Joseph A. Salowey (diff)
Genart Last Call review of -08 by Roni Even (diff)
Intdir Telechat review of -10 by Ron Bonica (diff)
Assignment Reviewer Ron Bonica
State Completed
Request Telechat review on draft-ietf-bess-srv6-services by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/E8g11eJKR073E0ugGqlUsMtzsqk
Reviewed revision 10 (document currently at 15)
Result Not ready
Completed 2022-02-14
review-ietf-bess-srv6-services-10-intdir-telechat-bonica-2022-02-14-01
I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

2) In Section 3.2.1 the draft says:

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

s/BGP speakers that do not support this specification/Legacy BGP implementations

It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

3) I concur with Warren Kumari's DISCUSS