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

[Manomugdha Biswas <[e-mail]>]

Thanks Jorge,
So answer to the question 1 below is that theoretically any device should accept the BGP update with TO 112, TL 8 even though locator length is 96, FUNC length is 20. Implementation may vary device to device.

Regards,
Mano
[cid:image002.png@01D715D1.2E6F1920]

From: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Sent: Wednesday, March 10, 2021 5:06 PM
To: Manomugdha Biswas <[e-mail]>; Alexander Vainshtein <[e-mail]>; Ketan Talaulikar (ketant) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Swadesh Agrawal (swaagraw) <[e-mail]>; Zafar Ali (zali) <[e-mail]>; [e-mail]; <[e-mail]> <[e-mail]>
Subject: Re: [spring] RTG-DIR review of draft-ietf-bess-srv6-services-05


CAUTION: This message originates from an external sender.
Hi Biswas,

“now say variable part starts at 112 (transposition offset), transposition length is 8 and locator length is 96 (FUNC+ARG length is 20). According to section 4 we should transpose 8 bits from offset 112 to label field in mp_reach_nlri.
But section 5.1 says that we should transpose FUNC part i.e. we should transpose from offset 96 with transposition length 20.”

As section 3.2.1 says, the limit of the transposition length (TL) is 20 bits for IPVPN and 24 bits for EVPN, but that does not mean that your TL is always 20 for IPVPN. In theory it may be any value between 0 and 20 (for IPVPN) and between 0 and 24 for EVPN.

Thanks.
Jorge


From: Manomugdha Biswas <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 10, 2021 at 11:49 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>, Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Swadesh Agrawal (swaagraw) <[e-mail]<mailto:[e-mail]>>, Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Subject: RE: [spring] RTG-DIR review of draft-ietf-bess-srv6-services-05

Hi Ketan,
According to section “4.  Encoding SRv6 SID information" for efficient encoding, variable part of SRv6 SID is transposed to label field. This draft has given an example of variable part as FUNC+ARG.

Section “5.1.  IPv4 VPN Over SRv6 Core" says that

        Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8277__;!!I5pVk4LIGAfnvw!znWscutIzlofFviFfmiB0LJR882lRGjijGmUryf-w9UGAeLic2dGM2xSO-RiStGdYEzLPYfc$>]

   with the Label Value set to the Function part of the SRv6 SID when

   the Transposition Scheme of encoding (Section 4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-srv6-services-06*section-4__;Iw!!I5pVk4LIGAfnvw!znWscutIzlofFviFfmiB0LJR882lRGjijGmUryf-w9UGAeLic2dGM2xSO-RiStGdYP1kT8LJ$>) is used and

   otherwise set to Implicit NULL.

now say variable part starts at 112 (transposition offset), transposition length is 8 and locator length is 96 (FUNC+ARG length is 20). According to section 4 we should transpose 8 bits from offset 112 to label field in mp_reach_nlri.
But section 5.1 says that we should transpose FUNC part i.e. we should transpose from offset 96 with transposition length 20.
Questions:

1.      In this scenario, if we transpose from offset 112 with transposition length 8 then is it error? Is it must to extend/match variable part to FUNC_ARG length starting from locator offset?

2.      If transposition offset and transposition length do not overlap with locator length and FUNC+ARG length then should we discard transposition?


Regards,
Mano
[cid:image003.png@01D715D1.2E6F1920]

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 10, 2021 4:15 PM
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Swadesh Agrawal (swaagraw) <[e-mail]<mailto:[e-mail]>>; Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] RTG-DIR review of draft-ietf-bess-srv6-services-05

Ketan,
Lots of thanks for posting an updated version of the draft.

I have looked it up, and it seems that the majority of my review comments have been addressed.

I defer to the Routing ADs regarding my metadata comments.

One point that, IMHO, requires additional clarification, is restriction of EVPN to just ingress replication for delivery of BUM traffic.
As I see it, stating that “The setup of multicast trees for use as P-tunnels is outside the scope of this document”   does not fully address this issue because, to the best of my understanding, RFC 8986 does not define any endpoint behavior that could be used for delivery of EVPN BUM traffic via P2MP trees even if such were supported (seems pretty evident if aggregate multicast trees are used, but even non-aggregate multicast trees are not covered IMHO).

Please see also more comments to your responses inline below.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 10, 2021 7:55 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Swadesh Agrawal (swaagraw) <[e-mail]<mailto:[e-mail]>>; Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

NOTICE: This email was received from an EXTERNAL sender.

Hi Sasha,

Thanks a lot for your detailed review, your comments/feedback and for taking time for discussions with the co-authors for their resolution.

We’ve just posted an update of the draft to address your comments based on our discussions :


