2.5.1 Routing Area Meeting (rtgarea)

Current Meeting Report

Routing Area Meeting IETF-58, 12/10/2003, Minneapolis

xxx indicates data lost by the note-taker

Administrivia (Bill)
        Welcome ccamp and mpls to rtg area
WG reports
    - bgmp (Bill)
      Plan was to publish experimental copy then shut the wg down.
      (semi-facetious) question - should we just do the latter?
    - ccamp (Common Control and Measurement Plane) (Adrian Farrell)
      just rechartered in Routing area
      5 drafts in rfc-ed queue
      new work being picked up
      main interesting issue is interaction w/ITU-T
    - forces (Forwarding and Control Plane Separation) ()
      <no update>
    - idmr (Internet Draft Multicast Remnants) (Bill)
      one document moved to magma
      DVMRP spec is the only remaining item.
            there was progress on security considerations so there is some 
hope of getting rid of it, too
    - idr (Inter-Domain Routing) (Sue Hares)
      Tied up details in the base spec
      Getting implementation reports in.
    - isis (IS-IS IGP) (Tony Li)
      Trying really hard not to do anything
    - manet (Mobile Ad-Hoc Nets) Joe/Scott
      No update
    - msdp (Multicast Source Discovery Protocol) (Bill)
      The MSDP spec was published as an RFC
      The MIB is republished and expected to have wg last call in its 
current form.
    - ospf (Open Shortest Path First IGP) (Acee)
      published ospf-te
      Will soon publish the graceful restart
      Informational draft on flooding reduction
      More drafts in the pipe
      wg last call for a using high order lsa option bit to prevent 
looping in rfc 2547 vpns
      will soon last call
           ospf v2 mib (one more spin needed)
           ospf v3 confidentiality and auth (IPSec and how to apply it, 
similar to ospf v2 auth)
      Will probably add
           multiple AF support for v3
           a couple TE drafts - extensions to existing TLVs
           one needs more discussion
           a new way of doing virtual links (tunnel adj draft) supports a 
link in > 1 area
      open discussion on incorporating manet requirements and figuring out 
the extensions and how they would impact OSPF
    - pim (Protocol Independent Multicast) (no update)
    - rpsec (Routing Protocol Security) (Tony)
           some AD comments to incorporate in generic threats doc then 
ready to ship
           people want to talk about anything else on the list
    - ssm (Source Specific Multicast) (Hugh)
           overview doc published as an rfc
           ssm-arch draft passed last call.  IPR issue to be discussed 
before advancing to IESG
           Discussion about admin scoping this week
    - udlr (Uni-Direction Link Routing) (not meeting) about to go 
quiescent working a lot on the experiments draft not much interest in 
advancing the UDLR doc to draft standard
    - vrrp (Virtual Router Redundancy Protocol) (no update)
    - mpls (Loa Andersson)
           two important things
           mib modules ready for IESG review
           management overview ready to go
           figuring out if they will take on the OAM work
BFD Status (Dave Ward)

<xxx scribe note, I could not copy down all of the text from the slides.  
see the online slides when they are posted>

    Base spec: has created three interoperable implementations, mostly done

    how to run bfd to test v4 and v6 control planes, bootstrap the proto

        ttl security guideline, port assignment and multiplexing.
        Another rev needed, but sufficient to create an 
