Re: [spring] RTG-DIR review of draft-ietf-bess-srv6-services-05

[Alexander Vainshtein <[e-mail]>]

Adding RTG-DIR – my apologies

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Swadesh Agrawal (swaagraw) <[e-mail]>; Zafar Ali (zali) <[e-mail]>
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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


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.