Routing Area Meeting IETF-58, 12/10/2003, Minneapolis xxx indicates data lost by the note-taker -------------------------------- Administrivia (Bill) routing-discussion@ietf.org http://rtg.ietf.org 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> draft-katz-ward-bfd-01.txt Base spec: has created three interoperable implementations, mostly done draft-katz-ward-bfd-v4v6-1hop-00.txt 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. draft-raggarwa-mpls-bfd-00.txt bfd over unidirectional lsps for mpls failure detect doc still out for comment draft-ietf-pwe3-vccv-01.txt how to use pseudowire virtual circuit connection verification 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 implementations. 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: mboned-auto-mcast finlayson-xxx (xxx more data loss) web page: http://www.shepfarm.com/multicast/upim mailing list: http://www.shepfarm.com/mailman/listinfo/mtp -------------------------------- Update on the rpo design team draft-meyer-rpo-00.txt <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: What Who scope high level model overview questions slides at: http://1-4-5.net/xxx (lost it here) Who awduche bonica kilmer kompella chrlewis mcpherson meyer whiting Scope focus on bgp but keep igps in scope Debate in Vienna on the use of bgp as a general transport infrastructure New class of applications e.g. auto-discovery for l3vpns, virtual private lan services (VPLS, VPWS) etc. Model components: Risk, Interference, Application Fit Definition: Application: Application combination of a bgp data type and its signalling data e.g. 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 implementation - impact on existing implementations and fate sharing properties - 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 signalling) 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 draft) 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 implementors? 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 consider. Dave Meyer: Software engineering risk is often considered in ops and deployment 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> -------------------------------- |