Hi, Please find below my understanding of the text.
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xiejingrong Sent: Friday, January 19, 2018 03:51 To: Eric C Rosen; bess@ietf.org Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03 Issue clarification: According to chap 5.2 of this document: In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a Wildcard S-PMSI(*,*) route with PTA(flag<LIR+LIR-pF>), whose NLRI is donated as SPMSI(type<0/1/2>RD,*,*,IngressPE). This SPMSI route will be relayed by EgressABR to EgressPE with PTA flag untouched. Then EgressPE will generate ONE LeafAD route with NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT<EgressABR>, and N(N>=0) LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR>. [SLI] Chap 5.2 does not deal with ASBR/ABR case, it defines the behavior of the egress node (the egress PE). Chap 5.3 does. Then according to chap 5.3 of this document: EgressABR will only send a Leaf A-D route. I guess, the said "a Leaf A-D route" should be the ONE of LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT<EgressABR>. Then how should EgressABR deal with the the N(N>=0) LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR> ? It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which only clarify LeafAD route with type<0/1/2>RD. Should such LeafAD route with type<16/17/18>RD be accepted and installed by EgressABR ? And then 'relay' back to IngressPE, and thus enable IngressPE explicit tracking inside the ingress "segmentation domain" ? Question clarification: (1) Should such LeafAD routes with type<16/17/18>RD be accepted and installed by EgressABR ? [SLI] If the egress node (EgressPE) originates Leaf A-D routes in a response to a LIR-pF, it uses the new RD types. As the SPMSI best route uses the ABR/ASBR address as a NH, the Leaf-AD route will use an ip-address based RT using the ABR/ASBR address as a base. When receiving the BGP Update containing the Leaf A-D, the ASBR/ABR will automatically import the route thanks to the RT. (2) If the said Leaf A-D routes (with RD type 16/17/18) be installed by EgressABR, then according to your answer, the Leaf A-D routes (with RT changed) will be 'relay' back to IngressPE. Right? This draft does not describe this either. [SLI] Yes the Leaf A-D route is forwarded and the RT is changed on the fly to the IngressPE address-specific RT. I think this does not change compared to the existing procedures from RFC6514. (3) If the above two are correct, then We can use PTA<type=NoTnlInfo, flag=LIR+LIRpF> in segmented P-tunnels scenario? But <draft-ietf-bier-mvpn-09> seems to imply that LIR-pF flag can't be used in Segmented P-tunnels scenario. Its chap 2.2.2 requires that, LIR-pF Flag is used only when non segmented P-tunnels are used. [SLI] As stated in the introduction, the goal here is to provide a cross-AS view rather than being stuck at the boundaries of the segmentation domain. Thanks. XieJingrong From: Eric C Rosen [mailto:ero...@juniper.net] Sent: Thursday, January 18, 2018 11:49 PM To: Xiejingrong <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03 I apologize for the delay in answering this message. On 12/21/2017 4:22 AM, Xiejingrong wrote: I have a comment on draft-ietf-bess-mvpn-expl-track-03. The chap 5.3 of this document said: Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-pF flags in the PTA MUST be passed along unchanged. This will ensure that an egress ABR/ASBR only sends a Leaf A-D route in response to a "match for tracking" if it is on the path to an egress PE for the flow(s) identified in the corresponding S-PMSI A-D route. The issue is as follow: In a [IngressPE--EgressABR--EgressPE] topology, IngressPE send a Wildcard S-PMSI(*,*) route with PTA(flag<LIR+LIR-pF>), whose NLRI is donated as SPMSI(type<0/1/2>RD,*,*,IngressPE). This SPMSI route will be relayed by EgressABR to EgressPE with PTA flag untouched. Then EgressPE will generate ONE LeafAD route with NLRI(type<0/1/2>RD,*,*,IngressPE,EgressPE) and RT<EgressABR> and N(N>=0) LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR>. All according to chap 5.2 of this document. Then according to chap 5.3 of this document: IngressABR will only send a Leaf A-D route, It should be the ONE of LeafAD(type<0/1/2RD,*,*,IngressPE,EgressABR) with RT<IngressABR>. In the example above, there is an "EgressABR" but not an "IngressABR". So I'm not completely sure that I understand your question. Then how should IngressABR deal with the the N(N>=0) LeafAD routes with NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR> ? It is not clarified in RFC7524 either. See chap 7.1 of RFC7524, which only clarify LeafAD route with type<0/1/2>RD. Should such LeafAD route with type<16/17/18>RD be accepted and installed by EgressABR, and then 'relay' back to IngressPE, and thus enable IngressPE explicit tracking inside the ingress "segmentation domain" ? The intention is the following. Suppose an egress ABR/ASBR satisfies the following two conditions: 1. It has installed an S-PMSI A-D route with the following properties: - its NLRI has wildcards for S and G, - its NLRI specifies PE1 as the ingress PE, - its PTA specifies "no tunnel info" and has LIR-pF set. 2. It has installed one or more Leaf A-D routes whose NLRI specifies (S,G) with PE1 as ingress PE Then the ABR/ASBR should originate a Leaf A-D route (with RD type 16/17/18) specifying (S,G) with ingress PE1. The Leaf A-D route would be withdrawn when one of these conditions no longer holds. Does this answer your question? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
