Last Call Review of draft-ietf-bess-srv6-services-05
review-ietf-bess-srv6-services-05-rtgdir-lc-vainshtein-2021-01-29-00

Adding RTG-DIR – my apologies

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com

From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: rtg-ads@ietf.org
Cc: draft-ietf-bess-srv6-services.all@ietf.org; bess@ietf.org; spring@ietf.org;
Swadesh Agrawal (swaagraw) <swaagraw@cisco.com>; Zafar Ali (zali)
<zali@cisco.com> Subject: RTG-DIR review of draft-ietf-bess-srv6-services-05

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-bess-srv6-services-05
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 29-Jan-21
IETF LC End Date:  Not known
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved
before publication.

Comments:
The draft is well written and it was relatively easy to grasp the main idea
behind it. However, the draft has to be read in parallel with the SRv6 Network
Programming
draft<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-28>
due to a lot of references to specific SRv6 endpoint behaviors defined in this
draft.

From my POV the draft introduces a new approach to providing BGP-based services
over an IPv6-capable core that is quite different from the way such services
have been provided over IP/MPLS cores .  It would be nice  if the authors could
 present these differences in a more explicit way and clarify their impact on
such issues as inter-AS/inter-domain services, scalability etc. However this is
just a wish, not a concern.

I have presented my early comments to the authors and contributors to the
draft, and we have hold a series of productive  discussions that, from my POV,
resulted in reaching rough consensus regarding resolution of all the issues I
have raised.

I have included my understanding of the authors’ responses in the body of the
review (marked by italics), and will be waiting for the next revision of the
draft for addressing these comments along the agreed upon lines.

I would like express my gratitude to Gaurav, Swadesh and Zafar  for their
responsiveness and cooperation.

Major Issues: None found

Minor Issues:

1.       It is quite common to say that the SRv6 dataplane is defined by RFC
8754m and this common statement is repeated in the first line of the SRv6
Services draft. However. I am not sure whether  RFC 8754, by and of itself,  is
a sufficient reference for the SRv6 dataplane  for the purpose of this 
document. My doubts are based on the following:

a.       RFC 8754 defines the Segment Routing header (SRH) and its handling

b.       The draft explicitly states that best-effort BGP-based services over
an SRv6 domain can be provided without SRH – but they definitely would use the
SRv6 dataplane My guess is that the  primary reference for the SRv6 dataplane
for this draft is provided by the SRv6 Network Programming draft and augmented
by RFC 8754. This guess is aligned with the frequent references to the SRv6
Network Programming draft in the SRv6 Services draft. I defer to the ADs and
the leaders of the SPRING WG to decide how this issue should be resolved

2.       The draft explicitly states in Section 2 that it “extends the BGP
Prefix-SID attribute [RFC8669] to carry  SRv6 SIDs and associated information”.
However, the draft:

a.       Does not explicitly states that that  it also extends RFC 8669 by
allowing BGP Prefix SID to be used with new AFI/SAFI (VPN-v4, VPN-v6 and EVPN)
anywhere in the text (RFC 8669 is explicitly limited to IPv4/IPv6 Labeled
Unicast leaving usage of the BGP Prefix SID attribute with other AFI/SAFI out
of scope)

b.       Is not marked as updating RFC 8669 in the metadata

c.       To the. best of my understanding the authors do not object to 
explicitly clarifying that this draft extends RFC 8669 also by applying it to
new AFI/SAFI. I believe that it would be up to the Routing ADs to decide
whether draft should be marked as updating RFC 8669 in the metadata

d.       I also wonder whether this draft should not be considered as updating
RFC 4364 and RFC 4659 because it suggests carrying, in the Label field of the
NLRI of the routes defined in these documents, values that do not represent
MPLS labels (or represent special purpose values that are used in these
fields). The same applies to RFC 7432  - but to a lesser extent since this
document allows carrying VNI values as well as MPLS labels. I defer to the
Routing ADs to decide how this should be handled

3.       Section 3 states: “Implementations supporting this specification
SHOULD provide a mechanism to control advertisement of SRv6-based BGP service
routes on a per neighbor and per service basis”.

a.       The purpose of this recommendation is prevention of misinterpretation
by the BGP speakers that do not support the draft, of the label fields of the
service routes as referring to MPLS labels while in fact these fields carry
transposed parts of the SRv6 Service SIDs

b.       I would like to understand how advertisement of SRv6 Service routes to
non-compliant PEs by BGP Route Reflectors can be prevented if

                                                               i.      The 
                                                               clients of these
                                                               Route Reflectors
                                                               include both
                                                               compliant and
                                                               non-compliant PEs

                                                             ii.      The Route
                                                             Reflectors also do
                                                             not recognize BGP
                                                             Prefix SID

c.       The authors have agreed to clarify that the mechanisms for prevention
are implementation- and/or deployment-specific and  will provide an example of
a suitable BGP policy. From my POV this would be most useful

4.       I have not found any references to multicast in MPLS/BGP IP VPNs (RFC
6513) in the draft. Neither is the SR Replication Segment for Multi-point
Service Delivery
draft<https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment-03>
mentioned anywhere. It is not clear to me whether such services cannot be
supported over SRv6, or are left for future study. Clarifying this point would
be quite helpful IMHO. In our discussion the authors have stated that MVPN is
out of scope of the draft and would be covered by a different document