https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06<https://urldefense.com/v3/__https:/clicktime.symantec.com/3UsxW3phCpdUtwJLUsoiuXP6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-bess-srv6-services-06__;JSUlJSUl!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMhVNtB9x$>

Please see inline below for individual responses.

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Sent: 29 January 2021 16:20
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Swadesh Agrawal (swaagraw) <[e-mail]<mailto:[e-mail]>>; Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05

Adding RTG-DIR – my apologies

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Swadesh Agrawal (swaagraw) <[e-mail]<mailto:[e-mail]>>; Zafar Ali (zali) <[e-mail]<mailto:[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<https://urldefense.com/v3/__https:/clicktime.symantec.com/3DNHqu2P3uB4FTvdUETxnRQ6H2?u=http*3A*2F*2Ftrac.tools.ietf.org*2Farea*2Frtg*2Ftrac*2Fwiki*2FRtgDir__;JSUlJSUlJSU!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMsQ6ru0d$>

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://urldefense.com/v3/__https:/clicktime.symantec.com/3Muuyg43iWUsicfqWidGKhk6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-spring-srv6-network-programming-28__;JSUlJSUl!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMqUgrMGX$> 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
[KT] RFC8754 does indeed define the SRH and hence specifies the SRv6 data plane in conjunction with RFC8402. Even when SRH is not used (refer RFC 8754 Sec 4.1.1 and RFC 8986 Sec 5.1 & 5.2), the processing follows RFC 8754 and RFC 8986 since the IPv6 DA in the packet is set to the specific SRv6 SID. Hence, the references to these two specifications in addition to RFC8402.

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.
[KT] Your understanding is correct here as clarified in the previous response and we have updated the text to better reflect the use of SRv6 Service SID alone for best effort and then the use of SRH as well.
[[Sasha]] The new version refers to RFC 8402 for the definition of SRv6, which is OK with me.

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)
[KT] Agree – we have clarified this in the text.[[Sasha]] Yes, lots of thanks.

b.      Is not marked as updating RFC 8669 in the metadata
[KT] I am not sure this is necessary since it does not really “update” the processing or handling of the feature specified in RFC8669 – this draft just re-uses the attribute introduced there.[[Sasha]] I defer to the ADs to decide whether such marking is or is not required.

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
[KT] Let us take an example, RFC8365 introduced new dataplane support for EVPN (RFC7432) using VXLAN (and others) but allowing VNI to be carried in the MPLS label fields of RFC7432. However, RFC8365 does not update RFC7432. We have a similar case, where a new dataplane (feature) is being specified for use with existing BGP services.[[Sasha]] Same as above.

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
[KT] As discussed, there are different approaches and mechanisms possible for BGP policy that are deployment design specific and better covered in a separate document. We have clarified this in the text.
[[Sasha]] The new text simply leaves the solution out of scope. If a non-normative example could be added, it would be nice IMHO.

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://urldefense.com/v3/__https:/clicktime.symantec.com/32TG19gUV4Lj31a5gjgAQYu6H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-spring-sr-replication-segment-03__;JSUlJSUl!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMixdZefu$> 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
[KT] You are correct; MVPN and P2MP SRv6 are going to be covered in separate documents. We have clarified this in the text.[[Sasha]] The new text is OK.

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
[KT] The draft does have the following text at the end of Sec 6.3 – “The setup of multicast trees for use as P-tunnels is outside the scope of this document.”
[[Sasha]] I still think that an explicit statement that the draft is limited to ingress replication for EVPN is required because, to the best of my understanding, RFC 8986<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8986__;!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMpyHVQZq$> does not define a suitable endpoint behavior. Did I miss something here?

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://urldefense.com/v3/__https:/clicktime.symantec.com/3SvJDuvNrUXrGUuf6hsEZn16H2?u=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-bess-evpn-optimized-ir-07__;JSUlJSUl!!I5pVk4LIGAfnvw!yf6kwu6swzxgSJHNyqUX2VUUrapcjyNhqIVtDhujD-1XQpAAN6anI9dVjdLIGCNFMgxBNOgh$> 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
[KT] You are correct about the applicability of that draft to SRv6 based BGP services. There are other EVPN extensions/procedures which also apply and it may be misleading to include and discuss one of them and not cover the others.[[Sasha]] Well, I can live with that.

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
[KT] This is correct.

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.
[KT] The efficiency is not in the context of Service SID allocation, but in the packing efficiency of the BGP updates.[[Sasha]] Got it now, thanks a lot!

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
[KT] Correct.
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
[KT] This is also correct. The procedure is explained in Sec 6.3.
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.
[KT] The definition of this notation is indeed in RFC8986 Sec 4.12 and this draft specifies how it is advertised via BGP. We have clarified this in the text.[[Sasha]]  Yes, OK with me.


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/
[KT] Ack for both.

Thanks,
Ketan (on behalf of co-authors)


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.

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.