[oam] Fwd: IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance

[Stan Ratliff <[e-mail]>]

Re-directing to [e-mail] as requested.

Regards,
Stan


Begin forwarded message:

> From: Ronald Bonica <[e-mail]>
> Date: August 22, 2010 7:10:01 PM EDT
> To: Stan Ratliff <[e-mail]>
> Subject: RE: IAB/IESG Joint Design Session on Forwarding Plane  
> Operations, Administration and Maintenance
>
> Stan,
>
> You might want to bring this discussion to [e-mail].
>
>                                                        Ron
>
>
> From: Stan Ratliff [mailto:[e-mail]]
> Sent: Sunday, August 22, 2010 2:32 PM
> To: Fred Baker
> Cc: Ron Bonica; Danny McPherson; Hannes Tschofenig; Stewart Bryant;  
> Stan Ratliff
> Subject: Re: IAB/IESG Joint Design Session on Forwarding Plane  
> Operations, Administration and Maintenance
>
> All,
>
> We have a draft that we've submitted to the MANET working group.  
> It's at https://datatracker.ietf.org/doc/draft-sratliff-dlep/. The  
> Data LInk Exchange Protocol (DLEP) was originally intended for  
> routers and radios to communicate in wireless networks, allowing  
> modem devices to generate events when a potential routing neighbor  
> is either found or is lost.
>
> That being said, a switch-based DLEP implementation could, as Fred  
> describes below, send messages to other devices in cases where  
> electrical connectivity is lost to some device, or a new device is  
> introduced - essentially, performing the same functionality as BFD,  
> but without the background ping traffic.
>
> Regards,
> Stan
>
>
> On Aug 22, 2010, at 8:11 AM, Fred Baker wrote:
>
>
> Question
>
>
> The scope of this design session is limited to the forwarding plane.  
> Proposals concerning control and management plane protocols will not  
> be accepted. For example, a proposal that probes a tunnel for  
> continuity would be acceptable, while a proposal for reporting  
> tunnel continuity to a routing protocol or management station would  
> be productive, but beyond the scope of this workshop.
>
> A tool that performs a keep-alive or make-dead function on a tunnel- 
> or-whatever seems marginally functional without the ability to  
> report its results to SOMETHING. I worry that you may find that this  
> constraint declares out-of-scope most useful tools.
>
> What we know how to do, and have done in the forwarding plane, is  
> ICMP. I would argue that BFD is largely an extension to ICMP in  
> concept, although it is implemented in UDP. It does the same  
> functions - it sends keep-alive messages in the form of pings to a  
> peer and observes the response. From my perspective, either we  
> continue with the "you can't talk with the network, only over it"  
> paradigm, or we look at a paradigm in which the network can itself  
> respond to questions. I think the latter is required if we want to  
> do anything that is recursive.
>
> An example of a paradigm in which the network might respond to  
> questions asks a lower-layer device, such as a switch, to advise an  
> upper-lawer device, such as a host or router attached to the switch,  
> for a specified indication of a specific kind of failure. For  
> example, the router could advise the switch that it is interested in  
> a given MAC address, one that perhaps happens to be in use by a peer  
> router, and ask the switch to advise it if the switch loses  
> connectivity to that MAC address. The switch would (somehow) put a  
> watch on the port the MAC address is associated with, and if  
> electrical connectivity is lost send a specified message to the  
> router within some stated interval. Such electrical loss would  
> protect against a hardware failure at the switch or in a connecting  
> cable without routers needing to poll each other at all. It would  
> not protect against forwarding plane failure in a peer, however;  
> other kinds of failures would still be primarily detected at the  
> same plane. There are obvious extensions for various inter-tube  
> technologies, including the notion of layering them on lower layer  
> networks or relaying such requests to peer - if the switch in the  
> example is connected to the MAC address via another switch, it could  
> ask the neighboring switch for such a message and remember to  
> forward it to the original requestor should it get one.
>
> I am copying Stan here because he made a related suggestion to me  
> last week. I have suggested to him that he propose it.
>
> I will not be in a position to attend the workshop for various  
> reasons, but might be interested to submit an internet draft to it.  
> Is something similar to the above of interest?
>
>
>
> -------- Original Message --------
> Subject:         IAB/IESG Joint Design Session on Forwarding Plane  
> Operations, Administration and Maintenance
> Date:  Fri, 20 Aug 2010 11:36:30 -0700 (PDT)
> From: IESG Secretary <[e-mail]>
> To:     IETF Announcement list <[e-mail]>
>
>
> The IAB and IESG would like to announce a joint design session on
> Forwarding Plane Operations, Administration and Maintenance (OAM) to  
> be
> held on October 12 through October 14 at George Mason University in
> Fairfax, Virginia, USA.
>
> IP and ICMP support very simple forwarding plane diagnostic tools  
> (e.g.,
> PING, TRACEROUTE). During the Internet's first decades, these tools
> fulfilled most operational requirements. However, during the last  
> decade,
> network operators have deployed many technologies that rely upon
> tunneling. These technologies include Pseudo-wires, Layer 2 Virtual
> Private Networks, and Layer 3 Virtual Private Networks. While the  
> internet
> community has enhanced its forwarding plane diagnostic tool kit with  
> the
> deployment of Bidirectional Forwarding Detection (BFD), some suggest  
> that
> the tool kit is still inadequate for tunneled applications.
>
> The purpose of this design session is to discover and document
> operational requirements and constraints for tunneled forwarding plane
> OAM. The design session will also entertain solution proposals.  
> While most
> activity in this area has been associated with Multi-Protocol Label
> Switching (MPLS), session organizers also encourage generic  
> proposals that
> include other tunneling mechanisms (e.g., IP-in-IP).
>
> The scope of this design session is limited to the forwarding plane.
> Proposals concerning control and management plane protocols will not  
> be
> accepted. For example, a proposal that probes a tunnel for continuity
> would be acceptable, while a proposal for reporting tunnel  
> continuity to a
> routing protocol or management station would be productive, but  
> beyond the
> scope of this workshop.
>
> Those intending to make presentations must submit position papers to  
> the
> IAB/IESG by September 24. Position papers should constitute one to  
> five
> pages on the problem or solution space, with a particular emphasis on
> areas that the IETF should address or revisit. Evaluation of the  
> position
> papers will be performed by a committee consisting of IESG and IAB
> members. A limited number of seats will be available for persons not
> presenting.
>
> Position papers will be made publicly available. On the basis of the
> position papers, a number of invited speakers will be asked to  
> present at
> the workshop. A final agenda with timeslots will be published by  
> October
> 1.
>
>
> Further information about position paper submission procedures are
> forthcoming. Interested parties are advised to subscribe to the oam at
>
> ietf.org
> mailing list for discussion and announcements related to the
> workshop. Additional information will be available at
>
> http://www3.tools.ietf.org/area/ops/trac/wiki/oamJDS
> .
>
> Ron Bonica, IESG
> Danny McPherson, IAB
> Hannes Tschofenig, IAB
> _______________________________________________
> IETF-Announce mailing list
>
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>