Subject: grow: draft minutes from IETF 59

From: David Meyer <[email-masked]>
Date: Thu, 11 Mar 2004 13:24:49 -0800

Please send any comments, corrections, or additions to
	the list.

	Thanks,

	Dave & Geoff

----

Global Routing Operations WG (grow) Minutes for IETF 59

Thursday 04 Mar 2004    1300-1500
=================================

CHAIRS: Geoff Huston <[email-masked]>
        David Meyer  <[email-masked]>

Minutes recorded by Giles.Heron <[email-masked]>

Agenda
=======

  o Administriva                         5 minutes

    - Mailing list: [email-masked]
      subscribe grow

    - Scribe?

    - Blue Sheets

  o Agenda Bashing                       5 minutes

  o Status of Active Drafts              40 minutes

    - Med Considerations
      draft-ietf-grow-bgp-med-considerations-00.txt
      McPherson                          5 minutes

    - Embedding Globally ... Considered Harmful
      draft-ietf-grow-embed-addr-00.txt
      Plonka                             5 minutes

    - BGP Communities for Data Collection
      draft-ietf-grow-collection-communities-02.txt
      Meyer                              5 minutes

    - Operational Concerns and Considerations for Routing
      Protocol Design -- Risk, Interference, and Fit (RIFT)
      draft-ietf-grow-rift-00.txt
      Meyer, et al.                      25 minutes

  o Re-charter discussion                30 minutes
    Meyer/All

Minutes
=======
Administrivia/Agenda Bashing

Draft status:

draft-ietf-grow-bgp-med-considerations-00.txt:
   Danny McPherson not present at the meeting. It is planned to issue new
   version of this draft in March. Comments on the current draft should
   be sent to the author, via the grow mailing list, promptly. In the
   absence of further comments the revised document will be in WG last
   call.

draft-ietf-grow-embed-addr-00.txt:
   Dave Plonka is not present at the meeting. No comments have been
   posted on this draft. The chair proposed moving this document to WG
   last call, with no objections. The WG last call will be issued
   following this IETF meeting.

draft-ietf-grow-collection-communities-02.txt:
   BGP communities for data collection. It was noted that there are some
   changes in the -01 revision, and mostly editorial changes in the -02
   version. The chair proposed moving this document to WG last call, with
   no objections. The WG last call will be issued following this IETF
   meeting.

draft-ietf-grow-rift-00.txt:
   David Meyer indicated that this approach (RIFT) had been described in
   the routing area meeting, and was discussed in that venue. It is
   intended that the document be revised at least through one further
   iteration prior to WG last call.

