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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess