Hi authors,
The usecase proposed by the draft is useful and worth research. We review the
draft and find there may be some errors about the process description in Sec
5.3 and 5.4. Please refer to our attched detailed comments illustrated
(identified by "Comments Begin" and "Comments End"). The summary of the
comments is as follows:
-- Regarding Inter-AS Option-C using RFC 3107, it should advertise the label
stack in the ingress PE through BGP extensions instead of only the steering
label for EPE;
-- Regarding Inter-AS Option-B, if "next hop self" is not enabled in the ASBR
in the local AS, it should also advertise the label stack in the ingress PE
through BGP extensions instead of only the steering label for EPE;
We proposed more use cases which needs to advertise the label stack through BGP
extensions in the central control environment in
draft-li-spring-mpls-path-programming-00 and the corresponding BGP extensions
are proposed in the draft-li-idr-mpls-path-programming-00 to advertise the
label stack along with the advertised prefix. It is for your reference.
Besides above, Regarding "5.2. At a router - SR Traffic Engineering tunnel",
we think it is better that the steering label for EPE (e.g. 1042) should be
advertised through BGP extensions RFC 3107 instead of PCPE since the steering
service is per service instead of per tunnel and the process can be unified
with other process in Sec 5.3 and 5.4. That is, all of them are based on BGP
extensions to advertise the steering label with the prefix.
Regards,
Zhenbin(Robin)
Attached comments:
5.3. At a Router - BGP3107 policy route
The EPE Controller could build a BGP3107 ([RFC3107]) route (from
scratch) and send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g. L/8.
o Next-Hop: the selected egress border router: C.
o Label: the selected egress peer: 1042.
o AS path: reflecting the valid AS path of the selected.
o Some BGP policy to ensure it be selected as best by the ingress
router.
This BGP3107 policy route "overwrites" an equivalent or less-specific
"best path". As the best-path is changed, this EPE input policy
option influences the path propagated to the upstream peer/customers.
===Comments Begin===
Building BGP LSPs with reference to the "Reference Diagram" shown in
[I-D.filsfils-spring-segment-routing-central-epe]. The destination
prefix is L/8, the ingress router is A.
+---------+ +------+
| | | |
| H B------D G
| | +---/| AS 2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K
| | +===F AS 3 |
+---------+ +------+
For Inter-AS deploying scenario, the router K, F and C will use the
next-hop-self method to change itself as the Next-hop for the
destination prefix L/8.
The router K in AS 3 will change itself as the Next-hop and allocate
a new BGP label for the destination prefix L/8, then send it to the
router F, eg., using a new label: 5001
The router F in AS 3 will change itself as the Next-hop and allocate
a new BGP label for the destination prefix L/8, then send it to the
router C, eg., using a new label: 5002
The EPE Controller could build a BGP3107 ([RFC3107]) route (from
scratch) and send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g. L/8.
o Next-Hop: the selected egress border router: C.
o Labels(SHOULD be a label stack):
The first Label: the selected egress peer: 1042.
The second Label: the Label that the router F sends to the router
C: 5002
(A packet comes into the ingress router A, will push 3 labels:
Label of Node C's Segment, 1042, 5002; )
o AS path: reflecting the valid AS path of the selected.
o Some BGP policy to ensure it be selected as best by the ingress
router.
Packet Walkthrough:
1) A packet destinating to L/8 comes into the ingress router A;
2) The router A will PUSH 3 labels in turn: 5002, 1042, the label of
the Node Segment of C, then send the packet to the router C;
3) When the packet reaches the router C, the actions are carried out
by the router C: firstly, POPs the label of the Node Segment of C;
secondly, POPs the label 1042 and finds out the outgoing interface
to the router F in accordance with the label 1042;
4) When the packet reaches the router F, the router F will see the bgp
label 5002 and can SWAP the bgp label 5002 to the bgp label 5001,
then send the packet to the router K.
===Comments End===
5.4. At a Router - VPN policy route
The EPE Controller could build a VPNv4 route (from scratch) and send
it to the ingress router:
o NLRI: the destination prefix to engineer: e.g. L/8.
o Next-Hop: the selected egress border router: C.
o Label: the selected egress peer: 1042.
o Route-Target: selecting the appropriate VRF at the ingress router.
o AS path: reflecting the valid AS path of the selected.
o Some BGP policy to ensure it be selected as best by the ingress
router in the related VRF.
The related VRF must be pre-configured. A VRF fall-back into main
FIB might be beneficial to avoid replicating all the "normal"
internet paths in each VRF.
===Comments Begin===
Deploying Inter-AS L3VPN Option B Services with reference to the
"Reference Diagram" shown in
[I-D.filsfils-spring-segment-routing-central-epe].
PE1(A) ASBR1(B) ASBR3(D)
+---------+ +------+
| | | |
| H B------D G (PE2)
| | +---/| AS 2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K (PE3)
| | +===F AS 3 |
+---------+ +------+
ASBR2(C) ASBR4(E)
ASBR5(F)
For Inter-AS L3VPN Option B:
PE3(K) will allocate a VPN label (eg, 6001) for the destination prefix L/8,
and send it to the router F via a VPNv4 route;
ASBR5(F) and ASBR2(C) will establish an EBGP session and exchange
VPNv4 routes, eg. ASBR5(F) will allocate a new VPN Label (eg. 6002) for the
destination prefix L/8 and send it to ASBR2(C);
The EPE Controller could build a VPNv4 route (from scratch) and send
it to the ingress router:
o NLRI: the destination prefix to engineer: e.g. L/8.
o Next-Hop: the selected egress border router: C.
o Labels(SHOULD be a label stack):
The first Label: the selected egress peer: 1042.
The second Label: the VPN Label that the router F sends to the router
C: 6002
o Route-Target: selecting the appropriate VRF at the ingress router.
o AS path: reflecting the valid AS path of the selected.
o Some BGP policy to ensure it be selected as best by the ingress
router in the related VRF.
Packet Walkthrough:
1) A packet destinating to L/8 comes into the ingress router A;
2) The router A will PUSH 3 labels in turn: 6002, 1042, the label of
the Node Segment of C, then send the packet to the router C;
3) When the packet reaches the router C, the actions are carried out
by the router C: firstly, POPs the label of the Node Segment of C;
secondly, POPs the label 1042 and finds out the outgoing interface
to the router F in accordance with the label 1042;
4) When the packet reaches the router F, the router F will see the vpn
label 6002 and can SWAP the vpn label 6002 to the vpn label 6001,
then send the packet to the router K.
===Comments End===
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
