[spring] WG Adoption Call for draft-previdi-spring-problem-statement - section 5.1.1.2

[Yakov Rekhter <[e-mail]>]

Alvaro,

> Hi!
> 
> This message officially starts the call for adoption for
> draft-previdi-spring-problem-statement.
> 
> Please indicate your position about adopting this use cases draft
> by end-of-day on March 27, 2014.
> 
> Some additional background:  We had issued a call for adoption for
> draft-filsfils-rtgwg-segment-routing-use-cases-02 back in November.
> From both the discussion at the meeting in Vancouver and on the
> list, there was consensus to adopt.  The authors published
> draft-previdi-spring-problem-statement-00 as a revision to the
> original draft without the solution being present in the use case
> description.
> 
> http://tools.ietf.org/html/draft-previdi-spring-problem-statement
> 
> Thanks!

The following is a comment on section 5.1.1.2 of 
draft-previdi-spring-problem-statement-01

> 5.1.1.2.  Egress Peering Traffic Engineering
>                                      +------+
>                                      |      |
>                                  +---D      F
>                     +---------+ /    | AS 2 |\ +------+
>                     |         |/     +------+ \|   Z  |
>                     A         C                |      |
>                     |         |\     +------+ /| AS 4 |
>                     B   AS1   | \    |      |/ +------+
>                     |         |  +---E      G
>                     +---------+      | AS 3 |
>                                      +------+\
> 
>                Figure 3: Egress peering traffic engineering
> 
>    Let us assume, in the network depicted in Figure 3, that:
> 
>       C in AS1 learns about destination Z of AS 4 via two BGP paths
>       (AS2, AS4) and (AS3, AS4).
> 
>       C sets next-hop-self before propagating the paths within AS1.
> 
>       C propagates all the paths to Z within AS1 (add-path).
> 
>       C only installs the path via AS2 in its RIB.
> 
>    In that context, the operator of AS1 cannot apply the following
>    traffic-engineering policy:
> 
>       Steer 60% of the Z-destined traffic received at A via AS2 and 40%
>       via AS3.
> 
>       Steer 80% of the Z-destined traffic received at B via AS2 and 20%
>       via AS3.

Please note that the reason why "the operator AS1 can not apply"
the traffic-engineering policy listed above is due to the assumptions
made above.

To allow the operator of AS1 to apply the traffic-engineering policy
listed above, all you need is to revise the assumptions as follows:

   C in AS1 learns about destination Z of AS 4 via two BGP paths 
     (AS2, AS4) and (AS3, AS4) 

   C does not set next-hop-self before propagating the paths within 
     AS1 (next-hop is still D or E)

   C propagates all the paths to Z within AS1 (add-path).

   C originates into AS 1 BGP route to D with C as next-hop and label L1

   C originates into AS 1 BGP route to E with C as next-hop and label L2

   Both A and B have a hop-by-hop LSP to C (signaled with either LDP or 
     RSVP-TE); A uses label L-A-C, B uses label L-B-C

   No MPLS outside of AS1 is needed (no MPLS on C-D and C-E links)

With these assumptions the policy mentioned above is implemented as 
follows:

   Steer 60% of the Z-destined traffic received at A via AS2 and 
     40% via AS3:

      By A using label stack <L-A-C, L1> for 60% of the Z-destined traffic,
         and label stack <L-A-C, L2> for 40% of the Z-destined traffic

   Steer 80% of the Z-destined traffic received at B via AS2 and 
     20% via AS3:

      By B using label <L-B-C, L1> for 80% of the Z-destined traffic, 
         and label stack <L-B-C, L2> for 20% of the Z-destined traffic

With this in mind the authors of the draft should also document the 
revised assumptions, as well as the conclusion based on these
revised assumptions.

Yakov.