[Idr] IDR WG minutes

Folks,

Attached are the minutes. Please review/comment before I'll
post the final version. The deadline for comments is Aug 18, 2008.

Yakov.
--------------------------------------------------------------
1) Document status 

At RFC editor Queue: 

- idr-ietf-idr-route-filter-17.txt
- idr-ietf-idr-bgp-prefix-ortf-06.txt 

2) BGP well-known Communities procedures: Dave Ward 

Dave ward:
- i sent proposal to list
- well known communities
- RFC 1997
- no registration procedures
- two reserved spaces and defined well known
- proposal is to keep one reserve space and existing well known
- split 50-50 into first come first serve and IANA defined
- same as ext communities

- polled a few people - no other requested ranges

- as on the list, req to use well known community from well know to
  equiv of reserved
- how to know when something is well known
- whether change semantics or not change to code points

Discussion: 

Danny McPherson: One of my concerns is that many people that are using 
community values today will not supported in the new scheme.

Dave: It is in the community reserve well-known range (0xFFFF8001  - 
0XFFFF FFFF) 

Yakov: Why do we need to reserve well-known range? Why can't we use 
First-Come-First Served and IANA 

Dave Ward: more than happy to have that, that was what was one the list

Yakov: any comments on that?

<none>

Yakov: assume there will be no more well known communities

Brian Dickson: I have a proposal new well-known community.

- for effective deployment of what i'm proposing will need to be well-
known community

Dave Ward: What is required is that a well-known community will have to 
turn on a knob? 

Brian Dickson: My proposal requires that the last-resort community be 
on by-default.

Dave Ward: That may mean that your feature is un-deployable given these 
rules. 

Yakov Rekhter: That is the issues with well-known communities, what is 
meant by "well-known". 

Brian Dickson: At what point do we consider that the proposal is "well-
known". The status of a proposal can help find the "well-known" issue. 
If the proposal

Danny McPhearson: You are proposing a "pretty well-known community".

Dave Ward: Until a community is at full standard, then it is not full-
well-known.

Brian:  There is no consensus on what is well-known. Your definition 
means that no more well-known communities will occur. 

Dave: I would indicated, unless we agree on a procedures no well-known 
communities 

Yakov: let's take to the list.  We still have an issue of what is 
"well-known".

2) draft-ietf-idr-bgp4-mibv2-07.txt 10 mins

MIB Status (via the presentation). Danny presenting

Danny McPherson
- thanks to joan
- most of the stuff is there - mostly structural
- a big issue is do we want to allow configuration objects
- largely the consensus that no
- if you use that make it known quickly

- indexes...
- looking for a new name for BGP extensions
- all this was on the list
- since no pays attention to MIB presentation
- jeff summarized all this on the IDR list

- look there if you are interested in the MIB
- email jeff or IDR - send comments there

Yakov: questions?

<none>

3) draft-knoll-idr-qos-attribute-01.txt 15 mins

Discussion: 

Yakov: What do you want done with this email?
Knoll: I want IDR Working Group to accept both this draft and draft-
knoll-idr-cos-interconnect-00.txt as IDR working group documents.
Yakov: I suggest that you combine these drafts before asking the 
working group to approve it.
Yakov: How many people read the draft? (10 hands raised)?
Yakov: How many people feel this draft is ready for a working group 
draft? (no hands)
Yakov: I suggest that you send email to the mailing list asking the 
working group chairs to poll the working group for a consensus on
accepting your draft as an IDR working group document.

4) draft-chakrabarti-idr-as4-route-cap-01.txt 15 mins

Discussion: 

Pradosh: I have a hard time finding the usefulness of the draft. 

Samita: In the four byte a difference between the four byte and the two 
byte. If configured with two route targets (four-byte and two-byte) you 
would get two different sets of route type. 

Pradosh: It is a local policy type. You can set this by configuration 
type. 

Yakov: To allow different allocation procedures of route targets ISPs 
are allowed to use its own AS number (2 or 4 bytes). The provider may 
choose either 2 byte or 4 byte allocations. Whether a route target is 
IP-v4 based on 2-octet AS-based or 4-octet AS based matters only for 
the purpose of route target allocation. The receiving PE should not 
care which type of Route target it is. 

Robert Razuk: If you have the new RT and the Old RT, what is the point 
what is the point of this draft? 

Yakov: Why does it matter from the receiving side what type of Route 
target you are receiving.  

Robert Razuk: Receiver doesn't care. 

Yakov: Yes, receiver doesn't care.  The provisioning system is the one 
that provides such a route-target. 

Yakov: You (Samita) need to articulate the problem that we need to 
solve. Otherwise, we have a technology without a problem. 

Samita: The problem we faced when the receiver is configured for 2 byte 
extended community and it receives the 4 byte community, it looks at 
the type and doesn't know what to do with it. 

Yakov: An implementation should not be configured to accept certain 
types of route-targets. The implementation should be accept all types 
of route target.

5) draft-dickson-idr-last-resort-04.txt 10 mins

Discussion: 
Yakov: Do you want to take questions after both or after each. 
Brian: After each presentation. 
Dow: when saying it solves the BGP wedgies, you are thinking of cases
of preferred and last resort?, but not preferred, second preferred, ...
last-resort.

- in other words, you can still have cases
- this solves certain cases...

Brian: Strictly the last resort. It would take the last resort out of 
the wedgies. 

Dow: There is indeterminism of the BGP wedgies that are improved by the 
addition of more information. It does not solve all the BGP wedgies 
problems.

Geoff Houston: this doesn't solve the wedgies problem
- solves some problems, but not the general case
- adding information solves some cases, but not the underlying
determinism in BGP

Brian: it solves some of the wedgies problems 

Geoff Houston: BGP wedgies are caused by BGP behavior. 
Geoff Houston: My point is that it would be over-claiming to solve all 
BGP wedgies. 

Volk:

- i think it solves most of the problems i would be concerned with
- i think this standardization is welcome
- it will help

Yakov: how many read?

<good many>

Yakov: how many think should be WG doc?

<not many>

Yakov: Suggest author ask the working group chairs to poll the the
working for a consensus on acceint this draft as an IDR WG document.

6) draft-dickson-idr-well-ordered-nth-best-01.txt, draft-dickson-
add-paths-ordered-01.txt 20 mins

Discussion: 

Brian: Takes multiple instance of a MRAI timer to as much as several 
minutes to several seconds of the 

Dow Street: Your statement that this reduces bandwidth. I can imagine 
it really increases between router bandwidth. 

Brian: I am talking about in-chassis bandwidth where bandwidth is 
exchanged. 

Dow Street: This is not messages between routers? 

Brian: Normally in chassis bandwidth is much more restricted than 
between routers. 

Yakov: with respect to extra memory requirement, keep in mind this is 
control plane memory, not data plane memory

Yakov: with respect to extra bandwidth required keep in mind that the 
links between control plane are 1 Gigabit and up.

Mark Handley: I am sure it might reduce churn of route table churn 
within the box. But it requires more BGP bandwidth passing to/from. 

Brian: An extra amount of data is flood to set-up this detailed level 
of information. After this point, the exceptions (failures/up-down) are 
the traffic. I realized late that it is the order re-changing that 
allows some more density of information.

Adrain: What happens when best returns to trump second-best and return 
to Best? 

Brian: When the best returns, the second best [need to provide the 
information]. 

Lixia Zhang: In our work we saw a ton of data. We saw that after the 
failures switch from path A to path B (due to failure in A), there are 
a lot of paths that stay on path A because they do not see the failure 
within A. 

Brian: You need the subsequent "N-events", because you not know what 
additional events. It is a combinatorial issue. 

Yakov: The whole purpose behind this is fast connectivity restoration.
If a site is multi-home, the interesting question how fast you switch 
between providers. How much path-hunting has negative impact in this 
case ? 

Lixia Zhang: How bad is the convergence? It is not 30% of the cases 
that are really bad.  In the 70% of the cases, there is not a 
convergence problem. 

[Chris Mark, google] There is 270,000 current routes and 200,000 
alternate paths. Verizon networks keep 16+ paths in the network. This 
is very expenses for everyone. 

Yakov: this is important that this is an optional feature because it 
may be expensive to some people.

Brian: This is passes another set of information to different routers.  

Pradosh: If this is deployed in the multiple provider environment, it 
pay provide additional information. 

Brian: It is bi-direction for sending information. If you examine, the 
data flow you may find that there is 

Lixia: In the experience of worrying about the worst case, when the bad 
things happen  multiple prefixes may have multiple prefixes where it 
gets really bad. 

Yakov: To solve 100% of problem the cost may so high that it will make
the solution undeployable.

Resolution after discussion: 

Yakov: Is there any interest in going on with what is going? 
Yakov: How many people have read this drop?  (15 people)
Yakov: How many people think we should go on with this draft (10 
people)? 

Brian: Please send the odd-ball topologies that may stress this 
algorithm to me. 

5) draft-ohara-idr-practical-request-00.txt 10 mins

Yakov: Comments from the audience

Ruediger Volk: Routers should not crash under unexpected data. If 
unexpected data occurs, it should be filtered away from the protocol 
side. This is information. Operators like to have robust router 
implementations. If unexpected data floats around, we want to have 
means to catch such data. This seems to be entirely a router 
implementation

Vince Fuller: It is a very good case to reset the bgp peer session near 
the source.   

