[Idr] IDR WG minutes

Yakov Rekhter <yakov@juniper.net> Mon, 26 March 2007 16:13 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVrod-0005PZ-Rz; Mon, 26 Mar 2007 12:13:03 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVroc-0005PU-Kt for idr@ietf.org; Mon, 26 Mar 2007 12:13:02 -0400
Received: from borg.juniper.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVrob-00089i-3a for idr@ietf.org; Mon, 26 Mar 2007 12:13:02 -0400
Received: from unknown (HELO merlot.juniper.net) ([]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 26 Mar 2007 09:12:56 -0700
X-IronPort-AV: i="4.14,330,1170662400"; d="scan'208"; a="696978428:sNHT35864108"
Received: from juniper.net (sapphire.juniper.net []) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2QGCuJ10341 for <idr@ietf.org>; Mon, 26 Mar 2007 09:12:56 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200703261612.l2QGCuJ10341@merlot.juniper.net>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <44256.1174925576.1@juniper.net>
Date: Mon, 26 Mar 2007 09:12:56 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Subject: [Idr] IDR WG minutes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


Please review the minutes for correctness. The deadline for
comments is April 8.

IDR WG minutes
IETF-68 Prague
March 21 2007 0900

1. Document status report (Yakov)

Lots of progress in publishing docs as RFCs -- many published, many  
more in queue, see slides.
Procedures for handling AFI allocations -- brief discussion at last  
IETF, subsequently on mailing list.  Rules approved by IESG.  We have  
SA, FCFS, and reserved.  See slides for details.
List of docs on which no progress -- see slides.
No objections for draft-lefaucheur-idr-v4nlri-v6nh-00 as WG doc, but  
weak support.  Since revised to -01.  Note that softwire mesh  
framework refs this as normative, so there is need for this doc to  
exist, so will be accepted as IDR WG doc.
BGP MIBv2 -- been around for six years.  -05 version of draft expired  
a year ago and nobody seems to care.  Editors seem to have abandoned  
it.  Yakov and Sue periodically bump milestone forward a couple  
years.  What should WG do with this draft?
- - Pekka Savola -- speaking as an operator, current MIB isn't  
sufficient, we are using new MIB and some vendors are implementing,  
for example being able to see amount of prefixes we receive and have  
filtered out is useful.  Would be good to survey what is actually  
useful in MIBv2
- - Sue Hares -- Pekka, can you do the MIB revision?
- - Pekka -- I'd be happy to send feedback but not to edit it.
- - Yakov -- unless we get an editor to adopt it, we won't have  
progress on it.  Pekka, you have a valid point but without someone to  
work on it, there's nothing to be done.
- - Simon Leinen -- I also have concerns that this is really required  
to operate BGP in a multiprotocol world.  I volunteer to do what's  
necessary to help.  I'm not normally on the IDR mailing list, but I'm  
concerned about this.
- - Yakov -- OK, how about this?  We extend the milestone one more  
year.  If we make progress, great.  If there's again no progress on  
the MIB, we remove the milestone.
- - Simon -- fair enough.

draft-fedyk-bgp-te-attribute-02.txt  (Hamid Ould-Brahim)

Traffic Engineering Attribute -- completing VPN auto-discovery for  
L1VPN.  See slides for details.
- - JP Vasseur -- should we resurrect 2 year old TE attribute draft we  
did for L3VPN and integrate the two?
- - Yakov -- which WG should it be in?  L1VPN, L3VPN, CCAMP, IDR...?
- - Adrian Farrel -- we should discuss at routing area open meeting.   
CCAMP seems like the right place.
- - Yakov -- will integrate John Scudder's comments.
- - JP -- how about old draft?
- - Yakov -- old draft introduces new SAFI, we don't understand why.
- - JP -- would need to discuss with authors of old draft.

draft-asati-bgp-mpls-blackhole-avoidance-00.txt (Rajiv Asati)

Data plane failure in MPLS networks has bad consequences.  Should fix  
this in the route resolvability check.  See slides for details.

- - Ina Minei -- seems to me that this is implementation specific.  Why  
should this be fixed at protocol level?  Other implementations don't  
suffer from similar problems.
- - Rajiv -- fair enough.  Just because some implementations don't  
suffer from a subset of the problem, doesn't mean it's not a valid  
problem.  For example if you use ordered LDP that hides the problem,  
but what about data plane failures, e.g. data corruption?
- - Ina -- OK you agree that LDP-ordered fixes it.  What about  
corruption in labeled path?  Other implementations have a fix for  
that too.  So, why spec it?
- - Rajiv -- well we can fix anything in theory.  What is sense from  
operators in the room?
- - Ina -- AND, should solution be at protocol level or implementation  
- - Yakov -- for presenter: what specific changes do you require from  
the protocol?  What do I need to change to support this?
- - Rajiv -- bestpath changes.  That's all.  Not a change within the on- 
the-wire protocol at all.  Other change is the means to interact with  
LSP Health DB.
- - Yakov -- LHD is outside scope of BGP, base spec doesn't talk about  
how to interact with ANY other protocols.  Sounds like you want this  
WG to change route selection algorithm.
- - Chandra Appanna -- I pretty much agree that there is not much to  
standardize here.
- - Rajiv -- changing the route resolvability check is the only part  
relevant for the WG.
- - Ina -- and does that need to be spec'd?
- - Yakov -- well the current spec is nebulous.
- - Chandra -- maybe we need to say that implementations should be  
smart about interpreting what "next hop reachability means"
- - Yakov -- exactly.  They shouldn't be dogmatic when reading the BGP  
- - ??? (name not stated at mic) -- I agree with Yakov.  I suggest this  
is informational.  LDP black holing is an implementation problem.  I  
think that this is very helpful.
- - Yakov -- any closure on what to do with this doc?  Anyone read it?   
(Lots of hands.)  OK what do you want to do with doc?
- - Chandra -- if there is interest on the list, maybe this can be  
informational.  Other than that, not much point in making the "be  
smart" statement.
- - Yakov -- one thing we should try to avoid is to prescribe a certain  
way of implementing.  Not our business.
- - John Scudder -- fundamental premise OK but seems like a lot of  
pages to make a simple point, and too much implementation details.   
Isn't basic point that if network layer foo is used for forwarding,  
network layer foo reachability is needed to qualify NH?
- - John -- could make this a one-page doc that says "please be careful  
about selecting a next hop if j. random network layer reachability  
isn't there".
- - Yakov -- yes, that could be a one-page draft (one line plus  
- - Yakov -- up to authors to do what they like bearing in mind comments.

Idr mailing list