Re: [Last-Call] Opsdir telechat review of draft-ietf-detnet-ip-oam-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Yingzhen,
thank you for your thoughtful suggestions that helped alot in improving the document. I like shorter sentences; they make text clearer. Both text updates accepted and are in the working version (attached).

Best regards,
Greg

On Wed, Feb 14, 2024 at 8:39 AM Yingzhen Qu <yingzhen.ietf@xxxxxxxxx> wrote:
Hi Greg,

Thanks for the reply. Please see my answers below inline.

Thanks,
Yingzhen


On Tue, Feb 13, 2024 at 9:48 PM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:
Hi Yingzhen,
thank you for your kind words in support of this work; much appreciated. Please find my notes below tagged GIM>>.

Regards,
Greg

On Tue, Feb 13, 2024 at 8:09 PM Yingzhen Qu via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Yingzhen Qu
Review result: Ready

I've reviewed version 10, and this is a follow up review.

Thanks to the authors for working on this document and addressing my comments.

The document readability has improved a lot from my last review of version -10,
and I believe it is ready for publication.

There are a couple of nits for the authors to consider.

The line numbers are generated using idnits.

160        is being done by using the Internet Control Message Protocol (ICMP)

nits: there should be a "." in the end.
GIM>> It seems like the long sentence may confuse a reader:
   Most of on-demand failure detection and localization in IP networks
   is being done by using the Internet Control Message Protocol (ICMP)
   Echo Request, Echo Reply and the set of defined error messages, e.g.,
   Destination Unreachable, with the more detailed information provided
   through code points.
The intention is to note that Echo Request/Reply that are the mechanism used in ICMP are the common method for on-demand failure detection and localization, i.e., of ping and traceroute. Would a slight re-wording make it clearer:
NEW TEXT:
   Most of on-demand failure detection and localization in IP networks
   is being done by using the Internet Control Message Protocol's (ICMP)
   Echo Request, Echo Reply, and the set of defined error messages, e.g.,
   Destination Unreachable, with the more detailed information provided
   through code points.
WDYT?

[Yingzhen]: Now I see I did break the long sentence wrong. Fortunately the message of the sentence was still delivered correctly. Here is my suggestion:
In IP networks, the majority of on-demand failure detection and localization is achieved through the use of the Internet Control Message Protocol (ICMP), utilizing Echo Request and Echo Reply messages, along with a set of defined error messages such as Destination Unreachable, which provide detailed information through assigned code points.


166        traffic between DetNet nodes with IP DetNet traffic, e.g., ensure
167        that such ICMP traffic uses the DetNet IP data plane in each node,

nits: somehow this sentence doesn't read well to me. "uses the DetNet IP
data plane" is not very clear to me, I think you're trying to say ICMP traffic
should go through the same path/interface as DetNet traffic, for example,
there is ECMP between two DetNet nodes.
GIM>> Thank you for pointing this to me. You are correct, the intention is to stress the importance of ensuring that ICMP packets traverse the same set of nodes and interfaces and receieve the same QoS treatment as the monitored DetNet IP flow. I propose the following update:
OLD TEXT:
   In order to use ICMP for these
   purposes with DetNet, DetNet nodes must be able to associate ICMP
   traffic between DetNet nodes with IP DetNet traffic, e.g., ensure
   that such ICMP traffic uses the DetNet IP data plane in each node,
   otherwise ICMP may be unable to detect and localize failures that are
   specific to the DetNet IP data plane.
 NEW TEXT:
   In order to use ICMP
   for these purposes with DetNet, DetNet nodes must be able to
   associate ICMP traffic between DetNet nodes with IP DetNet traffic,
   i.e., ensure that such ICMP traffic traverses the same interfaces and
   receives the same QoS treatment as the monitored DetNet IP flow;
   otherwise, ICMP may be unable to detect and localize failures that
   are specific to the DetNet IP data plane.
What are your thoughts? Is the text more clear now?

