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

From: Eric C Rosen <[email-masked]>
Date: Thu, 18 Jan 2018 10:49:00 -0500

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?

---

From: Xiejingrong <[email-masked]>
Date: Fri, 19 Jan 2018 02:51:06 +0000

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

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 ?  This draft does not describe this.

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

Thanks.
XieJingrong

From: Eric C Rosen [mailto:[email-masked]]
Sent: Thursday, January 18, 2018 11:49 PM
To: Xiejingrong <[email-masked]>; [email-masked]
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

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:

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.

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 07:45:08 +0000

Hi,

Please find below my understanding of the text.

From: BESS [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Friday, January 19, 2018 03:51
To: Eric C Rosen; [email-masked]
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

Issue clarification:

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

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.

[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:[email-masked]]
Sent: Thursday, January 18, 2018 11:49 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03

The issue is as follow:

_________________________________________________________________________________________________________________________

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.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 31 Jan 2018 13:49:25 -0500

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:
> donated as  SPMSI(type<0/1/2>RD,*,*,IngressPE).
>

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 
> NLRI(type<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR>.
>
> 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> ?
>
> 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:[email-masked]]
> *Sent:* Thursday, January 18, 2018 11:49 PM
> *To:* Xiejingrong <[email-masked]>; [email-masked]
> *Subject:* Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03
>
>     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<16/17/18>RD,S,G,IngressPE,EgressPE) and RT<EgressABR>.
>     All according to chap 5.2 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.
>
>
>     It is not clarified in RFC7524 either. See chap 7.1 of RFC7524,
>     which only clarify LeafAD route with type<0/1/2>RD.
>
>     installed by EgressABR, and then ‘relay’ back to IngressPE, and
>     thus enable IngressPE explicit tracking inside the ingress
>     “segmentation domain” ?
>
>