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

[Gyan Mishra <[e-mail]>]

Hi Ketan

I have been following this draft as it has progressed and had gone a long
ways and has matured.  Document is very well written.

A few comments on the draft.

Thank you

Section 2

Why is MVPN SAFI 129 RFC 6513 6514 out of scope for this document?

Just as we have BGP Prefix SID Attribute SRv6 L3 services TLV type 5 and
SRv6 L2 services type 6 could MVPN be encoded as type 7 maybe?

       SRv6 L3 Service TLV: This TLV encodes Service SID information for
      SRv6 based L3 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label when received with a Layer
      3 service route as defined in [RFC4364
<https://datatracker.ietf.org/doc/html/rfc4364>] [RFC4659
<https://datatracker.ietf.org/doc/html/rfc4659>] [RFC8950
<https://datatracker.ietf.org/doc/html/rfc8950>]

      [I-D.ietf-bess-evpn-prefix-advertisement
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-06#ref-I-D.ietf-bess-evpn-prefix-advertisement>].
Some behaviors which
      MAY be encoded, but not limited to, are End.DX4, End.DT4, End.DX6,
      End.DT6, etc.


Can we mention here that the 20 byte VPN label is encoded in function
field of SRv6 SID.  Above is L3 VPN label so should the L2 EVPN

draft be omitted as it’s mentioned below as well in reference to L2 service.


      SRv6 L2 Service TLV: This TLV encodes Service SID information for
      SRv6 based L2 services.  It corresponds to the equivalent
      functionality provided by an MPLS Label1 for EVPN Route-Types as
      defined in [RFC7432
<https://datatracker.ietf.org/doc/html/rfc7432>].  Some behaviors
which MAY be encoded, but
      not limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc.


Can we mention here that the 20 byte VPN label is encoded in function
field of SRv6 SID


Section 5


Would the VPN label be encoded in SRv6 SID in both Function / Arg and
not just Arg.  The VPN label is only 20 bytes and the

station ID is 64 bytes, however since the Func/Arg field is variable
length should we say Func/Arg to provide flexibility in the encoding.


Section 5.1
Section 5.1 can we mention RFC 5565 softwire mesh framework as it relates
to V4 over v6 core.

Rewrite:

The MP_REACH_NLRI AFI/SAFI 1/128 IPv4 NLRI over SRv6 core next hop is
encoded as defined in [RFC8950
<https://datatracker.ietf.org/doc/html/rfc8950>] as 24 or 48 byte IPv6
addresswith RD set to 0.


Section 5.3


Rewrite


The MP_REACH_NLRI AFI/SAFI 2/128 IPv6  NLRI over SRv6 core next hop
encoded asdefined in [RFC4659
<https://datatracker.ietf.org/doc/html/rfc4659>] as 24 or 48 byte
IPv6 address with RD set to 0.



Section 5.3
Rewrite

The MP_REACH_NLRI AFI/SAFI 1/4 BGP labeled unicast (4PE), IPv4 islands
over SRv6 core next hop is encoded as defined in [RFC8950
<https://datatracker.ietf.org/doc/html/rfc8950>] as 16 or 32 byte IPv6
address.


Section 5.4

Rewrite

The MP_REACH_NLRI AFI/SAFI 2/1 IPv6 NLRI over SRv6 core next hop is
encoded according to [RFC2545
<https://datatracker.ietf.org/doc/html/rfc2545>]



Kind Regards

Gyan


On Wed, Mar 10, 2021 at 11:04 AM Ketan Talaulikar (ketant) <ketant=
[e-mail]> wrote:

> Hi Sasha,
>
>
>
> Indeed your version is better and we’ll put that in on the next draft
> update.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* 10 March 2021 19:40
> *To:* 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: RTG-DIR review of draft-ietf-bess-srv6-services-05
>
>
>
> Ketan,
>
> From my POV an even better version would be “*Usage of multicast trees as
> P-tunnels is outside the scope of this document*”.
>
> But your proposed text is also OK with me.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Ketan Talaulikar (ketant) <[e-mail]>
> *Sent:* Wednesday, March 10, 2021 4:07 PM
> *To:* Alexander Vainshtein <[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: RTG-DIR review of draft-ietf-bess-srv6-services-05
>
>
>
> *NOTICE:* This email was received from an *EXTERNAL* sender.
>
>
>
> Hi Sasha,
>
>
>
> My apologies and I think I understand your point. Would the following text
> change convey the right meaning?
>
>
>
> s/ *The setup of multicast trees for use as P-tunnels is outside the
> scope of this document / The setup and usage of multicast trees as
> P-tunnels is outside the scope of this document*
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* 10 March 2021 16:15
> *To:* 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: 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]
>
>
>
> *From:* Ketan Talaulikar (ketant) <[e-mail]>
> *Sent:* Wednesday, March 10, 2021 7:55 AM
> *To:* Alexander Vainshtein <[e-mail]>; <
> [e-mail]> <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; Swadesh Agrawal (swaagraw) <[e-mail]>; Zafar
> Ali (zali) <[e-mail]>; [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://clicktime.symantec.com/3UsxW3phCpdUtwJLUsoiuXP6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-06>
>
>
>
> Please see inline below for individual responses.
>
>
>
> *From:* Alexander Vainshtein <[e-mail]>
> *Sent:* 29 January 2021 16:20
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; Swadesh Agrawal (swaagraw) <[e-mail]>; Zafar
> Ali (zali) <[e-mail]>; [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]
>
>
>
> *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
> <https://clicktime.symantec.com/3DNHqu2P3uB4FTvdUETxnRQ6H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir>
>
>
>
> 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://clicktime.symantec.com/3Muuyg43iWUsicfqWidGKhk6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-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:
>
>
>    1. RFC 8754 defines the Segment Routing header (SRH) and its handling
>       2. 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:
>
>
>    1. 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. *
>
>
>
>    1. 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.*
>
>
>
>    1. 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
>       2. 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”.
>
>
>    1. 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
>       2. 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
>
>    1. *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://clicktime.symantec.com/32TG19gUV4Lj31a5gjgAQYu6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-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*
>
> *[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:
>
>
>    1. 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.
>
>    1. 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://clicktime.symantec.com/a/1/biKp1AfoqwCVjtqxg5_vLdEMaWnvI4M-LJJtOF_BtLA=?d=GveeddDdNDsKHR-czb3Wltcci3Ee7a8MY3Vhln8iQrgFexk1L1augTK1ls8B3BDL5bP_EzXeteWybZLr99fehzgcX5ynSev6sool_xo1KVsd4RYsdlyoqeQ7bDwRziDkG3Ed4HWP-il5lzxmQqZK46RIp-Fw1tghrJcrgvGpRNsYvrSJB7JNnnuS3-oVARnTg-JeBNgiukrdul4BQO0hBszmhO1SCm9TJcgl34O-2OWt5jD6v4kyOnBKF2R35Q25T21RcJp28zIJPGY5M9cJdeahRwe5it29BQ_ipGOVfT9prRfz67VJ2D8471XyHhA3cZ9A2PFf9AqwEolwHDhY01XHc4IOUbc8a_9Dd7fCWG4Ygt2r8uME-Pv9kO3IxbhlcYNHHIlLL96J1at9Md_83GYTAJ28a5D7ze64nO23oPzGM8sMlN16KRoKz8i5CybmlVmZNYTwt6MoW0xPjAs4QE2Wpui3QvNtnIoBMOGe&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8986>
> does not define a suitable endpoint behavior. Did I miss something here?*
>
>
>
>    1. 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://clicktime.symantec.com/3SvJDuvNrUXrGUuf6hsEZn16H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-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*
>
> *[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:
>
>
>    1. The entire SRv6 SID encoded in the BGP Prefix SID attribute
>       combined with Implicit NULL as the label in the NLRI of the route
>       2. 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.
>       3. Neither of these schemes is defined as MANDATORY, but the
>       Transposition Scheme is RECOMMENDED as providing more efficient packing
>       4. 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.*
>
>
>
>    1. 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:
>
>
>    1. 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.*
>
>    1. 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.
>       2. 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: [phone]
>
> Cell:      [phone]
>
> Email:   [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.
>
>
> 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.
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD