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://tools.ietf.org/html/rfc8277>]
with the Label Value set to the Function part of the SRv6 SID when
the Transposition Scheme of encoding (Section
4<https://tools.ietf.org/html/draft-ietf-bess-srv6-services-06#section-4>) 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:[email protected]]
From: Alexander Vainshtein <[email protected]>
Sent: Wednesday, March 10, 2021 4:15 PM
To: Ketan Talaulikar (ketant) <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
Swadesh Agrawal (swaagraw) <[email protected]>; Zafar Ali (zali)
<[email protected]>; [email protected]; <[email protected]> <[email protected]>
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: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
From: Ketan Talaulikar (ketant) <[email protected]<mailto:[email protected]>>
Sent: Wednesday, March 10, 2021 7:55 AM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
<[email protected]<mailto:[email protected]>>
<[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
Swadesh Agrawal (swaagraw) <[email protected]<mailto:[email protected]>>;
Zafar Ali (zali) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>>
Sent: 29 January 2021 16:20
To: [email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
Swadesh Agrawal (swaagraw) <[email protected]<mailto:[email protected]>>;
Zafar Ali (zali) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: RTG-DIR review of draft-ietf-bess-srv6-services-05
Adding RTG-DIR – my apologies
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
From: Alexander Vainshtein
Sent: Friday, January 29, 2021 12:46 PM
To: [email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
Swadesh Agrawal (swaagraw) <[email protected]<mailto:[email protected]>>;
Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
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:
* RFC 8754 defines the Segment Routing header (SRH) and its handling
* 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
1. 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:
* 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.
* 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.
* 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
* 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.
1. 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”.
* 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
* 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
* 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.
1. 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.
1. 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:
* 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.
* 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?
* 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.
1. The draft defines two schemes for encoding the actual service SID in the
labeled service routes:
* The entire SRv6 SID encoded in the BGP Prefix SID attribute combined
with Implicit NULL as the label in the NLRI of the route
* 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.
* Neither of these schemes is defined as MANDATORY, but the
Transposition Scheme is RECOMMENDED as providing more efficient packing
* 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.
* 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!
1. 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:
* 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.
* 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.
* 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.
1. 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: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
