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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
