IETF 80 minutes available

[Alia Atlas <[e-mail]>]

Thanks to Joel Halpern for taking minutes.

The minutes are below.

Alia

======================
Notes for RTGWG Session – Monday, March 28, 2011 1300 CEDT – Prague

Agenda Bashing & Current Draft Statuses  - Alia Atlas
   Announcement of note well.
   Review of status presented

LFA Applicability - draft-ietf-rtgwg-lfa-applicability - Clarence Filsfils
   Described differences in latest version –
	editorial nits and better explanation of failure effects.
	Added explanation of capacity planning with LFA.
   Document will go to WG last call after IETF.

Multicast Only Fast Reroute - draft-karan-mofrr - Clarence Filsfils
   Problem: fast recovery from network outages (<50ms).
   Aimed at being an easy solution for common cases; not applicable to
all cases.
   No planning for extra bandwidth; no IGP convergence dependency.
   Discussion of application to Two-Plane. Network designs.
   Q from John Scudder – Draft says intended status is informational.
Is that intended?  Author agrees to
accept chairs’ advice on intended status.
  Arun asks were the work belongs?  Here, PIM?  Clarence responds
suggesting that it belongs here since there
are no changes to the protocol changes to PIM.  Chairs agree to talk
to other chairs and ADs about the correct
location for the work.

Composite Link Framework - draft-so-yong-rtgwg-cl-framework-03 - Ning So
   Changes made to align with the requirements draft evolution.
   Signaling extensions to LDP support to address problems found by discussion
   Added section on Management plane impact
    John Scudder asked for objections, noting that given the
requirements work already done by the WG, this is
likely to be adopted as a working group document.
   Review of the scope of the protocol extensions needed to support
this work.  The presenter noted that there
are many small impacts on many protocols.

Composite Link Discussion
   Curtis Villamizer suggested taking an inventory of existing
mechanisms to address the needs.
   Lou Berger suggested that CCAMP will need to discuss the protocol
changes once there are actual drafts with
proposals.
   John Scudder pointed out that the common approach is to present
such material twice, once in RTGWG for the
collective work and once in the protocol WG.
   Acee Lindem agreeing that more information is needed before it can
be determined where to do the work.
   Agreement that Last call will probably need to be in multiple places.

OSPF TE Express Path - draft-giacalone-ospf-te-express-path - Spencer Giacolone
   Driven by a need for low latency, very high grade SLA, network
services.  Financial data networks, for
example.
   Traditional metric techniques are hard to use.
   Overview of solution: OSPF extensions to distribute performance information.
   The draft is aimed at TE, and aims at distributing average (steady
state) values.  Control plane specifics
to ensure stability are important but separate.
    Discussion of details of encoding.  Details of precision and
general issues of extensibility and
stability.
    Lou Berger raised another draft (delay-metric draft in ccamp)
sthat should be compared, and maybe combined
with this work.
   Wenhu Lu asked about how the information is used, in parciular
whether this is driven by client requests,

of more pushed from CSPF?  If pushed, how does CSPF know whom to notify.
   Alia Atlas compared this to link failure notifications.  Agreed
that triggering has to be relevant to

affected LSPs.

Fast Notification Framework - draft-lu-fast-notification-framework - Wenhu Lu
   Summary of changes presented.
   Text modified to clarify goals of work.
   Dicussion of open issues.

Transport of Fast Notification Messages - draft-lu-fn-transport-00 -
Jeff Tantsura
   Presentation of a generic mechanism to carry notifications needing
rapid dissemination.
   Description of necessary properties; using a pair of redundant
trees to meet goals.
   Two possible encapsulations mentioned.
   Description of authentication: per link or per area.

IP Fast-Reroute with Fast Notification - draft-csaszar-ipfrr-fn-00 -
Andras Csaszar
   Description of using fast notification to enable IP FRR with rapid
response and good coverage.
   NS-2 had something like this (simplified) many years ago.
   Walk through of the behavior and its results.  Including  issues
when only some nodes support the
capability.

   Stewart Bryant (also Channeling Mike Shand): How does this differ
from the earlier presented methods of
remote fast-reroute? A rough answer was provided.  Doesn’t the
presence of many legacy nodes cause serious
micro-loops?   Yes.  This assumes that most of the nodes have been
upgraded, and only a few are using old
behavior.  Debate of likely impact.   How does this scale in terms of
computation and FIB loading? Answer that
the authors have some computations in the drafts.

   Hannes finds the idea appealing, wonders whether this should
include support for ordered FIB update?

Andras responded that with the fast path forwarding, the micro-loop
issue is significantly decreased, so there
may not be need for ordered FIB.  Hannes pointed out the link up is
still uncovered.  (Mike Shand via Stewart)
comments that FIB update time is what drives the micro-loop FIB
ordering issues. Discussion ensued.

   Hannes asked about cancellation, for example with a micro-flap.

   General question raised / discussed as to whether this piece of the
puzzle (fast propagation of
notification) is important to solve?

   Definitional argument as to whether non-local repair can be local
fast re-route.  In particular, when the
speed of light delay across the area is longer than the target
response time, does this help?  Network
diameters in the range of 11 to 15 hops were in the data collected
earlier, and need to be handled.

   Eric Osborne asked if this could be handled more generally with an
OSPF fast flood LSA.

   John Scudder called for conversation on the mailing list, with the
hope of either adopting or dispensing
with this work by the next meeting.  He asked for an executive summary
to the mailing list.

New Protocol for on-demand dynamic route optimizations between tunnel
endpoints –
draft-templin-intarea-vet-24, section 5.14 – Fred Templin
   This is work based on Internet area tunnel work.
   When one has many devices using a tunneled infrastructure, one can
overload hub routers, or have very large
number of routing adjacencies which are hard to handle.
   Outline of a set of (10) requirements.
   ICMP Router Redirects address something similar, but has serious
drawbacks when checked against the
requirements.  So they have built a custom redirection solution: predirection.
   The proposal handles asymmetry and legacy easily.
   Fred is hoping that the draft he will be submitting will be
considered by the working group.
   Jeff asks about whether the NBMA can ensure transitive
reachability.  If the source being redirected can
not send packets directly to the target to which it is being directed,
how is this detected and coped with?
History tells us this happens.