Subject: [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02

From: Lizhenbin <[email-masked]>
Date: Mon, 21 Jul 2014 01:10:31 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Jul 2014 09:20:56 +0200

​Hi Robin,​

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

​Not quite right. Router F is not a MPLS router. It just uses plain
IPv4/IPv6 forwarding. Please read this in the draft:

"o  The solution MUST apply to the Internet use-case where the Internet
routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.​"

​The entire EPE solution as described in the draft is contained to AS1. AS
2..4 are for illustration of the bigger picture only.

- - -

===Comments Begin===
> Deploying Inter-AS L3VPN Option B Services with reference to the

​Let me clarify that the EPE draft does not talk about VPN service.

It only uses L3VPN VPN mechanism within AS1 to distribute EPE
​instrumentation data perhaps "VPN policy route" is a bit misleading term.
It really means that SAFI 128 is used for EPE steering labels distribution.
It is still only IPv4/IPv6 Internet service.

Said this your suggestion of using EPE within VPN service and specifically
at EPE enhanced option B peering is valid.

However if you would like to focus on using EPE for VPN service it seems
that new separate proposal may be required. There is few issues associated
with this unique to such use case.

It can very well serve as parallel draft to Internet EPE use case.

Thx,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 21 Jul 2014 15:37:10 +0200

hi robert,

why does it matter wether router 'F' is MPLS enabled or not ?
IMO all that is required is that router 'C' 'generates'
a labeled route for router 'F' (NH: router C) as soon as the
BGP session between C and F comes up. -

i.e. just local router C implementation -
no new protocol extensions required for making this work at all.

tx,

/hannes

On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote:
|    *Hi Robin,*
| 
|         +---------+      +------+
|         |         |      |      |
|         |    H    B------D      G
|         |         | +---/| AS 2 |\  +------+
|         |         |/     +------+ \ |      |---L/8
|         A   AS1   C---+            \|      |
|         |         |\\  \  +------+ /| AS 4 |---M/8
|         |         | \\  +-E      |/ +------+
|         |    X    |  \\   |      K
|         |         |   +===F AS 3 |
|         +---------+       +------+
| 
|      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
| 
|    *Not quite right. Router F is not a MPLS router. It just uses plain
|    IPv4/IPv6 forwarding. Please read this in the draft:
|    "o  The solution MUST apply to the Internet use-case where the Internet
|    routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*"
|    *The entire EPE solution as described in the draft is contained to AS1. AS
|    2..4 are for illustration of the bigger picture only. 
|    - - - 
| 
|      ===Comments Begin===
|      Deploying Inter-AS L3VPN Option B Services with reference to the
| 
|    *Let me clarify that the EPE draft does not talk about VPN service. 
|    It only uses L3VPN VPN mechanism within AS1 to distribute EPE
|    *instrumentation data perhaps "VPN policy route" is a bit misleading term.
|    It really means that SAFI 128 is used for EPE steering labels
|    distribution. It is still only IPv4/IPv6 Internet service. 
|    Said this your suggestion of using EPE within VPN service and specifically
|    at EPE enhanced option B peering is valid. 
|    However if you would like to focus on using EPE for VPN service it seems
|    that new separate proposal may be required. There is few issues associated
|    with this unique to such use case. 
|    It can very well serve as parallel draft to Internet EPE use case.
|    Thx,
|    R.

| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Jul 2014 17:17:10 +0200

Hi Hannes,

> why does it matter wether router 'F' is MPLS enabled or not ?

​It does not. Where did I say it matters for EPE ?

However it matters for what Robin is suggesting as his entire suggestion is
to carry F's label ​from AS1 controller to ingress points.

> BGP session between C and F comes up. -

​That's true. ​Modulo the option B case Robin has suggested in his second
part. While that may also not need protocol extension how you signal this
around depends on your choice of signalling channel between controller and
ingress points.

Best,
r.