Hi Yubao, Your questions have nothing to do with the changes in the new version. Your question relates to aspects that have been clarified from a very early version of the document.
https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13#section-3.2.1 BGP speakers that do not support this specification may misinterpret, on the reception of an SRv6-based BGP service route update, the part of the SRv6 SID encoded in MPLS label field(s) as MPLS label values for MPLS-based services. Implementations supporting this specification MUST provide a mechanism to control the advertisement of SRv6-based BGP service routes on a per-neighbor and per-service basis. The details of deployment designs and implementation options are outside the scope of this document. Thanks, Ketan On Sun, Mar 20, 2022 at 12:18 PM <[email protected]> wrote: > > Hi Ketan, > > > Thanks for your clarification. It's very clear now in that update. > > After read the new version, now I have other questions: > > > When an ASBR receives a L3VPN route along with an implicit-null MPLS label, > > and that ASBR doesn't recognize the SRv6-specific TLVs, > > Is there a risk for that ASBR to re-allocate another non-reserved MPLS > label for that L3VPN route? > > > When a RR receives a MAC Advertisement Route whose MPLS label1 is > implicit-null, > > But it doesn't recognize the SRv6-specific TLVs, > > is there a risk for that RR considering that MAC Advertisement Route as > invalid? > > > > Thanks, > > Yubao > > > > 原始邮件 > *发件人：*KetanTalaulikar > *收件人：*王玉保10045807; > *抄送人：*[email protected];BESS; > *日 期 ：*2022年03月20日 11:35 > *主 题 ：**Re: [bess] [Idr] Review request for > draft-ietf-bess-srv6-services-11* > Hi Yubao, > Thanks for your feedback and we have clarified the use of the endpoint > behavior in the update posted earlier today to incorporate Alvaro's > suggestions. > > Thanks, > Ketan > > > On Mon, Mar 7, 2022 at 6:24 PM Ketan Talaulikar <[email protected]> > wrote: > >> Hi Yubao, >> Sec 6.1.1 (Ethernet per-AD ES route ) does talk about the usage of the >> End.DT2M behavior. It does not talk about making the route invalid if it is >> carrying some other behavior. >> >> That said, will discuss with my co-authors regarding making the text >> clearer and get back to you. >> >> Thanks, >> Ketan >> >> >> On Mon, Mar 7, 2022 at 1:03 PM <[email protected]> wrote: >> >>> >>> Hi Ketan， >>> >>> >>> Thanks for your reply, >>> >>> Please see inline below. >>> >>> >>> Thanks >>> >>> Yubao >>> >>> >>> >>> 原始邮件 >>> *发件人：*KetanTalaulikar >>> *收件人：*王玉保10045807; >>> *抄送人：*[email protected];BESS; >>> *日 期 ：*2022年03月04日 14:08 >>> *主 题 ：**Re: [bess] [Idr] Review request for >>> draft-ietf-bess-srv6-services-11* >>> Hi Yubao, >>> Thanks for your email. Please check inline below. >>> >>> >>> On Thu, Mar 3, 2022 at 8:20 AM <[email protected]> wrote: >>> >>>> >>>> Hi authors, >>>> >>>> >>>> >>>> I reviewed this draft and I don't understand this sentence very >>>> well: "The SRv6 Endpoint behavior of the Service SID thus signaled *is >>>> entirely up to the originator* of the advertisement" >>>> >>> >>> KT> Indeed. The egress PE is the one that picks the SRv6 SID to be >>> signaled with the specific route. >>> >>> >>> [Yubao 2] I mean the SRv6 Endpoint Behavior field of the SRv6 SID >>> Information Sub-TLV, I know the SID is picked by the originator, >>> >>> but I am not sure whether that behavior field should be >>> set to "End.DT2M" or not, >>> >>> and I am not sure whether it will be considered to be >>> invalid if that behavior field is set to other values. >>> >>>> >>>> Is it saying that when PE1 receives an Ethernet A-D per ES route >>>> whose SRv6 SID Information Sub-TLV's SRv6 Endpoint Behavior field is set >>>> to X （where X is not 0xFFFF), >>>> >>>> that Ethernet A-D per ES route should be indifferently processed by >>>> PE1 no matter what value will X be set to? >>>> >>> >>> KT> I am not sure of the draft text that you are referring to when >>> drawing up this inference. For SRv6 SID behaviors that use arguments (e.g. >>> Ethernet A-D per ES routes with behavior End.DT2M), it is necessary for the >>> ingress PE to not be indifferent to the behavior since it needs to put the >>> argument part correctly in the SRv6 SID used on the data path. >>> >>> >>> [Yubao 2] If the ingress PE receives an Ethernet A-D per ES route whose >>> SRv6 SID Information Sub-TLV's SRv6 Endpoint Behavior field is set to >>> 0x0508 (or any other unassigned values of RFC8986) >>> >>> But the IMET route it received carried a Behavior value >>> of 'End.DT2M', >>> >>> Will the ingress PE treat that Ethernet A-D per ES route >>> as an invalid route? >>> >>> >>> >>>> Is it necessary for the receiver-side processing of Ethernet A-D per >>>> ES route's Endpoint Behavior field to be clearly described? >>>> >>> >>> KT> Sec 6.3 is where the egress PE processing and use of the ARG >>> received via the Ethernet A-D per ES route with the SRv6 SID received along >>> with Route Type 3 is described. >>> >>> >>> [Yubao 2] I think section 6.3 mainly says that the behavior field of >>> IMET routes should be 'End.DT2M', >>> >>> but it is not clear whether the behavior field of >>> Ethernet A-D per ES route must be set to 'End.DT2M'. >>> >>> >>> Thanks, >>> Ketan >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yubao >>>> >>>> >>>> >>>> >>>> >>> >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
