Subject: IDR WG minutes IETF 54

From: David Ward <[email-masked]>
Date: Thu, 18 Jul 2002 19:45:20 -0500

NOTES: IDR WG meeting IETF 54
Scribe: David Ward

Agenda
	Route Oscillation
	Inform message type
	Extended Communities
	Document Status

Route Oscillation
I.	Anindya Basu Lucent presenter
	draft-wilfong-ibgp-oscillations-00.txt

	1. Brief Overview of Problem (Route Reflection example)
	2. Overview of Transient Route Oscillations
		a. proposal converges to stable situation
			i. potential problem in scenario where there 
could be an
			non-deterministic outcome
	3. Solution
		a. send xtra info
		b. if same aspath length, same loc_pref, diff AS: 
send both prefixes
	4. Correctness
		a. always converges
		b. loop free
		c. works for multi level RR and confeds
	5. Scaling
		a. don't need to always send xtra routes
		b. only advert when detect oscillations
			i. propose using low-pass filter to weed out 
restarts and detect
			high frequency osc.
	6. Issues seen in other drafts
		a. Walton
			i. doesn't solve transient and not all 
persistent oscillations
		b. Chen
			i. believes all clients must be fully meshed

QUESTION:
	How to detect oscillation?
ANSWER:
	Add a counter to each entry in FIB and a timer and use 
low-pass filter to determine if osc.
NOTE from author: If want to scale must fine some measure to detect oscillation

II. Alvaro Retana presenter:
	draft-walton-bgp-route-oscillation-stop-00.txt

	1. Brief Overview of Problem
		a. Type 1: single level RR/Confed
			i. solved in RFC 2796, 3065
		b. Type 2: multitier/hierarchical RR/Config
			i. must send multiple paths
			ii. always-compare-med considered unacceptable solution
		c. Oscillation stats from empirical analysis (2001 data)
			112086	 total routes
			9011	 candidates for oscillation (~10%)
			899           actually oscillating		(< 1%)
	2. Solution
		a. If RR or ASBR of confed
			i. send best path
			ii. send 'neighbor AS best path'
	3. Comparison
		a. Walton or Wilfong - requires oscillation detection
		b. Chen - not multi-level
	4. Next Steps
		a. determine oscillation detection mechanism - may be 
implementation specific
QUESTION: Will the number of oscillating routes increase in the future?
ANSWER: Potentially

QUESTION (Alex Zinin): What about detection mechanism?
ANSWER: YTBD

	draft-walton-bgp-add-paths-00.txt
	1. This extension is required for oscillation solution
		a. could be adopted as an additional solution above 
and beyond oscillation
	2. Proposal
		a. change NLRI encoding in 2858
			i. add bestpath bit - represents that path 
has been selected by speaker
			and put into FIB
		b. same change to 3107 for MPLs
			i. additional clarifications necessary
		c. add new capability advertisement
			i. multipath capability
			NOTE: must not use encoding in 3107
	3. Soon to be released new proposal
		a. remove multiprotocol linkage
		b. change encoding to flags (1 octet) in all specs:
			i. 1771, 2858, 3107
		c. can also solve route server functionality in 
addition to oscillation
	4. problems in 3107
		a. how to send multipath and encoding doesn't match text
		b. proposal is to change 3107 encoding to use new proposal
		NOTE: PPVPN owns 3107

III. Sue Hares presenter
	1. Mixed Issues w/ draft 17 -> 18 and FSM seen on list in 
dicussion of osc. drafts
		a. tie breaking rules
			i. e.g. cluster_id
	2. Oscillation drafts comparison and issues
		a. always-compare-med not adequate sol'n
			i. solution today is to restrict topology
			i. too difficult to coordinate MED values 
across multiple domains (asp)
	3. Presentation of Enke Chen's proposal
	draft-chen-route-oscillation-avoid-00.txt
		a. restrictions
			i. solves one level RR/Confed hierarchy
			ii. requires full mesh
		b. solutions
			i. announe best path rx'ed from clients
			ii. best path from all
			iii. calc IBEST and EBEST
			iv. announce according to rules in draft
Statement: Naiming Sheng: Enke Chen's proposal has fewer protocol and 
implementation changes
	4. How to proceed?
		a. vote for adoption
			i. no wilfong
			ii. some walton
			iii. few Chen
Statement: Alvaro Retana
	What is problem we are trying to solve?
	Enke's doesn't solve any problem
	Wilfong's solves problems that are not known to exist
	There is a real problem as there are multilevel topologies deployed
Statement: David Ward
	We know that Enke's proposal does not solve the problem in 
the protocol specification
		and his proposed solution is already covered in 
