Hi Rajesh, My understanding is if you have END.REPLACE and END.REPLACEB6 for the option C case, then for option B you may also need two separate behaviors, one is END.DB6 which is for replacing the VPN SID and encapsulate an SRH, the other one is for replacing the VPN SID (by removing the outer IPv6 header and push a new IP header) and forwarding on the outgoing interface.
An alternative approach is to combine the behaviors for each option and just have END.REPLACEB for option C, and END.DB for option B. Whether it is bound to an explicit path or a loose path in that domain is a local decision within the domain. What do you think? Best regards, Jie > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rajesh M > Sent: Tuesday, November 16, 2021 7:41 PM > To: peng.sha...@zte.com.cn; mrajesh=40juniper....@dmarc.ietf.org > Cc: draft-salih-spring-srv6-inter-domain-s...@ietf.org; spring@ietf.org > Subject: Re: [spring] Questions about REPLACEB6 of > draft-salih-spring-srv6-inter-domain-sids > > Hi PSF, > > END.REPLACE and END.REPLACEB6 both are different forwarding behaviors. > > END.REPLACE is forwarding on outgoing interface (after replacing sid). > END.REPLACEB6 forwarding involves H.Encaps (after replacing sid). > > Next version of the draft we will come up with illustrations, that time your > query can be revisited. > > Thanks > Rajesh > > > > > Juniper Business Use Only > > -----Original Message----- > From: peng.sha...@zte.com.cn <peng.sha...@zte.com.cn> > Sent: Monday, November 15, 2021 2:46 PM > To: mrajesh=40juniper....@dmarc.ietf.org > Cc: draft-salih-spring-srv6-inter-domain-s...@ietf.org; spring@ietf.org > Subject: Re:[spring] Questions about REPLACEB6 of > draft-salih-spring-srv6-inter-domain-sids > > [External Email. Be cautious of content] > > > Hi Rajesh, > > The allocation of End.DT/DX SIDs are generally determined by the > configuration of allocation mode on egress PE, and are stable after > allocation, > i.e., without affection by the BGP next-hop resolve processing. And, the > forwarding behavior of END.DT/DX is also different, so that they must be > instantiated separately. > However, the difference between REPLACE and REPLACEB6 is negligible, they > are both SID swap behavior. Let me put it another way, would you plan to > define a new endpoint behavior for each case when the resolved outer tunnel > to BGP next-hop is SRv6 policy, or GRE, or MPLS, ... etc ? > > Regards, > PSF > > > ------------------原始邮件------------------ > 发件人：RajeshM > 收件人：彭少富 > 10053815;draft-salih-spring-srv6-inter-domain-s...@ietf.org; > 抄送人：spring@ietf.org; > 日 期 ：2021年11月15日 11:27 > 主 题 ：Re: [spring] Questions about REPLACEB6 of > draft-salih-spring-srv6-inter-domain-sids > Hi Peng, > Thanks for the draft acknowledgement. Regarding your question about > REPLACE/ REPLACEB6 Why we need DT4/DT6/DT46/ DX6/DX4 sids, they are > also " local behavior of the BGP egress speaker". > End.DX6 - Decapsulation and IPv6 Cross-Connect. > End.DX4: Decapsulation and IPv4 Cross-Connect > End.DT6: Decapsulation and Specific IPv6 Table Lookup > End.DT4: Decapsulation and Specific IPv4 Table Lookup > End.DT46: Decapsulation and Specific IP Table Lookup By having separate SID > at egress for each Endpoint Behavior, it will be well defined. > On similar lines we have well defined Endpoint Behavior REPLACE and > REPLACEB6 sids. Hope this clarifies. > Thanks > Rajesh > Juniper Business Use Only > -----Original Message----- > From: peng.sha...@zte.com.cn <peng.sha...@zte.com.cn> > Sent: Tuesday, November 9, 2021 9:02 AM > To: draft-salih-spring-srv6-inter-domain-s...@ietf.org > Cc: spring@ietf.org > Subject: Questions about REPLACEB6 of > draft-salih-spring-srv6-inter-domain-sids > [External Email. Be cautious of content] Hi authors, Thanks for bringing SRv6 > SID swaping idea in the distributed scenario. > I think there is valid case when the target prefix originated from remote > domain is invisible or unreachable to the intermediate nodes of the local > domain, and the intermediate nodes of the local domain have routes to the > REPLACE SID allocated by the border node of the local domain. > However, the question as I raised at the meeting, REPLACEB6 may be not > necessary, because it is the local behavior of the BGP speaker to swap a > single > SID or a segment list. > It may be not appropriate to advertise prefix with REPLACE behavior to the > upstream neighbor at time-1, and re-advertise the same prefix with > REPLACEB6 behavior at time-2 just because its forwarding information is > changed from a single outgoing SID to a SID list. Otherwise, it will cause > excessive advertisement overhead in the network. Just like MPLS BGP-LU, the > difference of a single outgoing label or an outgoing label stack at the local > node is not aware by upstream node. > There may be some reasons for re-advertisement, such as the need to > announce a new metric, but these reasons do not support the need for > REPLACEB6. > Regards, > PSF > _______________________________________________ > spring mailing list > spring@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring > __;!!NEt6yMaO-gk!Sy9uGv5WYV0OmIv_iwCVUsq5bMKtfiQcgsODoj2iLJB4LV- > ZlIPESg_GS_e5-_v1$ > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