[Yingzhen]:  The new text is definitely more clear. Here is my suggestion, and it's up to you to decide whether to use it or not.
To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuring that such ICMP traffic traverses the same interfaces and receives identical QoS treatment as the monitored DetNet IP flow. Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane. 



DetNet Working Group                                           G. Mirsky
Internet-Draft                                                  Ericsson
Intended status: Informational                                   M. Chen
Expires: 17 August 2024                                           Huawei
                                                                D. Black
                                                                Dell EMC
                                                        14 February 2024


  Operations, Administration, and Maintenance (OAM) for Deterministic
                  Networks (DetNet) with IP Data Plane
                      draft-ietf-detnet-ip-oam-13

Abstract

   This document discusses the use of existing IP Operations,
   Administration, and Maintenance protocols and mechanisms in
   Deterministic Networking networks that use the IP data plane.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Mirsky, et al.           Expires 17 August 2024                 [Page 1]

Internet-Draft           OAM for DetNet over IP            February 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Active OAM for DetNet Networks with the IP Data Plane . . . .   3
     3.1.  Mapping Active OAM and IP DetNet flows  . . . . . . . . .   4
     3.2.  Active OAM Using IP-in-UDP Encapsulation  . . . . . . . .   5
     3.3.  Active OAM Using DetNet-in-UDP Encapsulation  . . . . . .   5
     3.4.  The Application of Y.1731/G.8013 Using GRE-in-UDP
           Encapsulation . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Active OAM for DetNet IP Interworking with OAM of non-IP DetNet
           domains . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informational References  . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [RFC8655] introduces and explains Deterministic Networks (DetNet)
   architecture.

   Operations, Administration, and Maintenance (OAM) protocols are used
   to detect and localize defects in the network as well as to monitor
   network performance.  Some OAM functions (e.g., failure detection),
   work in the network proactively, while others (e.g., defect
   localization) are usually performed on-demand.  These tasks are
   achieved by a combination of active and hybrid OAM methods, as
   defined in [RFC7799].

   [I-D.ietf-detnet-oam-framework] lists the OAM functional requirements
   for DetNet, and defines the principles for OAM use within DetNet
   networks utilizing the IP data plane.  The functional requirements
   can be compared against current OAM tools to identify gaps and
   potential enhancements required to enable proactive and on-demand
   path monitoring and service validation.



Mirsky, et al.           Expires 17 August 2024                 [Page 2]

Internet-Draft           OAM for DetNet over IP            February 2024


   This document discusses the use of existing IP OAM protocols and
   mechanisms in DetNet networks that use the IP data plane.

2.  Conventions used in this document

2.1.  Terminology

   The term "DetNet OAM" used in this document interchangeably with
   longer version "set of OAM protocols, methods and tools for
   Deterministic Networks".

   DetNet: Deterministic Networks

   OAM: Operations, Administration, and Maintenance

   ICMP: Internet Control Message Protocol

   Underlay Network or Underlay Layer: The network that provides
   connectivity between DetNet nodes.  MPLS networks providing LSP
   connectivity between DetNet nodes are an example of the DetNet IP
   network underlay layer.

   DetNet Node: a node that is an actor in the DetNet domain.  DetNet
   domain edge nodes and nodes that perform the Packet Replication and
   Elimination Function within the domain are examples of a DetNet node.

3.  Active OAM for DetNet Networks with the IP Data Plane

   OAM protocols and mechanisms act within the data plane of the
   particular networking layer.  Thus, it is critical that the data
   plane encapsulation supports OAM mechanisms and enables them to be
   configured so that DetNet OAM packets follow the same path
   (unidirectional or bidirectional) through the network and receive the
   same forwarding treatment in the DetNet forwarding sub-layer as the
   DetNet flow being monitored.

   The DetNet data plane encapsulation in a transport network with IP
   encapsulations is specified in Section 6 of [RFC8939].  For the IP
   underlay network, DetNet flows are identified by the ordered match to
   the provisioned information set that, among other elements, includes
   the IP protocol, source port number, destination port number.  Active
   IP OAM protocols like Bidirectional Forwarding Detection (BFD)
   [RFC5880] or Simple Two-way Active Measurement Protocol (STAMP)
   [RFC8762], use UDP transport and the well-known UDP port numbers as
   the destination port.  For BFD, the UDP destination port is specific
   to the BFD variant, e.g., Multihop BFD uses port 4784 [RFC5883].