Yakov: This is a bit of historical information because BGP is 20 years 
old. One of the complaints against BGP is that the error handling is 
simple. All error handling causes a fatal error of disconnection. There
are reasons for this. Once you pass the information, the information
gets stuck on the other end. If you just ignore the information, you 
may get into difficulty. The best handling is:

  1) refresh the data via the BGP-Refresh processing,
  2) If the error occurs a second time, then keep the connection 
     down. 

Ruediger Volk: I care that you can filter out information. But that is 
an implementation.

Yakov: If folks have specific cases, where different vendors give 
different interpretation to specification - please bring that to the 
working group. This case of non-interoperability indicates a 
specification bug, and we will fix it. 

6) Two drafts below: Francis 

draft-francis-idr-intra-va-00.txt 20 mins

Discussion:

Dino Farinacci: Do you believe that the highest level it will be a tree 
of informaiton or it will be 

Paul Francis: I am not sure that you 

Dino Farancci: How far will the packet go up before it gets dropped? It 
goes up to the aggregation drop. 

Rajeev: What is exactly to be asked?

Paul Francis: The -00 draft has a new extended community.  It could
turn out that there is good be that there is no additional changes
to the BGP specification and very little changes to the BGP
implementations.

Rajeev: Have you given any thought to operational issues about
having RIB that is not the FIB?  Why not filter what goes into the
RIB?

Paul Francis: This concept of suppressing things in the RIB is
problematic. Look at the all the proposal in the Routing Research
group about this topic.

Paul Francis: There is no topology changes. The only addition is
that the routers set-up tunnels between routers.

Yakov Rekhter: One way to reduce the state on routers is to have
multiple areas, and within each area point Default to the ABRs of
that area.

Robert Raszuk: Marking with the special community it. 

Chris Lilentoje: Value to see in the RIB.  I can still propogate this 
information out the RIB.  Internally the RIB is not as fully populated 
and efficient. 

Brain Dickson: I think there is an interesting corner to this topic. 
Having the ability to suppress from the RIB to the FIB, is generally 
applicable to defensive proxy aggregation.  Defensive proxy aggregation 
is when you aggregate internally but do not pass it on (???. It is 
important to have a mechanism that allows you to tag the things that 
do/do-not go into the RIB. 

Yakov Rekhter: You should look at NANOG-39 with presentation from 
Force-10, as it describes a way to reduce the size of FIB 

Tony Li (RedBack): We have another document series where this is 
appropriate for the work. It is a BCP. 

7) LISPs information - Vince Fuller 

draft-fuller-lisp-alt-02.txt, draft-farinacci-lisp-07.txt 20 mins
Vince Speaking on the LISP-ALT group. 

Questions: 

Yakov: You claim that BGP configuration complexity is a barrier to 
site-multihoming, but in reality how many lines of configuration is 
required for a simple BGP setup ?

Dino: LISP full 4 lines, BGP is 10 lines.

Yakov: I am sure that 6 line does not matters a great deal for others.

Shane Massey: Enterprise networking people are afraid of BGP.  We have 
mail them a template from level-3 to get connected. 

Tony Li: It is entirely reasonable that enterprise are afraid. How many 
have them sent all routes into the routing table (???) 

Tony Li: What is the minimal configuration to do multiple-homing? When 
people go to multi-homing is to balance their traffic incoming and 
outgoing.  This requires an enormous to take all prefixes and munge the 
routes. 

Peter Lothberg: I use multi-home on my little home network. 

Vince: We'll give Peter's phone number to the ISPs and he'll get little 
sleep in the next few days.

Adrian: How does the EID space work? How do you guarantee that the EID 
space will 

Vince: You create the EID space and assign it to follow the topology? 
You need to have the topology congruent to the EID topology (??).  
Topology has tunnels. 

Yakov: It is geographic addressing. 

Vince: It is not true. The reason that geographic topology does not 
work because (EID and addresses)[need the input here].

Yakov: There is no additional traffic that goes through the ALT traffic.

Hannes I have got one comment on the amount of geographical topology. In 
fixing convergence problem, we see that data driven state is the 
barrier to fixing the convergence problems. My request would be to 
avoid data driven state.

Vince: It is not a requirement to use data driven state. It is not a 
requirement 

Tony LI: My understanding that EID is going to use IPv4 address space?

Vince: It is not true that EID space will necessary be holding IPv4 
address space or the 

Dino: IPv4 is a swamp. IPv6 is much better to provide geographical 
address. If we renumber we can have addresses. If we cannot renumber, 
we LISP. 

Tony LI: Why do LISP if you renumber? 

Dino: You only have renumber once more. 

Tony LI: The interesting place is where do you renumber the swamp? 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

[Idr] IDR WG minutes - preliminary