Routing Area WG (rtgwg)
IETF 84 - Vancouver

Scribes: Lucy Wong and Gunter Van de Velde




(1) Maximally Redundant Trees Update  by Alia Atlas
discussion is on the three drafts involved

MRT for IP/LDP Unicast Fast-Reroute is rather stable.
Plan for IGP extensions
  use flag to show MRT support - goal is to keep it simple

status:
 comparing various alternativs
 modeling is done
 comparing of the different models: MRT, Not-Via, optimal possible, Remote-LFA

preliminary analysis:
model1 is three rings interlocking between each other
each of the solutions are then analyzed

Model2 model is  dual shaped squared:
each of the solutions are then analysed
  
MRT for Mcast and Live-Live
Working on protocol drafts for the mechanism
improve live-live convergence methods




(2) Composite Link Framework and Use Cases by Ning So

3 related drafts
requirement draft was waiting for other two drafts
use-case draft and framework draft made working group draft

Framework draft
latest updated in June
Status is unchanged
Some text some text has been moved in location
proposed a set of components of a total solution

What has been added?
dynamic multipath balance
path symmetry
packet ordering
performance, scalability and stability
ip and ldp traffic

-> purpose is that each topic is looked into in greater depth

protocol focus:
link-grouping and advertisement
delay jitter and extensions
path selection and admission control
inter-layer communication

load balancing specifics:
dynamic multipath balance
frequency of balance
packet ordering requirements
minimal disruption load balance

IP and LDP and PW:
IP and LDP traffic
LDP extensions
pseudowires extensions

What is the goal:
eventually move towards defining protocols
propose a set of documents to cover groups for easier requirements
need to agree that the set of topics is ok... feedback requested

Next steps:
the WG draft will be updated after 84




(3) Framework and Requirements for Energy Aware Control Planes by Russ White

Goal:
catalog proposed solutions to reduce power
examine possible problems caused by various mechanisms
document issues in this space

Requirements:
energy efficiency and BW, stretch, fast recovery

2 examples were discussed

Question: What should be analyzed further?

Lucy@Huawei
Q: For what control plane would this work?  IP/MPLS/other?
Russ: for any but we need to be careful that we do not break things

Sue Harris@huawei
Q: What sort of networks are you looking into? plugged in or unplugged devices
Russ: looking into plugged-in networks
Sue:  IEEE works on wireless solutions
Acee: there are other related efforts
Alvaro:  Yes, we'll need to coordinate/cooperate.

John Parello@cisco
Q: there are many groups already working on energy efficient solutions regarding eman; what about sensor networks?
Russ: if it would become a working group item then we need to figure out how to best deal with this
Russ: the objective is to keep the requirements generic and not specific to any type of network

Bithika@extreme
Q: What about virtualization... how can you see what sort benefit you have?
Russ: virtualization is a business decision involving a lot of provisioning...will need to be taken into consideration



(4) Traffic Engineering: Requirements, Approaches, and Issues by Beichuan Zhang  

The problem:
Increased energy consumption

The opportunity:
tradeoff between redundancy and efficiency

Solution:
power aware router and traffic engineering
this document explains requirements, approaches and potential issues

Requirements:
goal is that resiliency is sufficient
there should be sufficient standby capacity
QoS metrics as delay, jitter, etc should be sufficient
the bringing down of links and and routers should not impact other protocols

sleeping vs. rate adaption
if you let the link to sleep then there is no connectivity, so that is particular important for control packets
rate adaption saves less energy but control packets get through

configured vs adaptive
either configure the state or do it based upon triggers

distributed vs centralized:
either by a central entity or by local entity

HW support:
the HW should support this
HW should support energy related measurement

sleeping links:
if link is asleep, then that will impact protocols
Is solution to modify the other protocols to support this?

Future work:
Better routing/TE algorithms
standardization: support power aware features.

Discussion:
Gunter@cisco: 
Q: Resiliency is one thing, but what about convergence speed?
Beichuan: Yes that should be looked into

Acee Lindem@Ericsson
Q: how much would this save? and what if you have device far away and you drop your link?
Beichuan: That should be avoided
Alvaro:  The savings will depend on the use of the solution: whether it is adaptive or implemented using a profile. How much will it save depends on network complexity.
Beichuan: 50~30min change. 40% saving, depending on traffic

micro (??):
Statement: to bring down a part of a building to save energy is a good thing.. interesting work

Rolf:
Statement: go to energy bof and mention the things that you think should further looked in there

Rob Evans:
Q How do you check that a sleeping link is not broken?
Beichuan: yes, link may fail during sleeping, this is a problem...maybe with detour check