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:ero...@juniper.net]
*Sent:* Thursday, January 18, 2018 11:49 PM
*To:* Xiejingrong <xiejingr...@huawei.com>; 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?
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
