[Idr] IDR WG Minutes

Yakov Rekhter <yakov@juniper.net> Mon, 08 August 2005 15:07 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29DX-0007Ys-37; Mon, 08 Aug 2005 11:07:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29DV-0007XR-PO for idr@megatron.ietf.org; Mon, 08 Aug 2005 11:07:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27194 for <idr@ietf.org>; Mon, 8 Aug 2005 11:07:03 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29lE-0002P1-5A for idr@ietf.org; Mon, 08 Aug 2005 11:41:56 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j78F6uBm053350 for <idr@ietf.org>; Mon, 8 Aug 2005 08:06:56 -0700 (PDT) (envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j78F6uG02001 for <idr@ietf.org>; Mon, 8 Aug 2005 08:06:56 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200508081506.j78F6uG02001@merlot.juniper.net>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <58238.1123513614.1@juniper.net>
Date: Mon, 08 Aug 2005 08:06:55 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
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>
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Folks,

Attached are the minutes. Please review for correctness *before*
end of this week.

Yakov.
-------------------------------------------------------------------

IDR WG notes 2005.08.04 -DWard
-------------------------

Doc status
see ppt

Danny McPherson to finish Confed implementation report in one month

Geoff Houston to complete 4-octet AS number space

New MIB editor see draft

-------------------------
Li AS Hop count Attribute

see ppt for info
Essence: Add TTL to each prefix, decrement at AS boundary
Drop route when TTL hits zero
Transitive attribute

Alt: Distribution Lists
List contains ASs that can rx and cannot exclusion

NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

Houston: is NO_EXPORT dropped or continued when combined?

NOTE:  Can scope 'anycast'

Houston: when aspath prepending, is that expressed in the HOP_COUNT?
Li: Decremented by one always

Hares: Two more ASPATHS per route? How does scaling work?
Li: In the worst case, when setting up a list you can have an 
arbitrary  number in incl or excl list?

Hares: Is order semantics true but,

Rekhter: An ASPATH cannot carry all AS in the internet as not enough space

Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
roughly two X

Hares: Why do you say proxy usage is diffficult in Dist List case? 
TTL is lighter but, why choose between two? Might have both.

Li: From an implementors POV, it is easier to do one and not two

Rekhter: The increase in number of AS' per route is not a practical issue

Houston: At the edge, it may work but, topology is dense and we nee

Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a 
separate counter?

Li: Want to see draft first. Technically what is required is a 
separate attribute but, look almost identical

Houston: When comparing the two mechanisms need to look at "what is 
going on." Distribution lists require complete knowledge of topology. 
Problem is that you cannot insure that they do not leak. HOPCOUNT 
does not have 'knowledge' problem but, focuses on accuracy.

Hares: Inclusion requires enumeration but exclusion does not

Houston: HOPCOUNT allows more specifics w/ a boundary. Advocates HOPCOUNT

Roque: No productive compare the two. Want to select upstream 
provider w/ targeted ext comms. HOPCOUNT might prevent this 
technique. Most common TE technique; customers preferring transit AS' 
per prefix. Not applicable for transit exit scenario. Two issues and 
solutions are orthogonal but, neither solution is devalued.

Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

Li: Yes and not violate

Chris; Will it get used if provider ignores or removes

Rekhter: Who is entity that benefits from this? Which SP.

Li: Table size reduction is goal. One SP adds does the work but, gets 
no benefits. Altruism or hope of it is a good reason.

Houston: Zhang drafts in GROW show that altruism is bunk instead 
self-interest. Most UPDATEs come from lower tier points. Most 
computation happens at lower level of peering .. therefore, small 
folks get most thrash. If "I" do this, I help my problem ... 
therefore altruism is there for the folks that use it and tag it.

David Ward: Affect Hop count?

Li: Not significantly as it would be longer prefixes.

Enke: Can we inject an AS numer as 'signature' of who adds attribute?

May be added to draft. No comments

-------------------------
Zhang Renhai Entire Route Reflect

Comments held until after Walton's draft
see ppt for info

-------------------------
Walton Add Paths
Alvaro Retana (Cisco) presenter.
see ppt for info

NOTE: RFC 3107 must be updated

-------------------------
Walton Oscillation Stop
Alvaro Retana (Cisco) presenter
info in same ppt as "Add Paths"

Swallow: What is frequency of oscillation?

Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

Combined questions for both draft authors:
Danny (unaffiliated) - We are increasing and decreasing table size. 
Walton's draft is more general and flexible then Zhang's.

Retana: Most of increase of table size is internal to an AS (almost all)

zhang: I don't understand question.

Zhang: Walton's draft is more general. Because you add attribute, do 
you think that efficiency of packing will be affected?

Retana: NLRI will be bigger but, no impact on packing.

Gargi (Cisco): Zhang's draft - must specify that you explicitly WD 
when a nexthop changes or how to announce new NH?  How do you delete 
the first NH?

Zhang: If NH changes, just add it. To solve the problem there will 
taken offline to email.

Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
paths to a legacy speaker?

Retana:  Cap advert defines who can learn add_path. Other 
applications like EBGP ECMP and propagating multiple paths will have 
to be addressed.

Retana: Constrained scope.

Roque: Although you say impact of deployment is localized. We need a 
better understanding of what impact will be. For each route prefix, 
path attrs in Adj RIB Out. Generally announcement, is only  when 
Adj-RIB-Out changes. What is expectation of propagating changes when 
inbound updates would cause outbound content. What are consequences? 
Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

Retana: Spec says send on path. Change is that we would have tracking 
of two or more paths.

Rekhter: We can have as many ad hoc solutions as we want or a more 
general solution. We as a group should decide on a more general 
solution. We should look at potential new functionality once we have 
more than one path being advertised.
Suggestion is that the authors of three proposals should find common 
solution to all problems that WG would like to address. A mailing 
list will be set up to discuss this problem and solution. On the IDR
mailing list please identify problems.

Rekhter: Do we need requirements document?

Ward: No, absolutely not.

-------------------------
Dubois PM Reqmts

see ppt for info

Rekhter: Send note to list on whether or not we should take as a WG doc.

Dubois: Earlier solution was not meeting requirements and there are 
many possible solutions. We need a solution that fits the 
requirements; we are not encouraging one solution over another:

Ted Seely (Sprint): Why not weight traffic away from peer or 
interface? There are other techniques that don't require change to 
protocol.

Ruediger Volk: I lose traffic when I do this technique.

Ruediger: The convergence problem I see is due to the previous issue 
of config change.

Jason Schiller (UUNET): Is there a hard requirement that this does 
not require a config change ... taken to the list.

-------------------------
Hares Dynamic Confed AS

Not requested to be WG item.
see ppt for info

Roque: I would assume that you would want to do restoration in a 
seamless way. What is motivation to make failure restoration a 
visible outside the confederation?

SKH: Goal is to not drop the peering session. Therefore, the purpose 
is policy rerouting wants to 'hang by itself.' If I drop out of the 
AS confed, I would have had to drop the session.

Roque: Why not just tunnel back?

SKH: No IGP connectivity and tunnels ran into problems.
SKH: will send scenarios to list

Chandra Appanna (Cisco): I think you need a few more failsafes. 
Resend is a MUST, and some mechanisms is nec. that moved did not 
suddenly change. Need to resend routes due to policy change potential.

SKH: We have added failsafe. We delayed resend, it would be abnormal 
to send all routes if nothing changed. Will send scenario in email.

Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones 
moves from one confed to another?

-------------------------
Multisession update - Chandra Appanna

See ppt for info

Added flexibility for any capability code to cause/create multiple sessions

No comments

-------------------------
Kapoor SSA - Gargi, Scott Wainner

see ppt for info

-------------------------
Kapoor Tunnel SAFI

combined w/ SSA preso, same ppt

Gargi did technical side and changes to docs:

more TLVs to express encap:

MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

added application scenarios: MPLS over IP tunnels

Scott presented motivations

Combined comments:

SKH: Can you explain status of this mechanism w/in each of these 
groups (on referenced drafts)? What is approved, required, etc. We 
need to see something from those chairs that the ref'ed drafts are 
"blessed."

Scott:  Walked through

Gargi: We have chicken and egg to get this done. Encoding first or 
formats first?

Intro work on L3VPN list.

Rekhter: Very reasonable model where must have both WGs review dependent docs.

Bill Fenner:  Must work w/ other WG for encoding.

Rekhter: Two possible models - first: semantics or encoding need to 
be done in L3VPN
    second: L2/L3VPN WGs tell us semantics and IDR produces codepoints

Rahul:  C/E problem wasn't problem in the past but, applicability. 
Applicability has been cleared up. Now that motivations are clear, 
the multiple proposal should be conjoined. Do work wherever ADs state

Roque: Disagree w/ motivations. IGP can provide reachability. I think 
you use BGP as signaling protocol which is not a problem. But, 
presentation states that BGP needs to know this information. Please 
clarify the layering split.

Rekhter: Can this move to L3VPN

SOLUTION: Joint Last Call in IDR and L3VPN.


-------------------------
SAFI Space Partition
In reply to Jeff Hass email on list.

Fenner to send notes on how to alloc SAFI space.

Proposal: take private use space and turn it into reserved and 
perhaps 16 or so as private use. Reserved is reserved so we can 
decide later on FCFS or otherwise managed.

Are folks using private space? Do we need to skip some?

Rekhter: How long will it take to use up first come first served?

Fenner: We should be able to straighten this out quickly and IANA is 
keeping up. 30 days deadline.

Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
it IETF aligned.

Roque: I do not want to see vendor specific space go away altogether. 
There is much more usage than one case alluded to. Today is only 
practical alternative, cannot be locked out. Can it be shown to work 
before we assume 30 days?

Fenner: There are publications on these agreements and promises that 
it will be done in 30 days. FCFS is you get it now .... no draft, no 
wait.

Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and 
is a way to differentiate addrs between two peers. Just need opaque 
space that we can use between two peers.

Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is 
faster but, it seems to required Routing ADs having lunch w/ IANA.

Rekhter: IANA must have strict 30 days max as rule.

Fenner: We are working on this and the stats show that 30 days is being met.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr