Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

[Xiejingrong <[e-mail]>]

Fully understood, and -06 version is ok to me.
Thanks for Eric's patient explanation.
Thanks for Stephane also.
In MVPN using BIER Segmented Scenario, ABR needs Per-flow's VpnLabels to do further forwarding sticking, so that we can not use a SPMSI (*,*, PTA <type=BIER, flag=LIRpF, VpnLabel>, but SPMSIs(S,G,PTA<type=BIER, flag=LIR, VpnLabel>) will be good.

From: Eric C Rosen [mailto:[e-mail]]
Sent: Thursday, February 01, 2018 2:49 AM
To: Xiejingrong <[e-mail]>; [e-mail]
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

Thanks for delving into the details here.  This part of the writeup is very confusing (for which I have no one to blame but myself); I've tried to clarify in the -06 revision.

On 1/18/2018 9:51 PM, Xiejingrong wrote:

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.

The flags are required to be left untouched only if the PTA specifies "no tunnel info".


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>.

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" ?

EgressABR originates Leaf A-D routes of its own if and when it knows that it has downstream receivers that are interested in receiving flows from IngressPE.  It may originate more than one Leaf A-D route if LIR-pF is set in the S-PMSI A-D route's PTA.




Question clarification:

(1)     Should such LeafAD routes with type<16/17/18>RD be accepted and installed by EgressABR ?  This draft does not describe this.

If such routes carry EgressABR's import RT, and if their NLRIs match the NLRI of an S-PMSI A-D route installed by EgressABR, the Leaf A-D routes will be accepted and installed by EgressABR.  They are also relayed upstream (after changing the RT), as described in section 5.3.



(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.

(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.

Yes, PTA<type=noinfo, flag=LIR+LIR-pF> can be used if segmented tunnels are used, and will enable the ingress PE to discover the egress PEs.  However, there will not be a tunnel directly from the ingress PE to egress PEs that are on the other side of a segmentation boundary.

Draft-ietf-bier-mvpn states that, if segmented tunnels are used, LIR-pF should not be set in a PTA that specifies "BIER".  It doesn't say that the flag should not be set in a PTA that specifies "no tunnel info".

If you are using segmented BIER, the segmentation boundary router needs to change the BitString when a packet goes from one BIER domain to another.  This means that when the router receives a BIER packet, it needs to be able to infer, from the MPLS label following the BIER header, what the new BitString is.  The value of the new BitString depends on the flow being carried.  Since the labels are assigned by the S-PMSI A-D routes, the ingress needs to originate an S-PMSI A-D route for each flow.  Thus it can't really benefit from the LIR-pF technique when segmentation is used.  (On the other hand, segmented Ingress Replication could benefit from the LIR-pF technique, because in that case, the labels are assigned by the Leaf A-D routes.)





Thanks.
XieJingrong

From: Eric C Rosen [mailto:[e-mail]]
Sent: Thursday, January 18, 2018 11:49 PM
To: Xiejingrong <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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?