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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
