[bess] Comments on <draft-dawra-bess-srv6-services-00>

[Xiejingrong <[e-mail]>]

Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service over IPv6 networks.
Here are some minor comments:

   SRv6 Service SID refers to an SRv6 SID that MAY be associated with
   one of the service specific behavior on the advertising Provider
   Edge(PE) router, such as (but not limited to), in the case of L3VPN
   service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a
   nexthop) functions
[xjr] what are the things "but not limited to" ? Please specify explicitly or delete the words in this paragraph and other places.

   To provide SRv6 service with best-effort connectivity, the egress PE
   signals an SRv6 Service SID with the BGP overlay service route.  The
   ingress PE encapsulates the payload in an outer IPv6 header where the
   destination address is the SRv6 Service SID provided by the egress
   PE.  The underlay between the PEs only need to support plain IPv6
   forwarding [RFC2460].
[xjr]"with best-effort connectivity" is not clear to me.
[xjr] I suggest a section can be added to say about "not using color and SRH", "using color and SRH" for easy-deployment and for path-optimization respectively.
[xjr] s/RFC2460/RFC8200/g

   To provide SRv6 service in conjunction with an underlay SLA from the
   ingress PE to the egress PE, the egress PE colors the overlay service
   route with a Color extended
   community[I-D.ietf-idr-segment-routing-te-policy].  The ingress PE
   encapsulates the payload packet in an outer IPv6 header with an SRH
   that contains the SR policy associated with the related SLA followed
   by the SRv6 Service SID associated with the route.  The underlay
   nodes whose SRv6 SID's are part of the SRH must support SRv6 data
   plane.
[xjr] see above suggestion.

SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to
      represent SRv6 SID Informaton Sub-TLV.
[xjr] s/Informaton/information/g

   Egress PEs which supports SRv6 based L3 services advertises overlay
   service prefixes along with a Service SID enclosed in a SRv6 L3
   Service TLV within the BGP SID attribute.  This TLV serves two
   purposes - first, it indicates that the egress PE is reachable via an
   SRv6 underlay and the BGP ingress PE receiving this route MAY choose
   to encapsulate or insert an SRv6 SRH; second ,it indicates the value
   of the SID to include in the SRH encapsulation.
[xjr] The two purposes I can see, the indication of the reachability to this PE, and the indication of a specific Service this SRv6 SID bound to.
[xjr] Use of SRH or not is determined by Color Extended Community, or more precisely, the SR-policy installed on Ingress Node, not this TLV.

4.6.  EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core
   These routes do not require the advertisement of SRv6 Service TLVs
   along with them.  Similar to EVPN Route Type 4, the BGP Nexthop is
   equal to the IPv6 address of egress PE.  More details may be added in
   future revisions of this document.
[xjr] is this determined that No SRv6 Service TLVs required ? the document <draft-xie-bier-ipv6-mvpn> had seen the use of SRv6 Service TLV in multicast VPN.
[xjr] Suggest to say simply this is outside of this document, which I think covers unicast service only, and helpful to advance.

Thanks
Jingrong