[Idr] minutes

[Yakov Rekhter <[e-mail]>]

Folks,

The revised minutes have been posted (see below). 

Yakov.
------- Forwarded Message

Date:    Mon, 15 Aug 2005 12:21:20 -0400
From:    Rebecca Bunch <[e-mail]>
To:      Yakov Rekhter <[e-mail]>
Subject: Re: IETF-63 Proceedings Submission

Your proceeding submissions have been posted, please review them on line 
and send any corrections to [e-mail]. The deadline for 
submitting corrections is Monday, September 19, 2005 at 17:00 ET.

https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=63


Yakov Rekhter wrote:

>Hi,
>
>Attached are the IDR WG minutes.
>
>Yakov.
>---------------------------------------------------------------------
>
>IDR WG Minutes 2005.08.04 
>-------------------------
>
>Doc status
>see ppt for info
>
>Danny McPherson to finish Confed implementation report in one month.
>
>Geoff Houston to complete the implementation report for 4-octet AS 
>number space.
>
>New MIB editor see draft
>
>-------------------------
>Tony 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
>
>Geoff Houston: is NO_EXPORT dropped or continued when combined?
>
>NOTE:  Can scope 'anycast'
>
>Geoff Houston: when aspath prepending, is that expressed in the HOP_COUNT?
>Tony Li: Decremented by one always
>
>Sue Hares: Two more ASPATHS per route? How does scaling work?
>Tony Li: In the worst case, when setting up a list you can have an 
>arbitrary  number in incl or excl list?
>
>Sue Hares: Is order semantics true but,
>
>Yakov Rekhter: An ASPATH cannot carry all AS in the internet as it
>would exceed the maximum size of the BGP Update message.
>
>Tony Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
>roughly two X
>
>Sue Hares: Why do you say proxy usage is diffficult in Dist List case? 
>TTL is lighter but, why choose between two? Might have both.
>
>Tony Li: From an implementors POV, it is easier to do one and not two
>
>Yakov Rekhter: The increase in number of AS' per route is not a practical 
>issue
>
>Geoff 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?
>
>Tony Li: Want to see draft first. Technically what is required is a 
>separate attribute but, look almost identical
>
>Geoff 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.
>
>Sue Hares: Inclusion requires enumeration but exclusion does not
>
>Geoff Houston: HOPCOUNT allows more specifics w/ a boundary. 
>Advocates HOPCOUNT
>
>Pedro 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"
>
>Tony Li: Yes and not violate
>
>Chris Morrow: Will it get used if provider ignores or removes
>
>Yakov Rekhter: Who is entity that benefits from this? Which SP.
>
>Tony 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.
>
>Geoff 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?
>
>Tony Li: Not significantly as it would be longer prefixes.
>
>Enke Chen: 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"
>
>George Swallow: What is frequency of oscillation?
>
>Alvaro 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.
>
>Alvaro 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. 
>
>Alvaro 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 Jakma: If in ECMP case, what AS sequence? How to pass multiple 
>paths to a legacy speaker?
>
>Alvaro Retana:  Cap advert defines who can learn add_path. Other 
>applications like EBGP ECMP and propagating multiple paths will have 
>to be addressed.
>
>Alvaro Retana: Constrained scope.
>
>Pedro 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.
>
>Alvaro Retana: Spec says send on path. Change is that we would have
>tracking of two or more paths.
>
>Yakov 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.
>
>Yakov Rekhter: Do we need requirements document?
>
>Ward: No, absolutely not.
>
>-------------------------
>Dubois PM Reqmts
>
>see ppt for info
>
>Yakov 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 Volk: 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?
>
>Sue Hares: 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?
>
>Sue Hares: No IGP connectivity and tunnels ran into problems.
>Sue Hares: 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.
>
>Sue Hares: 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:
>
>Sue Hares: 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 Wainner:  Walked through
>
>Gargi: We have chicken and egg to get this done. Encoding first or 
>formats first?
>
>Intro work on L3VPN list.
>
>Yakov Rekhter: Very reasonable model where must have both WGs review 
>dependent docs.
>
>Bill Fenner:  Must work w/ other WG for encoding.
>
>Yakov Rekhter: Two possible models - first: semantics or encoding need to 
>be done in L3VPN; second: L2/L3VPN WGs tell us semantics and IDR produces 
>encoding.
>
>Rahul Aggarwal: there were two problems in the past: 1) Motivation wasn't
>clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors
>of the drafts presented at this IDR meeting were unable to come up
>with a joint proposal. Suggested that since motivations are clearer
>now, this work should be discussed again in the L3VPN WG.
>
>Pedro 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.
>
>Yakov 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.
>
>Bill 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?
>
>Yakov Rekhter: How long will it take to use up first come first served?
>
>Bill 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.
>
>Pedro 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?
>
>Bill 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.
>
>Yakov Rekhter: IANA must have strict 30 days max as rule.
>
>Bill Fenner: We are working on this and the stats show that 30 days 
>is being met.
>
>  
>

------- End of Forwarded Message


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr