Routing Area Working Group, March 2009 IETF Meeting, San Francisco
> CHAIR: Alex Zinin
>
> =====
>
> *  Administrivia - Chair
>    (5 minutes)
>
> * Changes to loopfree framework  - Stewart Bryant (5 minutes)
>   
> http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lf-conv-frmwk-04.
> txt
>
> Stewart report on the changes performed after last call:
> - IP Fast Reroute Framework (v04): clarify that µloops are not always 
> a problem
> - A Framework for Loop-free Convergence (v10): more changes: added new 
> loop mitigation strategies and in the cases LF not necessarily needed
> - NotVia document did not progress
> - Alex asks about implementation status before moving to std level.  
> Stewart states that no implementation exist.
> - Alex asks for comments on FRR and LFC framework and NotVia on the 
> mailing list.
>
> * Changes to draft-so-young-mpls-ctg-framework-requirement-01.txt  - 
> Ning So (15 minutes)
>   
> http://tools.ietf.org/html/draft-so-yong-mpls-ctg-framework-requiremen
> t-01
>
> Presentation slides: re-outline requirements, difference between v00 
> and v01, ask for WG doc.
>
> Discussions:
> Q: In case of local restoration, if LSP is protected, what is the 
> requirement ?
> A: Generic req. doc. Each component support OAM. In case of failure 
> re-routing expected (how to perform re-routing open issue)
> Q: No requirement for inter-working with FRR
> A: Requirement not present in the current document Q (Tony): Impact on 
> routing architecture ? network layer ?
> A: Intended to resolve problems related to bundling and link 
> aggregation
> (A.Malis): Document presented at different places incl. Softwire WG.  
> This work spans the scope of WG such as MPLS, etc.
> Q (Alex): Is there any solution document planned ?
> A (A.Malis): Solution is under discussion but need first agreement on 
> requirement before discussing solutions Q (Alex): Question about the 
> local behavior of the router (tackle link local problems so that they 
> do not affect the network) A (A.Malis): Idea is to locally sync. 
> bundle components
>
> Alex: AD comment concerning the document
> Malis: We talk to vendors to prevent breaking existing behavior
> Lou: We are jumping ahead. Lou asks for clear statements on 
> requirements without a particular solution in mind
>
> Alex: Who read the doc ? ~22
>
> Alex: Who agrees with the requirements ? almost majority of 22 people 
> (this shall be clarified on the list). It seems this doc. may be a 
> good starting point to initiate req. work. After we might look in the 
> solution space together with possible implementations.
>
> * Discussion of FIB reduction approach called Virtual Aggregation  - 
> Xiaohu Xu (30 minutes)
>   http://tools.ietf.org/html/draft-francis-intra-va-00
>   http://tools.ietf.org/html/draft-xu-tunnel-00
>
> Presentation slides (almost tutorial)
>
> Discussion: mainly clarification question on how VA and VP operates.  
> The basic concept is to inject an intra-AS (so invisible to other
> AS) "virtual" super-prefix (this term is misleading cf. also G.Swallow 
> as installed into the actual FIB) such as to reduce number of FIB 
> entries at the expense of increasing stretch - routing information 
> exchanges remains unchanged (no RIB entries reduction) in combination 
> with tunnels to ensure that prefixes are reachable via edge routers 
> connected to external peers (these tunnels can be MPLS, GRE tunnels). 
> Specific routers know routes for "sub-prefixes"
> within specific VPs at "Aggregation Points" (AP) whereas other routers 
> do not require those sub-prefixes. The main open issue is the ratio 
> between path length increase vs FIB entries reduction
> (performance) in addition to the issue resulting from static selection 
> of AP per selected VP (robustness to AP failure/network dynamics).
>
> Alex: advise to continue discussion on the list as this proposal 
> results in lots of changes in FIB and FIB<->RIB and AS operation
> Dave: not chartered. Possibility to use RTGWG as discussion forum.  
> Other possibility GROW
> Alex: propose a specific list to discuss this topic
> Ross: need to pick-up a single place but GROW is not in the routing 
> area
> Alex: will post an e-mail where the forum for discussion will happen
> Dave: movig between WG groups because people do not want this proposal 
> as WG doc anywhere