exisiting RFCs. Therefore, it should
		be removed from consideration.
Statement: Basu
	Must solve problem w/o toplogy restriction
	All possible topologies must be under consideration
	Protocol changes required
Statement: Robert Rasuk:
	Should separate add_path from oscillation solution as it 
solves other problems
Question: Sue Hares
	Should we solve the problem of only one level or multilevel 
topologies? Should we ask
	operators?
Question: Kireeti Kompella
	Is a survey of operators available? Where they forced to 
restrict topology?
Answer: Sue Hares
	In an informal survey Sue has found multilevel topologies 
deployed. Other operators
	restricted their topology but, didn't want to
Question: Amir
	If we are trying to solve a known problem why is there an issue?
Statement: David Ward
	We should move forward in working group today to adopt a 
draft or limit the numbers of
	drafts under consideration. IDR has identified and been 
working on this problem for
	over three years and still have no agreed upon solution 
leaving a large hole in the
	protocol specification. We should solve the problem that is 
known today and solve it
	fully and take on future problems as they arise. Only 
Walton's draft fits that requirement.
Statement: Basu
	Our draft does solve problems that do occur today and may 
occur. We cannot discount the
	ability to solve potential problems.
Statement: Alex Zinin
	Discussion must continue on list as there is no agreement. No 
working group action to be
	taken.

INFORM message
I. Gargi Nalawade presenter
draft-nalawade-bgp-inform-00.txt
	1. Goals
		a. no way to tell remote peer that there has been an 
error or event w/o use of
		NOTIFICATION
			i. this resets peering session
		b. no change to existing implementations
		c. limit sharing of messages between peers
	2. Encoding overview
		a. Packet format
		b. Event codes
		c. Data types
	3. Rx'ing the INFORM
		a. log it
		b. inform the administrator (implementation specific)
Question: How to use w/ NOTIFICATION?
Answer: Use it to inform that you are going to reset. Use immediately 
before the NOTIFICATION
but, now can add PDU/ATTR/whatever to help debug.

Question: Will this cause a change to the FSM?
Answser: No

Questons: What is "too many routes option?" How to define?
Answer: It is an implementation specific configuration

Question: Jeff Pickering
	Should a peer take any specific action upon reception of the INFORM?
	The authors should explicitly prohibit any automated action

Statement: Andrew Lange
	Move forward draft

Outcome: Sue Hares
	Accepted as WG item pending taking it to list

Extended Communities
1. Andrew Lange presenter
discussion on list is source of material
	1. Problem
		a. need to support IPV6
		b. could have more efficient packeing of values in data field
			i. see ptomain-bgp-redist
		c. clean for future data types
		d. support for locally defined community structures 
(types and subtypes)
	2. Improvements
		a. regular typed encoding over extended encoding
		b. value field becomes variable length
		c. type field and subtype field added
	3. Packet format
		a. see archive on list
		b. adds new base type
		c. type
		d. subtype
		e. locally defined types/subtypes
	4. Issues
		a. backward compatibility
		b. there is installed base (2547 deployments) of 
extended communities
Statement: Barry Friedman
	Make new attribute type
Question: Barry
	Does transitive mean across AS boundary?
Answer: Andrew
	Transitive means ti will cross boundary but, perhaps go no further
Queston: Geoff H.
	What is proposal to deal w/ changes in length? See historical 
issues w/ SNMP
	Recommend that the draft specifically states what to do.
		c. there are three ways to deal w/ backward compatibility
			i. there is a hack
				Only have new encoding beyond the 
first 4 codepoints (in ext.
				comm now)
				and then switch to new encoding
			ii. new attribute type
				Move forward existing ext comm work
				perhaps deprecate over time
Statement: Kireeti
	2 specs w/ new attr type is fine but, don't use word 
deprecate of orig ext. comm.
Statement: Gargi
	Don't use word deprecate as there are many installed bases

		d. Should we duplicate all ext comm into new 
attribute for IPV6?

Statement: Kireeti
	It wouuld be nice to do everything under new atttr but, have 
to create transition plan
	Need feedback from operators
Question: What happens if you have Route Target in old and new 
format? Perhaps dont' define in new attr
Answer: Andrew
	That is a transition and implementation issue but, we can add 
a statement on how to
	deal w/ duplicate information

Statement: Sue Hares
	WG action: Andrew to write new draft as new attribute and submit

Document status (Sue went too fast for me to get it all)
	1. draft 17 -> 18 based on FSM work
		a. skh wrote two new drafts
			i. statemt - state machine diagram
			ii. backoff - optional (in draft opt means optional)