Discussion on RIFT:

   Presentation by Dave Meyer:

   RIFT used to be called RPO (Routing Protocol Overload). The name
   seemed to be inhibiting the discussion, so it has been changed to
   RIFT.

   The discussion was around "fit". The Routing AD, Alex Zinin, had asked
   for a Design Team  to look at concerns around overloading Internet
   routing protocols with functions which weren't directly related to
   routing packets. The Design Team had not made much progress on
   definititions of "route", "packet" etc.

   The focus of RIFT is on BGP, but it is noted that IGPs are also in
   scope. The IETF 57 debate was interesting, as it did expose some
   concerns around the use of BGP as generalised feature transport
   mechanism. Some see this use as unhelpful, and offer the view that it
   will destablilise the network. This debate has intensified with
   additional functionality using BGP (e.g. signalling, auto-discovery,
   VPLS etc.)

   RIFT Framework:

     GPT = use BGP as a generic transport infrastructure.

     SPT = model BGP as special purpose transport for interdomain routing
     information.

   Both models assessed for Risk, Interference and Application fit.

   "Application" is defined as combination of BGP data type and
   associated signalling data. e.g. IPv4 routing system, L3 VPN, etc

   "Risk" is modelling of robustness tradeoffs. It is intended to include
   consideration of the impact of adding new applications to existing
   implementations, feature churn etc. Also there is a risk in tradeoff
   between extending existing protocol and designing a new one.

   It was reported that the Design Team struggled to reach any consensus.

   Multisession BGP fits in with this form of risk assessment reasonably
   well. There are three drafts on multisession.

   Imagine you have a model which lets you compete risk based on number
   of AFI/SAFI pairs.  If risk means anything at all then assume that the
   risk of the SPT model is bounded by the GPT model - else you can't
   argue for the SPT model.

   Assume number of AFI/SAFI for SPT model is small (e.g. 2 -
   unicast/multicast). That means that multisession BGP is trying to find
   a way to get GPT down to a similar risk profile to the SPT (by
   grouping the AFI/SAFI). Aim of multisession was to group AFI/SAFI and
   to then run in multiple processes. For small values of g (the size of
   the grouping) the risk profile looks like SPT. But there are other
   components of course - shared memory, process interactions etc.  So
   risk is trying to model what happens to an implementation when you add
   AFI/SAFIs to it.

   Interference is trying to model the potential for a new application to
   adversely affect the protocol level operation of an implementation.
   For example creating a new state with deadlocks or destablilising the
   distributed behaviour of BGP. So risk is at implementation level and
   interference is at protocol level.

   Nobody has said anything about risk or interference. The
   contentiousness comes with fit.

   Application fit is matching requirements of the data to be distributed
   to the underlying capabilities of the distribution mechanism. e.g.
   broadcast, multicast and unicast distr.

   We're at the 3rd attempt to organise this section. First couple of
   times looked at solutions instead of issues/problems. Version now has
   assertions and counter-assertions (as that was what was going on in
   the discussions). This is an unbounded set - everyone has their own
   ideas as to what fit looks like. From discussions today maybe should
   try to organise this around issues.

     Dimitri Papadim - the assertions/counter assertions section seems
     hard to evaluate.

     David Meyer - this doc isn't supposed to conclude rightness vs
     wrongness on these 3 attributes, but to document the issues as they
     are. That's why have tried different structures to try and get at
     this.

     Kurtis Lindqvist - the way the assertions and counter-assertions are
     written doesn't give explanation of why people are arguing the way
     they are. if you read doc as such it's hard to make top text fit
     assertions. Perhaps broaden it a bit so people can understand why
     people are arguing one way or the other.

     Luca Martini - perhaps this is because one vendor is trying to get
     at another vendor. Several counter assertions are missing.

     David Meyer - It was easier to get one side of this than the n-1
     other sides. People on the committee need to help contribute this
     stuff.

     David Meyer - example of assertion #3. Almost a transcript of what
     happened in the design team.  The VPWS application is not a good fit
     for BGP. Based on the assertion that BGP is poorly suited to VPWS
     signalling requirements because PWs are inherently P2P. Attributes
     are per-wire, as compared to routing or auto-discovery where you
     want info to go everywhere. Suppose you use an RR you have to send
     union of all the attributes to the RR. So message is n times as
     large, and RR has to send the n messages to each endpoint.

   Counter assertion is that it is a good fit because the RR only needs
   to distribute a label range. This gets round the size of the setup
   message so it isn't really n times larger. Only per wire info will be
   bigger.

     Kireeti Kompella - especially when k = 0 (per wire info).

     Yakov Rekhter - fails to recognise that VPLS (or any other
     application) has signalling as one (but not the only) component.
     This discussion fails to look at system-wide implications.

     Kireeti Kompella - an analysis of the ops impact of two protocols
     rather than one is also interesting in this context.

     Luca Martini - we have strong indication that most of these L2
     services won't be running on devices which also run Internet
     routing, so the two protocols argument doesn't hold.

   Counter-counter assertion. Label ranges are efficient if and only if:

     1) a large enough label range is pre-allocated to accomnodate all
     the systems you might ever add to the VPLS/VPWS (assuming no service
     interruption is acceptable)

     2) there is no per-wire info other than labels that needs to be
     distributed.

   Basically the argument goes that as soon as you want to send some per-
   wire status or info (e.g. MTU size) then you've got problems. Also
   argued this is a waste of label space and that it fragments the label
   space. May make debugging harder. Also may be sub-optimal for non
   fully-meshed topologies.

     Luca Martini - found out at Level3 that MTU was very helpful in
     detecting mis-matches.

     Kireeti Kompella - in the case of VPLS only have one MTU

     Vach Kompella - assuming with VPWS that all PWs are the same type.
     We're worried about transitions where one PW might be IP only
     Ethernet-Frame, another might be something else. Even if Ethernet
     have two types of encaps. Some router vendors haven't done both
     kinds. Not that there isn't per-wire info, but that there is and
     we'll get into it as soon as we start deploying this stuff.

     Vach Kompella - how do we add to asserts/counter asserts.

     David Meyer - send to list.

     Kireeti Kompella - the guys who made this comment don't understand
     label ranges. Ranges can come in chunks - so can allocate a few
     labels and then add a range. So it depends on how you want to do
     label block allocation. In LDP you must have 100 messages for 100
     sites. For BGP the best case is 1. We do labels in blocks of 8 or
     16. We have deployments of this.

     Yakov Rekhter - people who made certain claims fail to understand
     what they are analysing. Making assertions based on random
     assertions.

     Rahul Aggrawal - one comment on wasted label space. Look at other
     places where they're allocated (e.g. 2547). in 2547 if you do per
     interface labels you're wasting them.

     Luca Martini - can we have example of system wide analysis?

     Yakov Rekhter - VPLS has auto-discovery and signalling. This is all
     signalling. Where is discovery on auto-discovery?

     Kireeti Kompella - in new version of draft explain how path
     selection is done. RR scaling is really powerful when you go inter-
     AS. For LDP is M * N mesh across two ASes. With BGP you multihop it
     just as for 2547. My point is that about fit are we screwing up BGP
     by using it as a transport. Nothing to do with label ranges. In
     doing VPLS or VPWS we've changed nothing in the way BGP distributes
     things. Component per NLRI. When you do attribute filtering, add AS
     paths, check for loops, advertise to peer groups - all of that is
     the same. NLRI is just an opaque bit-string and is only looked at
     when you want to install routes or do path selection. When you talk
     about application fit - application is application of info for VPLS
     or VPWS. Haven't changed anything in BGP - it's just what we're
     carrying. Think of BGP as a big switch to carry common stuff and
     then AFI/SAFI stuff. Most changes are inside the switch. For 2547
     main changes were for constrained filtering. Works without change
     for VPLS. For meta question - what is all this about, BGP
     distribution mechanisms vs application requirements this analysis is
     off in the weeds.

     David Meyer - don't disagree on that. Talked to a few people this
     morning.

     Yakov Rekhter - if you want to keep this section then you need to
     say that it makes no claim for validity of assertions or counter
     assertions.

     David Meyer - I was looking for different approach. This one didn't
     work either. Right approach is more along lines of what Kireeti was
     saying. Need to uplevel a couple of levels, say "these are some
     issues" and leave it at that. Would it need to be more detailed than
     that to be useful? My sense is that this has diminishing returns.
     Will write something much shorter and more abstract. Can do that
     pretty easily. Kireeti will help.

     Yakov Rekhter - mustn't constrain to BGP. People extend other
     protocols as well - e.g. ISIS.

     David Meyer - suggestions on how to do this?

     Yakov Rekhter - can have pointers to drafts which extend OSPF and
     ISIS.

     Vach Kompella - If you uplevel one or two levels the debate might
     end up not being heated, but also may not yield results. What is the
     end-goal of this thing? Is it to say "people want to change
     protocols and we need to see if there's a fit" or are we going to
     take specific protocols and say why specific changes do/don't fit.
     If we don't get useful result from going uplevel then I don't get
     the point of the whole argument.

     Kireeti Kompella - one reason it's useful. we've had consensus for
     both BGP and LDP in L2VPN. The issues around BGP overload mean the
     people who'd like to use BGP are asking "why is this wrong, why are
     some vendors not doing this". If you say "here are the issues" they
     can read this and make their own decision. It's not a question of X
     or Y, it's a question of what am I getting myself into if I pick X.
     The series of arguments and counter-arguments makes it hard to see
     real issues. Real question is "if I add this stuff to BGP then have
     I fundamentally changed the protocol".

     Vach Kompella - I'm asking for an AS applicability statement. That
     draft should say "here's the applicability of BGP to this". If your
     network matches those criteria then it fits. But doesn't address
     does this break BGP, or LDP, or OSPF. If those are the issues you're
     concerned about you have to come up with a better way of expressing
     that than assertions/counter assertions.

     Yakov Rekhter - that's why we need to change this.
     Assertions/counter assertions goes nowhere. Let's focus on what are
     the issues.

     David Meyer - we'll do that. Want to get that done, get it onto the
     list, have discussion, do WG last call, and get on with it. Can do
     in a month.

     Kurtis Lindqvist - The other question in my mind is what do you plan
     to do with the doc once published?

     David Meyer - supposed to be informational

     Kurtis Lindqvist - but what is it for. Explains issues and how we
     got here. I like assertions/counter assertions as lets you know why
     this doc is being published. If you take that out you lose a lot of
     the value in the doc.

     David Meyer - we could compromise on an appendix with the disclaimer
     Yakov Rekhter mentioned.

     Yakov Rekhter - it's an embarassment to publish an RFC with claims
     that may have no validity at all. Need to think about self-respect.

     Kurtis Lindqvist - I can agree with Yakov, but we need some way to
     reflect why we published this at all.

     Kireeti Kompella - people want to know what goes wrong if we use
     BGP. If we do an accurate job of defining issues without the fight
     on either side then SPs can make their own choice.

     Yakov Rekhter - e.g. of proposal of using RSVP-TE to signal P2MP TE
     LSPs. This doc can be used as is to show tradeoffs between PIM and
     RSVP-TE without getting into debates, assertions and counter-
     assertions.

     Kurtis Lindqvist - I prefer what Yakov has said to what Kireeti has
     said. Saying something slightly different.

     Kireeti Kompella - Yakov expresses it better but think he's saying
     the same.

     David Meyer - Kireeti and I will get the new draft up and if poss
     we'll WG last call and be done with it.

     Rahul Aggrawal - need to note the proposal in MPLS WG to add stuff
     to OSPF.