5.       It is my impression that delivery of BUM traffic over EVPN services as
defined in the draft is limited to ingress replication as the provider
tunneling technology:

a.       This impression is based on the following observations:

                                                               i.     
                                                               According to
                                                               Section 8.3.1.2 
                                                               of RFC 7432, in
                                                               the case of
                                                               provider
                                                               tunneling
                                                               technologies
                                                               that are
                                                               different from
                                                               ingress
                                                               replication, 
                                                               the ESI label is
                                                               upstream-assigned
                                                               by the
                                                               advertising PE
                                                               and has to be
                                                               interpreted by
                                                               the egress PEs
                                                               in the context
                                                               of the ingress
                                                               PE that, in its
                                                               turn, has to be
                                                               inferred from
                                                               the
                                                               identification
                                                               of the P2MP
                                                               tunnel over
                                                               which the packet
                                                               containing the
                                                               EVPN-encapsulated
                                                               BUM frame has
                                                               been received by
                                                               the egress PE

                                                             ii.      The
                                                             definition of the
                                                             End.DT2M behavior
                                                             in the SRv6
                                                             Network
                                                             Programming draft
                                                             requires
                                                             association of
                                                             specific outgoing
                                                             interfaces in the
                                                             L2 outgoing
                                                             interfaces of the
                                                             corresponding
                                                             table in the
                                                             egress PE with
                                                             specific Arg.FE2
                                                             values and
                                                             encoding these
                                                             values in the SRv6
                                                             SIDs associated
                                                             with this
                                                             behavior. Such
                                                             association
                                                             presumably does
                                                             not depend on
                                                             specific ingress
                                                             PEs

                                                           iii.      Neither
                                                           the SRv6 Network
                                                           Programming draft
                                                           for the SRv6
                                                           Services one provide
                                                           any details about
                                                           inferring the
                                                           context for the
                                                           upstream-assigned
                                                           ESI labels from the
                                                           received SRv6 SIDs.

b.       If my understanding is correct, such a limitation should be explicitly
stated in the draft. In our discussion the authors have stated that P2MP SRv6
trees is out of scope of the draft and would be covered by a different
document. It is my understanding that the authors would not object to such a
clarification

c.       When it comes to usage of ingress replication in EVPN, my guess (FIIW)
is that EVPN over SRv6 that uses ingress replication would be fully compatible
with the Assisted Ingress Replication scheme as described in the Optimized
Ingress Replication for
EVPN<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-optimized-ir-07>
draft. If this is indeed so, it would be useful if this fact were explicitly
mentioned in the draft (with an Informative reference to the Optimized Ingress
Replication draft). In our discussion the authors stated that the draft is
fully compatible with the Assisted replication scheme  just as any other
IP-based encapsulation

6.       The draft defines two schemes for encoding the actual service SID in
the labeled service routes:

a.       The entire SRv6 SID encoded in the BGP Prefix SID attribute combined
with Implicit NULL as the label in the NLRI of the route

b.       The Transposition Scheme: Only the locator part of the SRv6 SID
encoded in the BGP Prefix SID attribute while the function and arguments (if
any) are encoded as the label field of the NLRI.

c.       Neither of these schemes is defined as MANDATORY, but the
Transposition Scheme is RECOMMENDED as providing more efficient packing

d.       To the best of my understanding, the egress PE can use any of these
schemes at its discretion when it advertises the service routes. Is this
correct? If yes, does this mean that the ingress PE MUST support both schemes?
In our discussion the authors have confirmed that

e.       I have to admit that I do not fully understand why the Transposition
Scheme is more effective since eventually the same set of Service SIDs has to
be allocated and advertised by the egress PEs; but this is probably my personal
problem.

7.       The last para of Section 4 the draft (that discusses per Ethernet
Segment EVPN Auto-Discovery route), says that the “argument part of the SRv6
SID MAY be transposed in the ESI Label field of the ESI Label Extended
Community and the SID value in the SRv6 Services TLV is set to 0 with the SRv6
SID Structure Sub-Sub-TLV”. From my POV:

a.       There is no other place where this argument can be transposed –
because, as per RFC 7432, the Label filed of this route MUST be set to 0

b.       In the general situation (when the Egress PE is attached to multiple
multi-homed Ethernet Segments and contains multiple MAC-VRFs attached to these
segments) the Arg.FE2 value (that is assigned per ES and carried with the
per-ES Ethernet A-D route) MUST be combined with the Function part of the SRv6
Service SID (that is allocated per Bridge Table and advertised in the Inclusive
Multicast Ethernet Tag EVPN route) using the Transposition scheme.

c.       I also think that consistent usage of the Transposition Scheme (i.e.,
same offset and length) across multiple EVPN routes is required. It is my
understanding that the authors agree that consistent usage of the Transposition
Scheme across multiple ES and multiple EVI is expected

8.       Both the SRv6 Network Programming draft and the SRv6 Services draft
use notation Arg.FE2, but I have not found any definition of this notation.
According to the authors, these two drafts define this notation and no
additional definition is required, and agreed to state that explicitly in the
draft.

Nits:

1.       I did not run the nits check on the draft

2.       In the 3rd para of Section 1: s/one of the service specific behavior/
one of the service specific behaviors/

Hopefully these notes will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.