interoperable implementation.

            bfd over unidirectional lsps for mpls failure detect
            doc still out for comment

            how to use pseudowire virtual circuit connection 

    known docs
        bfd over ethernet (for when there is no L3 interface)
        bfd as a fast failure detection for vrrp
        bfd as a generic failure detection replacement
            (# of people want to have 1 failure detection mechanism)
        Needs MIB for BFD

  Where is bfd in the IETF

    ADs have been asked to form a wg, but the # of folks working on it is 
really really small.  Due to the lack of activity, not sure if a wg is 
necessary.  Not much activity on the list.

    Goal is to take the shortest path to create interoperable 

    Although BFD is not a profound idea, there is value in reusing the 
technology vs. the infinite # of fast failure detection mechanisms that are 
being proposed everywhere
Multicast Last Mile (Keyur Patel)

      <XXX I was not able to copy down all the slides, please see the 
online slides when posted.>

      Followup on last-mile multicast bof from last time

      Keyur Patel, Greg Shepherd (Keyur presented)
      BoF held at last IETF
      work began on a draft to address issues raised at the bof
      protocol machinery in draft-keyur-amap-00.txt (a bit premature)
      mlm mailing list for broader consensus.
      a bunch of goals from the last mile bof
             independent of penetration
             leverage existing mcast when possible
             <xxx data loss here>

     Relevant work:
        (xxx more data loss)

     web page:

     mailing list:

Update on the rpo design team

    <xxx I could not copy down all the slides, again see online>

    At Vienna ietf there was a discussion about using routing 
protocols for non-routing functions.
    Design team was formed to document the considerations

    Dave Meyer summarized:
       high level model overview
       slides at: http://1-4-5.net/xxx (lost it here)


      focus on bgp but keep igps in scope
      Debate in Vienna on the use of bgp as a general transport 
      New class of applications e.g. 
      auto-discovery for l3vpns, virtual private lan services (VPLS, VPWS) 

    Model components: Risk, Interference, Application Fit

    Definition: Application:
        combination of a bgp data type and its signalling data
                ipv4 routing system
                flow spec/rules
                auto discovery mechanism for l3 vpns
                auto discovery mechanism for private lan services

    Definition: Risk
    Model robustness tradeoffs inherent in addition of new 
applications in a given implementation 
          - models impact of generic software engineering issues on an 
          - impact on existing implementations and fate sharing 
          - tradeoff between extending protocol vs designing, 
implementing, and deploying a new protocol

    Definition of Interference
    Potential for a new application to adversely affect the operation of an 
existing implementation at the protocol level 

    e.g. new state with a deadlock
         destabilize distributed protocol
         use up all the remaining bits

    Application Fit
	matching the requirements of the data to be distributed with the 
underlying capability of a distribution mechanism.

        e.g. broadcast, multicast, unicast

        so there are two models
           1) BGP as a generic transport mechanism (GPT) (data types and 
           2) BGP is a special purpose transport (SPT) for the 
inter-domain routing system

    GPT model
      - focuses on application fit and assumes the 
risk/interference tradeoffs can be managed using software 
engineering techniques

    SPT model
      - SPT is more sensitive to risk and interference

    ... the rest of the document.looks @ where the 2 models diverge. comes 
down to this: the demux point is where risk is assigned.  dave admits he 
didn't quite capture what kireeti wanted to say in the draft.
    (from a show of hands, not very many people in the room had read the 

    Question from Dave Meyer: Is this model useful?

         Q from Baruta (xxx)? (from MCI) - great way to approach it, but 
thought that too much credit is given to implementors.	 If it is a great 
implementation, then there is no problem, but from the IETF will you 
protect the ISPs buy making it easy for the not-so-good 

	 Dave Meyer: if you take software engineering out of scope, you get a much 
harder problem because other aspects of risk are really dwarfed by the 
implementation details

         Second question: how easy is it to rip out an extension if we  
decide it was not a good idea?

Tony When will we contend with the *actual* question?

Dave: trying to document the concerns, some people would say we already did 
contend with it with MBGP.
Yakov: GUP (generic unified protocol) - was documented around 1982 or 
1983.  Are you saying that the IETF should discuss whether software 
engineering is in the IETF mission?

Dave Meyer: Would rather not, but we always come back to this 
question. Someone else (ADs?) should decide whether it's in scope

Yakov:  Should this be added to the mission of the IETF mailing list? IETF is 
supposed to be a standards body and not a software engineering 
educational body.

Alex Zinin: Software engineering is not what we should be doing here, but 
considerations *related* to software engineering are reasonable to 

Dave Meyer: Software engineering risk is often considered in ops and 

Yakov: we should just add software engineering to the mission 
statement of the ietf and then we can do this.  (paraphrased)

kireeti kompella: I *E* TF Engineering (at least some kind) is within 
scope.  I think it's useful to consider risk.  If there is a protocol 
problem, we can solve it within the IETF.  If it's a software 
engineering problem, we can say "do a better implementation" but we don't 
necessarily have to invent a new protocol.

azinin: thanks to the design team for a lot of work, please read it.

Dave Meyer: read it for the framework, but not so much for the details.

Open Mike Time

<No comments, Adjourned after one hour>


None received.