Other drafts
------------

   Bounded LPM was rejected.

Charter update
--------------

   IESG looking at this. Operating without for now. Dropped milestones and 
some items that were inherited from PTOMAINE.

   (1) First goal is to find ways of reducing effect of prefix
       subaggregates to reduce NLRI load.

   (2) MED issue.

   (3) Effects of BGP as edge-to-edge signalling

   (4) Effects of interaction with TE etc. on BGP. How do we
       isolate global infrastructure from such effect.

Discussion on (4)
   Yakov Rekhter - shouldn't we look at IGP itself on goal 4 rather
   than BGP.

   David Meyer - we were thinking of BGP when we wrote this.

   Yakov Rekhter - if IGP doesn't work then BGP doesn't either.

   David Meyer - do we have lattitude to discuss this and work on it
   before next telechat?

   David Kessens - Yes. You can discuss anything, BUT this WG has to
   work not on IGPs. Interaction OK.

   Yakov Rekhter - are you saying we should only work on BGP.

   David - OK to deal with interaction but not on IGPs.

   Yakov Rekhter - routing systems have IGP and BGP. Just like
   ignoring auto-discovery in VPLS.

   David Kessens - have to draw the line somewhere. if you have good
   args to change then we'll listen.

   Yakov Rekhter - isn't it obvious that to make BGP work you need the
   IGP to work? If you talk about impact of ISIS-TE on routing system
   then you need to look at ISIS first, not BGP.

   Alex Zinin - common ground. What Yakov's saying is covered here.
   Interaction between TE extensions and BGP happens _through_ ISIS.

   Yakov Rekhter - so why not state this in charter.

   Alex Zinin - need to send mail to WG chairs.

   Yakov Rekhter - does chair disagree.

   David Meyer - I don't. Just worried about procedure.

   David Kessens - let's not focus on procedure but on getting it right.

   David Meyer - will take it as an action item to work on that
   milestone.

   David Kessens - will help if can be done this week as am not in next
   week. Faster the better.

   Yakov Rekhter - question on item 3. How do you plan to determine the
   effects of using BGP on the scalability of BGP. Is it just a wish-list
   or do we have a specific plan?

   David Meyer - No, don't have a plan.

   Yakov Rekhter - can someone tell me the plan?

   Bill Fenner - The RIFT stuff is a beginning of this. I think of
   it more as analysis. Can always deploy the wrong thing and
   measure the wrong thing. Analysis like RIFT lets you talk about
   things based on analysis.

   Yakov Rekhter - analysis of what?

   David Meyer - RIFT was supposed to cover item 3.

   Bill Fenner - charter item pre-dates RIFT.

   Yakov Rekhter - you should look at rfc2547bis as it looks at
   scalability.

   David Meyer - I'm taking away action to rework item 4 by end of week.

   Yakov Rekhter - what about 3? If that's what you mean then you
   can mark it as done, as rfc2547bis analyses scalability. What
   else do you have in mind?

   David Meyer - I think that one was put in to charter to cover RIFT and
   GROW.

   Bill Fenner - if we have better way to describe RIFT work then
   that's fine.

   David Meyer - I need new text for 3 and 4 and will get that to
   ADs by end of week.

   Bill Fenner - I think 3 is fine, but apparently it raises
   hackles.

   Kireeti Kompella - don't think RIFT really covers this.

   Bill Fenner - maybe we need a fifth item to cover RIFT.

   Kireeti Kompella - I like RIFT. But talking about scalability there's
   other stuff not covered in RIFT - like how much data is in BGP, what's
   the volatility of this data. Scalability is a different dimention of
   risk. RIFT just covers static aspects. What happens to BGP when it
   carries 1M prefixes? What is the difference if 10 prefixes change per
   second vs 10K?

   David Meyer - there was a discussion as to whether or not RIFT was in-
   scope for GROW. Writing milestones and goals for an ops group is
   different to a protocol group. Trying to dis-ambiguate the situation
   with RIFT.

   Yakov Rekhter - why does item 3 only look at BGP as signalling. What
   about auto-discovery.

   Bill Fenner - confusion over word signalling. In this context it means
   "that which is not IP reachability".

   Yakov Rekhter - need to tighten language.

   Bill Fenner - OK. Lot of argument when RIFT began as to "what is non-
   routing information". That's why wording evolved. Has evolved in
   direction which is not write.

   Alex Zinin - editorial issues better handled on mailing list. Post new
   charter to list and let people comment.

   David Meyer - what do other ADs think?

   David Kessens - fine, let's just get it done. No nitpicking.