Mirsky, et al.           Expires 17 August 2024                 [Page 3]

Internet-Draft           OAM for DetNet over IP            February 2024


   Thus a DetNet node must be able to associate an IP DetNet flow with
   the particular test session to ensure that test packets experience
   the same treatment as the DetNet flow packets.  For example, in a
   network where path selection and DetNet functionality are based on
   3-tuples (destination and source IP addresses in combination with the
   Differentiated Services Code Point value) that association can be
   achieved by having the OAM traffic use the same 3-tuple as the
   monitored IP DetNet flow.  In such a scenario, an IP OAM session
   between the same pair of IP nodes would share the network treatment
   with the monitored IP DetNet flow regardless of whether ICMP, BFD, or
   STAMP protocol is used.

   In IP networks, the majority of on-demand failure detection and
   localization is achieved through the use of the Internet Control
   Message Protocol (ICMP), utilizing Echo Request and Echo Reply
   messages, along with a set of defined error messages such as
   Destination Unreachable, which provide detailed information through
   assigned code points.  [RFC0792] and [RFC4443] define the ICMP for
   IPv4 and IPv6 networks, respectively.  To utilize ICMP effectively
   for these purposes within DetNet, DetNet nodes must establish the
   association of ICMP traffic between DetNet nodes with IP DetNet
   traffic.  This entails ensuring that such ICMP traffic traverses the
   same interfaces and receives identical QoS treatment as the monitored
   DetNet IP flow.  Failure to do so may result in ICMP being unable to
   detect and localize failures specific to the DetNet IP data plane.

3.1.  Mapping Active OAM and IP DetNet flows

   IP OAM protocols are used to detect failures (e.g., BFD [RFC5880])
   and performance degradation (e.g., STAMP [RFC8762]) that affect an IP
   DetNet flow.  It is essential to ensure that specially constructed
   OAM packets traverse the same set of nodes and links and receive the
   same network QoS treatment as the monitored data flow, e.g., a DetNet
   flow, for making active OAM useful.  When the UDP destination port
   number used by the OAM protocol is assigned by IANA, then judicious
   selection of the UDP source port may be able to achieve co-routedness
   of OAM with the monitored IP DetNet flow in multipath environments,
   e.g., Link Aggregation Group or Equal Cost Multipath, via use of a
   UDP source port value that results in the OAM traffic and the
   monitored IP DetNet flow hashing to the same path based on the packet
   header hashes used for path selection.  This does assume that
   forwarding equipment along the multipath makes consistent hashing
   decisions, which might not always be true in a heterogeneous
   environment.  (That also applies to encapsulation techniques
   described in Section 3.2 and Section 3.3.)  To ensure the accuracy of
   OAM results in detecting failures and monitoring the performance of
   IP DetNet, it is essential that test packets not only traverse the
   same path as the monitored IP DetNet flow but also receive the same



Mirsky, et al.           Expires 17 August 2024                 [Page 4]

Internet-Draft           OAM for DetNet over IP            February 2024


   treatment by the nodes, e.g., shaping, filtering, policing, and
   availability of the pre-allocated resources, as experienced by the IP
   DetNet packet.  That correlation between the particular IP OAM
   session and the monitored IP DetNet flow can be achieved by using
   DetNet provisioning information (e.g., [I-D.ietf-detnet-yang]).  Each
   IP OAM protocol session is presented as a DetNet Application with
   related service and forwarding sub-layers.  The forwarding sub-layer
   of the IP OAM session is identical to the forwarding sub-layer of the
   monitored IP DetNet flow, except for information in the grouping ip-
   header, defined in [I-D.ietf-detnet-yang].