Question: should there be a state machine and FSM table in draft?
Answer: Yes, there will be (concensus vote yes)
	2. V1 MIB working on security section
	3. V2 MIB going to LC
	4. various things in queue for RFC editor
	5. Various docs under discussion
	6. 2545bis
		a. MIB ready
		b. site local issues
		c. BGP ID issues
Statement: Alex Zinin
	What are consideratinos for site local addressing? Need to define:
		If needed
		How needed
		Where needed
	Alex requests WG to provide some clue on how to resolve issue in BGP.
Question: Sue Hares to Alex
	Can the IPV6 WG define site boundaries and scoping architecture?
	When will this be resolved?
Answer: Bill Fenner
	Perhaps soon. It would be good if IDR could help w/ 
architectural question if a site
	should be limited to within an AS, cross AS',etc

	7. Dynamic capability draft? Is it adequate?

Statement: Bill Fenner
	Cannot go to standards track w/ IPR statement as is. Must be 
removed to be standard

	8. Want implemenation report for Graceful Restart

	9. ORF to be discussed on mailing list

	10. Murphy's vulnerability draft to be IDR WG item

	11. Murphy's protection mechanisms to be RPSec WG item

Statement: Alex Zinin
Please help skh finish base spec. This needs to be completed for 
interoperable implementations.
Skh should not have to carry burden alone. Please help.

---

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 18 Jul 2002 18:47:36 -0700 (PDT)

David Ward writes:

> INFORM message I. Gargi Nalawade presenter draft-nalawade-bgp-inform-00.txt 1.
> Goals a. no way to tell remote
> peer that there has been an error or event w/o use of NOTIFICATION
> i. this resets peering session b. no change to existing
> implementations c. limit sharing of messages between peers
> 2. Encoding overview a. Packet format b. Event codes c. Data types
> 3. Rx'ing the INFORM a. log it b. inform the administrator
> (implementation specific) Question: How to use w/ NOTIFICATION?
> Answer: Use it to inform that you are going to reset. Use
> immediately before the NOTIFICATION but, now can add
> PDU/ATTR/whatever to help debug.

> Question: Will this cause a change to the FSM?  Answser: No

> Questons: What is "too many routes option?" How to define?  Answer:
> It is an implementation specific configuration

> Question: Jeff Pickering Should a peer take any specific action upon
> reception of the INFORM?  The authors should explicitly prohibit any
> automated action

> Statement: Andrew Lange Move forward draft

> Outcome: Sue Hares Accepted as WG item pending taking it to list

I object to making this a WG document.

I believe this mechanism is unnecessary and that no sufficient
justification has been presented to add this to the spec. There should
be a very compeling reason to be making changes so basic such as
adding new messages.

A couple of comments on the details above:

> Answer: Use it to inform that you are going to reset. Use
> immediately before the NOTIFICATION but, now can add
> PDU/ATTR/whatever to help debug.

How can that be of extra value given that notification allows you to
carry variable lenght data ? Adding this message is just going to
cause a debugging mess with all the deployed systems out there that do
not implement it.

> Question: Jeff Pickering Should a peer take any specific action upon
> reception of the INFORM?

Yes, reset the session, at least in the case that has been vastly
discussed in the list which is receicept of invalid nlri. Furtunatly
no code needs to be written to achieve that since it is the default
action on a receipt of an invalid message code.

  Pedro.

---

From: Russ White <[email-masked]>
Date: Fri, 19 Jul 2002 09:16:21 -0400 (EDT)

I think the inform message originally came from a desire to find
ways of _not_ resetting the session on simple, can be fixed
inline errors. It would provide you, as an implementor, and the
operators, based on your implementation, the option of doing
something _other_ than a session reset. What is done with the
information is clearly up to the operator and implementor....
Simple logging seems like a valuable enough thing to start with.

But simply adding the information should not be a big deal either
way.

:-)

Russ

> action on a receipt of an invalid message code.

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: [email-masked]
Date: Mon, 22 Jul 2002 07:38:52 -0700

Pedro,

As an operator, I think that there are a number of useful places for an 
INFORM message, as a mecahanism to pass information between BGP speakers
that does not result in a session reset.  Two that come to mind are:

1) Max-prefix.  Currently we only have the option of a hard max-prefix
limit.  With an INFORM we could create a hard and a soft limit.  When
a peer hits the soft limit, among other things, it sends them an INFORM
telling them so.  The peer could then look at the issue, and if the
route growth is legitimate, call us to ask that the limit be increased.
This would limit unnecessary peering session resets that do occur due
to normal route growth.