Charter:

   (5) document operational aspect of routing security and provide
   recommendations to other groups.

Discussion on (5):
   Yakov Rekhter - is this routing infrastructure, or routing
   protocols, or both?

   David Meyer - this is ops group so is both.

   Sue Hares - infrastructure includes RPSL etc., not just protocols.
   Human beings are part of this. Are you going to look at RPSL and ops?

   David Meyer - I would imagine that ops issues around RPSL would
   live here.

   Sue Hares - RPSL is just an example, but you want to look at
   infrastructure.

   Bill Fenner - my concern here is that enumerating every aspect we're
   interested in risks missing one. Trying to say any operational aspect
   of security in routing system is in scope.

   Alex Zinin - security of routing protocols belongs in routing area.
   we're documenting operational aspects of routing security.

   Yakov Rekhter - should be operational aspects of securing the
   routing system

   David Kessens - send text and stop nitpicking.

Status update on WG.

   (Geoff has had to leave the meeting due to illness.)

   Bert sent message to list. Vijay resigned, and Geoff has come on.
   Vijay will be tech advisor, as is Bill. David is our AD. Will be some
   changes to the charter as we've discussed.

   David - first post to list. Longer discussion takes the longer will
   take. Realistically this won't all get done this week. Needs to be
   done by Thursday next week. Bit of a complication as David not there
   next week and Bert travelling.

   David Meyer - Kireeti and I taking an action item. I will post new
   charter by Monday.

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/