Hi Jingrong, I have updated -02 version to fix a typo and some minor nits. Rest of comments are addressed in the latest version as mentioned by Swadesh as well. Cheers, Gaurav
On Mon, Jul 8, 2019 at 1:47 PM Swadesh Agrawal (swaagraw) < [email protected]> wrote: > Hi Jingrong > > > > Thanks for reviewing and comments. Please see my response inline starting > with [SA] . > > > > Regards > > Swadesh > > > > *From: *BESS <[email protected]> on behalf of Xiejingrong < > [email protected]> > *Date: *Thursday, June 27, 2019 at 7:51 PM > *To: *"[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *[bess] Comments on <draft-dawra-bess-srv6-services-00> > > > > 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. > > [SA] In future, new behaviors could be defined on Egress PE extension to > network programming. So we don’t want to restrict behaviors. > > > > 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. > > [SA] Based on IGP shortest path reachability. > > [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. > > [SA] hopefully above response clarifies. > > [xjr] s/RFC2460/RFC8200/g > > [SA] Ack. > > > > 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 > > [SA] fixed in new version. > > > > 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. > > [SA] Please refer to updated version which hopefully clarifies this > comment. Further there is a typing error in new version. Last line of > paragraph will be modified to below is next version. > > > > “second ,it indicates the value of the Service SID to be used in the > encapsulation.” > > > > 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. > > [SA] This is specific to EVPN RT 6,7,8 and not MVPN (RT 6 and 7). This may > be updated in future version of document based on future analysis. > > > > Thanks > > Jingrong > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