2) As-confed seq/set propogation.  Although, I do think the default
behavior upon receipt of a type 3/4 from a non-confed peer should be
a session reset, the fact remains that doing so is not a current option
due to the installed base (at least not as a default option).  Under 
the current behavior of existing code, routes with this inapproprate
information are ignored.  With an INFORM, we can tell a peer that
route x is being ignored because it contains an as-confed set/seq.
At least that way they know there is a problem, and there exists
an automated mechanism above and beyond trying to track down their
NOC.

I'm sure others can think of additional uses.  So long as we specify
that no protocol action is to be taken upon receipt of INFORMs, I believe
that the utility justifys implementing the functionality.

Andrew

On Thu, Jul 18, 2002 at 06:47:36PM -0700, Pedro Roque Marques wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Thu, 18 Jul 2002 18:47:36 -0700 (PDT)
> From: Pedro Roque Marques <[email-masked]>
> To: [email-masked]
> Subject: inform (was: IDR WG minutes IETF 54)
> In-Reply-To: <p05111a00b95d0a37ad7b@[133.93.77.124]>
> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
> Precedence: bulk
> X-OriginalArrivalTime: 19 Jul 2002 01:49:37.0068 (UTC) FILETIME=[89D5AEC0:01C22EC6]
> 
> David Ward writes:
>

---

From: Enke Chen <[email-masked]>
Date: Mon, 22 Jul 2002 15:45:33 -0700

Hi, David:
Some comments are in-lined.

> Message-Id: <p05111a00b95d0a37ad7b@[133.93.77.124]>
> Date: Thu, 18 Jul 2002 19:45:20 -0500
> To: [email-masked]
> From: David Ward <[email-masked]>
> Subject: IDR WG minutes IETF 54
> Cc: [email-masked]
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> Sender: [email-masked]
> Precedence: bulk
> 

> 			i. believes all clients must be fully meshed

Actually only clients at the same level need to be fully meshed to
guaratee route selection consistency. (We will make this clearer in the
next revision.)

Is this a real issue considering that is how many networks are
configured?

> 		b. Chen - not multi-level

Actually the mechanism does work with multi-level route reflection.
I did not finish this part before taking the vaction. This portion
will be revised in the next version.

> 		be removed from consideration.

Do not follow the comments by Alvaro and David on "does not solve
any/the problem". The essence of draft-chen-route-oscillation-avoid-00.txt
is to suggest:

    o advertising the best external path by a non-RR to IBGP (as
      in RFC 1771).

    o revising the RR behavior to remove advertisemnet dependence
      on IBGP updates.

The combination does solve the problem of route oscillation.

Admittedly the draft has some overlap with the "oscillation-reduce"
drafts, and we will consolidate the drafts in the next revision.

-- Enke

---

From: Alex Zinin <[email-masked]>
Date: Mon, 22 Jul 2002 18:13:42 -0700

David,

> II. Alvaro Retana presenter:
...

> QUESTION (Alex Zinin): What about detection mechanism?

I think it was probably someone else. I asked the presenters
to please summarize the discussion on the list, explaining
what issues have been raised, how they have been addressed and
what the remaining ones are.

>         draft-walton-bgp-add-paths-00.txt
...
>                 b. proposal is to change 3107 encoding to use new proposal

Add please:

Alex: If we have a problem in 3107, maybe we should fix it
Sue : 3107 is not in IDR

> III. Sue Hares presenter
...
>                 a. vote for adoption

I would change "vote" here to something like "show of hands to get the
feeling of the room" :)

>                         iii. few Chen

Might be useful to note the approximate number of hands
for ii and iii. If I recall correctly it was not more than
half a dozen for each.

Add here:

Sue : Need to take this to the list, as there's no clear
      consensus.

Thanks.
Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Jul 2002 11:53:16 -0400

On Mon, Jul 22, 2002 at 07:38:52AM -0700, [email-masked] wrote:
> that does not result in a session reset.

Pedro has convinced me that INFORM is a bad idea.  However, I still
have great sympathies for the operational issues.

In this light, I propose the following:
The bgp-mib-v2 is still only set in wet concrete (and is due for
the collected comments to be published).

How about if we add a counter/trap on a per-peer basis that reflects
conditions where the implementation is specifically ignoring routes
rather than dropping the peering session?  This will have to be 
worded carefully.

This will at least allow the router being "victimized" by the bad routes
to bring it to an operators attention.  The pushback mechanism
is no longer an INFORM message, rather its back to operators
giving the other operators a call.

-- 
Jeff Haas 
NextHop Technologies

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Fri, 26 Jul 2002 10:40:01 -0700

In addition I think it needs to be discussed how one can
mandate that actions should not be automated/taken on rcv'ing
an INFORM - I think it cannot be mandated. And a compliance 
check will also not be possible since not all implementations 
are open source :)

-
Chandra A.