PCE%20Policy%20Architecture%20draft-ietf-pce-policy-enabled-path-comp-01.txt

1
PCE Policy Architecturedraft-ietf-pce-policy-ena
bled-path-comp-01.txt

• Igor Bryskin ltibryskin_at_advaoptical.comgt
• Dimitri Papadimitriou ltdimitri.papadimitriou_at_alcat
  el.begt
• Lou Berger ltlberger_at_labn.netgt
• Jerry Ash ltgash_at_att.comgt

2
Changes from previous version

• No significant technical changes
• Editorial changes
• Re-added figures lost in merge with
  draft-berger-pce-policy-architecture-00.txt
• Some other minor edits
• Updated references, boilerplate, etc.
• Added co-author
• Biggest change added scenario

3
Advanced Load Balancing Scenario

• IGP routing may direct all PE3/PE4/PE5 ingress
  traffic to egress PE2
• Example in IRSCP71.8 of multi-homed traffic
  goes to one link (complete imbalance)
• PCE policies could be configured such that
• traffic load monitored (e.g., based on Netflow
  data) at ingress routers PE3 ? PE7 towards data
  center prefixes served by egress routers PE1
  PE2
• PCE path computations balance traffic load, e.g.,
  PE4/PE5 to egress PE1, thus overriding default
  IGP based selection

AS 1
PE10
PE8
PE9
PE5

PE4
PE3
PE6
Customer Network

PE2
P1
P2
CE
PCE
P3
PE1
PE7
AS 0
PCEP
Physical link
4
Advanced Load Balancing Scenario

• Good example of how PCE policy can account for
  info not advertised as TE link/node attributes
• such info cannot be included in explicit path
  computation constraints
• such info can be pretty much anything (e.g.,
  traffic demand forecasts, flow monitoring
  feedback, any administrative policies, etc.)
• Further examples in IRSCP of how PCE policies
  might address certain network routing problems
• selective DDoS blackholing
• planned maintenance dryout
• VPN gateway selection.

5
Next Steps

• Additional feedback