3.2.  Active OAM Using IP-in-UDP Encapsulation

   As described above, active IP OAM is realized through several
   protocols.  Some protocols use UDP transport, while ICMP is a
   network-layer protocol.  The amount of operational work mapping IP
   OAM protocols to the monitored DetNet flow can be reduced by using an
   IP/UDP tunnel to carry IP test packets ([RFC2003]).  Then, to ensure
   that OAM packets traverse the same set of nodes and links, the IP/UDP
   tunnel must be mapped to the monitored DetNet flow.  Note that the
   DetNet domain for the test packet is seen as a single IP link in such
   a case.  As a result, transit DetNet IP nodes cannot be traced using
   the usual traceroute procedure, and a modification of the traceroute
   may be required.

3.3.  Active OAM Using DetNet-in-UDP Encapsulation

   Active OAM in IP DetNet can be realized using DetNet-in-UDP
   encapsulation.  Using DetNet-in-UDP tunnel between IP DetNet nodes
   ensures that active OAM test packets follow the same path through the
   network as the monitored IP DetNet flow packets and receive the same
   forwarding treatment in the DetNet forwarding sub-layer (see
   Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored.

   [I-D.ietf-detnet-mpls-over-ip-preof] describes how DetNet with MPLS
   over UDP/IP data plane [RFC9025] can be used to support Packet
   Replication, Elimination, and Ordering Functions to potentially lower
   packet loss, improve the probability of on-time packet delivery and
   ensure in-order packet delivery in IP DetNet's service sub-layer.  To
   ensure that an active OAM test packet follows the path of the
   monitored DetNet flow in the DetNet service sub-layer the
   encapsulation shown in Figure 1 is used.









Mirsky, et al.           Expires 17 August 2024                 [Page 5]

Internet-Draft           OAM for DetNet over IP            February 2024


         +---------------------------------+
         |                                 |
         |         DetNet App-Flow         |
         |       (original IP) Packet      |
         |                                 |
         +---------------------------------+ <--\
         |            DetNet ACH           |    |
         +---------------------------------+    +--> PREOF capable
         |       Service-ID (S-Label)      |    |    DetNet IP data
         +---------------------------------+    |    plane encapsulation
         |            UDP Header           |    |
         +---------------------------------+    |
         |            IP Header            |    |
         +---------------------------------+ <--/
         |            Data-Link            |
         +---------------------------------+
         |             Physical            |
         +---------------------------------+

             Figure 1: DetNet Associated Channel Header Format

   where:

      DetNet ACH is the DetNet Associated Channel Header defined in
      [I-D.ietf-detnet-mpls-oam].

      PREOF - Packet Replication, Elimination, and Ordering Functions if
      DetNet service sub-layer defined in [RFC8655].

3.4.  The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation

   [RFC8086] has defined the method of encapsulating GRE (Generic
   Routing Encapsulation) headers in UDP.  GRE-in-UDP encapsulation can
   be used for IP DetNet OAM as it eases the task of mapping an OAM test
   session to a particular IP DetNet flow that is identified by N-tuple.
   Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables
   the use of Y.1731/G.8013 [ITU-T.1731] as a comprehensive toolset of
   OAM.  The Protocol Type field in GRE header must be set to 0x8902,
   assigned by IANA to IEEE 802.1ag Connectivity Fault Management (CFM)
   Protocol / ITU-T Recommendation Y.1731.  Y.1731/G.8013 supports the
   necessary functions required for IP DetNet OAM, i.e., continuity
   check, one-way packet loss and packet delay measurement.









Mirsky, et al.           Expires 17 August 2024                 [Page 6]

Internet-Draft           OAM for DetNet over IP            February 2024


4.  Active OAM for DetNet IP Interworking with OAM of non-IP DetNet
    domains

   A domain in which IP data plane provides DetNet service could be used
   in conjunction with a TSN and a DetNet domain with MPLS data plane to
   deliver end-to-end service.  In such scenarios, the ability to detect
   defects and monitor performance using OAM is essential.
   [I-D.ietf-detnet-mpls-oam] identified two OAM interworking models -
   peering and tunneling.  Interworking between DetNet domains with IP
   and MPLS data planes analyzed in Section 4.2 of
   [I-D.ietf-detnet-mpls-oam].  In addition, OAM interworking
   requirements and recommendations that apply between a DetNet Domain
   with the MPLS dataplane and an adjacent TSN network also apply
   between a DetNet domain with the IP dataplane and an adjacent TSN
   network.

5.  IANA Considerations

   This document does not have any requests for IANA allocation.  This
   section can be deleted before the publication of the draft.

6.  Security Considerations

   This document describes the applicability of the existing Fault
   Management and Performance Monitoring IP OAM protocols.  It does not
   raise any security concerns or issues in addition to ones common to
   networking or already documented in [RFC0792], [RFC4443], [RFC5880],
   and [RFC8762] for the referenced DetNet and OAM protocols.

7.  References

7.1.  Normative References

   [I-D.ietf-detnet-mpls-oam]
              Mirsky, G., Chen, M., and B. Varga, "Operations,
              Administration and Maintenance (OAM) for Deterministic
              Networks (DetNet) with MPLS Data Plane", Work in Progress,
              Internet-Draft, draft-ietf-detnet-mpls-oam-15, 12 January
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              detnet-mpls-oam-15>.

   [I-D.ietf-detnet-yang]
              Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li,
              "Deterministic Networking (DetNet) YANG Model", Work in
              Progress, Internet-Draft, draft-ietf-detnet-yang-19, 25
              January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-detnet-yang-19>.




Mirsky, et al.           Expires 17 August 2024                 [Page 7]

Internet-Draft           OAM for DetNet over IP            February 2024


   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              DOI 10.17487/RFC2003, October 1996,
              <https://www.rfc-editor.org/info/rfc2003>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC8086]  Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
              in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
              March 2017, <https://www.rfc-editor.org/info/rfc8086>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
              <https://www.rfc-editor.org/info/rfc8939>.

   [RFC9025]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
              2021, <https://www.rfc-editor.org/info/rfc9025>.

7.2.  Informational References

   [I-D.ietf-detnet-mpls-over-ip-preof]
              Varga, B., Farkas, J., and A. G. Malis, "Deterministic
              Networking (DetNet): DetNet PREOF via MPLS over UDP/IP",
              Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-
              over-ip-preof-09, 8 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              mpls-over-ip-preof-09>.

   [I-D.ietf-detnet-oam-framework]
              Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos,
              C. J., Varga, B., and J. Farkas, "Framework of Operations,
              Administration and Maintenance (OAM) for Deterministic
              Networking (DetNet)", Work in Progress, Internet-Draft,



Mirsky, et al.           Expires 17 August 2024                 [Page 8]

Internet-Draft           OAM for DetNet over IP            February 2024


              draft-ietf-detnet-oam-framework-11, 8 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-
              oam-framework-11>.

   [ITU-T.1731]
              ITU-T, "Operations, administration and maintenance (OAM)
              functions and mechanisms for Ethernet-based networks",
              ITU-T G.8013/Y.1731, August 2015.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
              June 2010, <https://www.rfc-editor.org/info/rfc5883>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

Authors' Addresses

   Greg Mirsky
   Ericsson
   Email: gregimirsky@xxxxxxxxx


   Mach(Guoyi) Chen
   Huawei
   Email: mach.chen@xxxxxxxxxx


   David Black
   Dell EMC
   176 South Street
   Hopkinton, MA,  01748
   United States of America
   Email: david.black@xxxxxxxx







Mirsky, et al.           Expires 17 August 2024                 [Page 9]
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux