- You use the term flow is a lot. Your definition is in line with the Flow definition in RFC 7011 (IPFIX). Why not reuse it? Even your specific flow definition could re use the same "Flow" definition from RFC 7011 Large Flow(s): long-lived large Flow(s) Small Flow(s): long-lived small Flow(s) and short-lived small/large Flow(s) - How many flow categories do you want to stress? 1. Introduction: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows (which include long- lived small flows, short-lived small/large flows) 1.2. Terminology Large flow(s): long-lived large flow(s) Small flow(s): long-lived small flow(s) and short-lived small/large flow(s) 2. Flow Categorization In general, based on the size and duration, a flow can be categorized into any one of the following four types, as shown in Figure 1: (a) Short-Lived Large Flow (SLLF), (b) Short-Lived Small Flow (SLSF), (c) Long-Lived Large Flow (LLLF), and (d) Long-Lived Small Flow (LLSF). Please be consistent. This is slightly confusing. This only makes sense with the sentence at the end of section 2. In this document, we categorize Long-lived large flow(s) as "Large" flow(s), and all of the others -- Long-lived small flow(s) and short- lived small/large flow(s) as "Small" flow(s). Proposal (to make it clear earlier in document): OLD: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows (which include long- lived small flows, short-lived small/large flows) NEW: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows. These other flow, which include long-lived small flows and short-lived small/large flows, are considered as small flows in this document. EDITORIAL - Please expand LAG/ECMP in the abstract. While ECMP is known, LAG is not. - (load/mix and comma) OLD: If the traffic load constitutes flows such that the result of the hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component link, if, the individual flow rates are much smaller as compared to the link capacity, NEW: If the traffic mix constitutes flows such that the result of the hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component link, if the individual flow rates are much smaller as compared to the link capacity, - EDITORIAL OLD: Where: ->-> small flows ===> large flow NEW: Where: -> small flow ===> large flow Alternatively, make it clear in the figure that "-> -> ->" means 3 small flows, by having each flow on a new line. In the same figure, what does "--/---/-" mean? - To demonstrate the limitations of local optimization, consider a two- level fat-tree topology with three leaf nodes (L1, L2, L3) and two spine nodes (S1, S2) and assume all of the links are 10 Gbps. Let L1 have two flows of 4 Gbps each towards L3, and let L2 have one flow of 7 Gbps also towards L3. If L1 balances the load optimally between S1 and S2, and L2 sends the flow via S1, then the downlink from S1 to L3 would get congested resulting in packet discards. On the other hand, if L1 had sent both its flows towards S1 and L2 had sent its flow towards S2, there would have been no congestion at either S1 or S2. A figure would be appreciated. - as a courtesy for the RFC editors, please order the references - idnits complains about the date. - RFC 5101 -> RFC 7011

= Hi,

Benoit, thanks for your feedback.<= o:p>

Based on the feedback in this thread, and bas= ed on feedback received on an offline conversation with our AD, Benoit, and= our document shepherd, Scott, we have revised the document, and we believe= it addresses the issues that were raised.

http= ://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-11

The main changes in draft 11 vs. draft 10:

- Clarified the scope of the document at t= he very beginning, e.g., FRR and protection are out of scope.

- Moved the two lists from section 4.9 = and 4.10 to a separate section, and referenced them in the abstract. <= /o:p>

- Added a new subsection: "= ; Guidance to Network Equipment Vendors". The background for this chan= ge is a comment by Benoit that if network equipment vendors are included in= the target audience draft 10 was missing some content. After a discussion = with Benoit and Scott it was agreed that the missing piece was a short subs= ection that would provide guidance to network equipment vendors.=

- Removed the term "data plane = OAM tools", and clarified that we are focusing on tools for measuring = and monitoring the data plane. The background for this change was an observ= ation by Scott that the term “data plane OAM tool” is a bit con= fusing; by saying “OAM tool” it necessarily means that you are = monitoring the data plane.

- Several more updates based on Stewart's comments in this thread.

We believe we have addressed all the open issues, a= nd that the document is ready for WG last call.

Any further feedback is welcome.

Thanks,

Tal.<= o:p>

From: Benoit Claise [= mailto:bclaise@cisco.com]
Sent: Thursday, November 28, 2013 6:05= PM
To: Tal Mizrahi; draft-ietf-opsawg-oam-overview@tools.ietf.or= g
Cc: stbryant@cisco.com; Scott O. Bradner; opsawg-chairs@tools.i= etf.org; Joel jaeggli; Adrian Farrel; opsawg@ietf.org
Subject: Re= : draft-ietf-opsawg-oam-overview status

Dear auth= ors,

As you know, the IESG sent this document back to the WG (see http://www.ietf.org/mail-archive/web/opsawg/current/msg02931.html). I asked the authors to make sure that the feedback and concerns received = so far were addressed. A new version has been posted. Good!

Below = is the feedback sent by Stewart Bryant on the new version, forwarded with p= ermission to the WG: Stewart has been involved in OAM for some time now, is= the routing AD, and was the DISCUSS holder when the draft was reviewed by = the IESG in 2011). Note that the DISCUSS is gone now, since the document is= back in the WG.

I've been reviewing the new draft version, this ema= il below, and had two conf. calls with Stewart today. Below is the outcome = of our discussion.

The draft improved. For example, I like the fact = that the target audience is now in the abstract.
However, one important = point brought up by Stewart is: why audience do you target? Is the draft co= ntent useful for that audience?
It seems that initially, it was the sili= con designer. It's apparently not the case any longer.
You list

   The target audience of this document includes netwo=
rk equipment

   vendors, network operators a=
nd standard development organizations,

   an=
d can be used as an index to some of the main data plane OAM tools

   defined in the IETF.

We believe that this draft is not c= omplete enough for the network equipment vendor audience. It needs way more= than this overview. Also you focus only on the data plane OAM.
R= egarding the network operators, your table in 4.10 might be a good output. = However, it's buried into a subsection.
Regarding "an index to some= of the main data plane OAM tools defined in the IETF", the table in s= ection 3.9 is buried into a subsection.
Maybe you want to highlight tho= se tables with they own section.

Also, while the abstract and title = mention "an index to some of the main data plane OAM tools defi= ned in the IETF" , the data plane adjective really limits the scope of= what you're investigating. I only understood its implications way later in= the draft. For example that FRR, RDI (remote defect indication), etc. were= not included. This should be stressed upfront.

This point points ba= ck to Stewart's point: think about your target audience and evaluate if the= content is useful for the readers... Note that this is now a WG document, = so we must get the OPSAWG community feedback.

Also, Stewart has some= good points below: path verification versus peer authentication, multipoin= t to point, etc.

Regarding the WIKI, I'm actually in favor a collect= ing this information in a RFC. OAM has been growing over the years, up to a= point where I'm not sure what it does NOT contain (FCAPS). So doing a one-= time "overview of OAM tools" makes sense to me.

Regards, B= enoit

Firstly, I should say I have been revie= wing this work from
the point of view of someone who was on po= int when we designed
the MPLS-TP OAM, where we took object less= on after object lesson
on the scope and purpose of OAM from the= ITU-T.

I will say that the project you have embarked on is= a very
difficult and challenging one, since this subject has enormous breath and depth. In one communication = earlier the stated purpose was to provide an overview from the = point of view of a silicon designer. I do not think you get clo= se to that. My view is still that you fail to ruthlessly id= entify the target audience and the single mindedly deliver to t= hat audience. The text is far too detailed in places for th= e broad brush overview and lacks the rigor needed for a deeper = academic introduction. If your goal is the former, I think = you need to split the work between an RFC and a Wiki, and delet= e a lot of the detail. If your goal is the latter, then I t= hink you need to set up a well defined, intellectually rigerous= framework for OAM, and then show how well, or how badly= the solutions map to it. If your original goal is to talk = about implementation, I would have expected a lot of discussion= on stack depth, queue and process structure, performance bottl= enecks, timestamping etc. Indeed even in an introduction there = needs to be some text on those aspects of the problem. = Now if I am the only AD that has any concerns about publishing= this text as an RFC, I am prepared to move to abstain and you<= br>can publish this as it is. However I think that Ben= oit needs to understand that we have sufficient real support i= n the IETF for the text amongst the various OAM design teams t= hat look after each protocol suite discussed in the text. If t= here is not support, perhaps this should go to the ISE as a pe= rsonal statement on the subject. It might be a good idea if= Benoit and I discussed this on the telephone tomorrow. - Stewart Abstract &nb= sp; Operations, Administration, and Maintenance (OAM) is a general te= rm    that refers to a toolset for fault detection an= d isolation, and for    performance measurement. SB> No In MPLS-TP (which is in scope it does more, it is al= so a devolved SB> control plane)   = ; Over the years various OAM tools have been    defin= ed for various layers in the protocol stack.    T= his document summarizes some of the data plane OAM tools defined in   the IETF in the context of IP unicast, MPLS, pseudowires,= MPLS for    the transport profile (MPLS-TP), and TRI= LL. SB> Since MPLS-TP is a subset of MPLS the ordering o= f the list is a little curious    The target = audience of this document includes network equipment &nbs= p; vendors, network operators and standard development organizations,<= br>   and can be used as an index to some of the main data pl= ane OAM tools    defined in the IETF. =3D=3D=3D=3D=3D=3D 1. Introduction &nb= sp; OAM is a general term that refers to a toolset for detecting,    isolating and reporting failures and for monitoring t= he network    performance. SB> See= earlier comment    There are several different i= nterpretations to the "OAM" acronym.    Thi= s document refers to Operations, Administration and Maintenance,    as recommended in Section 3 of [RFC6291]. &n= bsp; This document summarizes some of the data plane OAM tools define= d in    the IETF in the context of IP unicast, MPLS, = pseudowires, MPLS for    the transport profile (MPLS-= TP), and TRILL. SB> See earlier comment =    This document focuses on data plane OAM tools. Hence, control = and    management aspects of OAM are outside the scop= e of this document.    This document focuses on tools= for detecting and isolating failures    and for perf= ormance monitoring. Network repair functions such as Fast = ; Reroute (FRR) and protection switching, which are often triggered b= y    OAM protocols, are out of the scope of this docu= ment. SB> You need to be careful with the definition of = OAM - In MPLS-TP (which SB> you define as in scope) these ar= e considered OAM functions. 1.1. Background<= /tt>    OAM was originally used in traditional communi= cation technologies    such as E1 and T1, evolving in= to PDH and then later in SONET/SDH. ATM    was probab= ly the first technology to include inherent OAM support &= nbsp; from day one, while in other technologies OAM was typically defined    in an ad hoc manner after the technology was alread= y defined and    deployed. Packet-based networks were= traditionally considered    unreliable and best-effo= rt, but as packet-based networks evolved,    they hav= e become the common transport for both data and telephony, &nbs= p; replacing traditional transport protocols. Consequently, packet-ba= sed    networks were expected to provide a similar &q= uot;carrier grade"    experience, and specifical= ly to support OAM.    As typical networks have a = multi-layer architecture, the set of OAM    protocols= similarly take a multi-layer structure; each layer has its &nb= sp; own OAM protocols. Moreover, OAM can be used at different levels = of    hierarchy in the network to form a multi-layer = OAM solution, as shown    in the example in Figure 1.=    Figure 1 illustrates a network in which IP tr= affic between two    customer edges is transported ov= er an MPLS provider network. MPLS OAM    is used at t= he provider-level for monitoring the connection between &= nbsp; the two provider edges, while IP OAM is used at the customer-level    for monitoring the end-to-end connection between the= two customer    edges. <= br> Mizrahi, et al.        Ex= pires April 21, 2014         &= nbsp;       [Page 4] Internet= -Draft          Overview of OA= M Tools           &n= bsp; October 2013       &= nbsp;    |<-------------- Customer-level OAM ------------= -->|          &= nbsp;       IP OAM (Ping, Traceroute, OWAMP, = TWAMP)         &nbs= p;            &= nbsp; |<- Provider-level OAM ->|    =             &nb= sp;            MPLS = OAM (LSP Ping)      +-----+  =      +----+       &n= bsp;            = ;    +----+       +-----+=      |     |  &nb= sp;    |    |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    |  =      |     | &nbs= p;   |     |-------|    | = ;         MPLS   &nb= sp;      |    |-------|  =    |      |   &nbs= p; | IP   |    |    &nbs= p;            &= nbsp;      |    | IP &nb= sp; |     |      +-----= +       +----+     &= nbsp;           &nbs= p;      +----+      = +-----+      Customer   &nb= sp; Provider          &nb= sp;           Provider&nb= sp;     Customer     &n= bsp; Edge         Edge &= nbsp;           &nbs= p;            Edge&n= bsp;         Edge &= nbsp;           &nbs= p;        Figure 1 Example: Multi-layer = OAM 1.2. Target Audience    The t= arget audience of this document includes:    o St= andard development organizations - both IETF working groups and       non-IETF organizations can benefit from thi= s document when       designing new OA= M protocols, or when looking to reuse existing OAM   =     tools for new technologies. SB> Who d= o you have in mind outside the IETF? SB> There are a lot of= OAM expert groups out there.    o Network equipm= ent vendors and network operators - can use this   &n= bsp;   document as an index to some of the common IETF OAM tools.=    It should be noted that this document is not = necessarily suitable for    beginners without any bac= kground in OAM. 1.3. OAM-related Work in the IETF <= br>   This memo provides an overview of the different sets of= OAM tools    defined by the IETF. The set of OAM too= ls described in this memo are    applicable to IP uni= cast, MPLS, pseudowires, MPLS for the transport    pr= ofile (MPLS-TP), and TRILL. While OAM tools that are applicable to =    other technologies exist, they are beyond the scope of thi= s memo.    This document focuses on IETF document= s that have been published as    RFCs, while other on= going OAM-related work is outside the scope.    T= he IETF has defined OAM protocols and tools in several different    contexts. We roughly categorize these efforts into a few set= s of OAM-    related RFCs, listed in Table 1. Each ca= tegory defines a logically- Mizrahi, et al.  =       Expires April 21, 2014   &nbs= p;             = [Page 5] Internet-Draft      =     Overview of OAM Tools      = ;       October 2013 &nbs= p; coupled set of RFCs, although the sets are in some cases intertwin= ed    by common tools and protocols. =    The discussion in this document is ordered according to these<= /tt>    categories.    &nbs= p;            &= nbsp;    +--------------+------------+ &nb= sp;            =        | Category     | T= ransport |        &nbs= p;             = |            &n= bsp; | Technology |        &= nbsp;           &nbs= p; +--------------+------------+      =             &nb= sp;   |IP Ping       | IPv4/IPv6&nb= sp; |          &nb= sp;           +----------= ----+------------+        &n= bsp;            = ; |IP Traceroute | IPv4/IPv6 |     &n= bsp;            = ;    +--------------+------------+   &= nbsp;           &nbs= p;      |BFD      &n= bsp;    | generic    | &nbs= p;            &= nbsp;      +--------------+------------+ <= tt>            =          |MPLS OAM   = ;   | MPLS       | &nbs= p;            &= nbsp;       +--------------+------------+            =           |MPLS-TP OAM &n= bsp; | MPLS-TP    |     &nbs= p;            &= nbsp;   +--------------+------------+   &nb= sp;            =       |Pseudowire OAM| Pseudowires| &n= bsp;            = ;        +--------------+------------+           &nbs= p;          |OWAMP and &n= bsp;   | IPv4/IPv6 |     &n= bsp;            = ;    |TWAMP         = |            |<= br>           &n= bsp;         +--------------+------= ------+          &= nbsp;           |TRILL OA= M     | TRILL      | <= tt>            =          +--------------+----------= --+           = ;    Table 1 Categories of OAM-related IETF Documents SB> Categories implies taxonomy, and those are not really= SB> taxonomy classes. Those are really IETF work packages.<= br> 1.4. Focusing on Data Plane OAM Tools &nbs= p; OAM tools may, and quite often do, work in conjunction with a control    plane and/or management plane. At the data pla= ne, OAM provides    instrumentation tools. <= br>SB> That is your definition of the purpose, not for example the <= /tt> SB> transport world's definition. SB> You mig= ht also consider implicit OAM tools such as router hellos &= nbsp; OAM tools often use control plane functions, = e.g., to initialize OAM sessions and to exchange various parameters.=    The OAM tools communicate with the management pla= ne to raise alarms,    and often OAM tools may be act= ivated by the management (as well as by    the contro= l plane), e.g. to locate and localize problems.   = ; The considerations of the control plane maintenance tools and the   functionality of the management plane are out of scope fo= r this    document, which concentrates on presenting = the data plane tools that    are used for OAM. Networ= k repair functions such as Fast Reroute (FRR) Mizra= hi, et al.        Expires April 21, 2014=             &nb= sp;    [Page 6] Internet-Draft  &n= bsp;       Overview of OAM Tools  &= nbsp;          October 2013    and protection switching, which are often tr= iggered by OAM protocols,    are also out of the scop= e of this document. SB> I don't mind what you call your = function, but this exclusion SB> will not class the function= ality as OAM within the shared IETF-ITU SB> definition of OA= M in the transport technology space.    Since OAM= protocols are used for monitoring the data plane, it is = imperative for OAM tools to be capable of testing the actual data    plane in as much accuracy as possible. Thus, it is i= mportant to    enforce fate-sharing between OAM traff= ic that monitors the data plane    and the data plane= traffic it monitors. 2. Terminology 2.1. A= bbreviations    ACH    Associated = Channel Header    AIS    Alarm Ind= ication Signal    ATM    Asynchron= ous Transfer Mode    BFD    Bidire= ctional Forwarding Detection    CC  &nb= sp; Continuity Check    CV   = ; Connectivity Verification    DM &nbs= p;   Delay Measurement    ECMP &nb= sp; Equal Cost Multiple Paths    FEC  &= nbsp; Forwarding Equivalence Class    FRR &n= bsp; Fast Reroute    G-ACh   Gene= ric Associated Channel    GAL    G= eneric Associated Label    ICMP   Inter= net Control Message Protocol    L2TP   = Layer Two Tunneling Protocol    LCCE   = L2TP Control Connection Endpoint    LDP &nbs= p; Label Distribution Protocol    LER =    Label Edge Router Mizrahi, et al. = ;       Expires April 21, 2014  &nb= sp;            = [Page 7] Internet-Draft     = ;     Overview of OAM Tools    &nbs= p;        October 2013 <= tt>   LM     Loss Measurement    LSP    Label Switched Path &nb= sp; LSR    Label Switched Router = ; ME     Maintenance Entity = ; MEG    Maintenance Entity Group &nbs= p; MEP    MEG End Point    M= IP    MEG Intermediate Point    MP=      Maintenance Point    MPL= S   Multiprotocol Label Switching    MP= LS-TP MPLS Transport Profile    MTU  &n= bsp; Maximum Transmission Unit    OAM  = Operations, Administration, and Maintenance &n= bsp; PDH    Plesiochronous Digital Hierarchy    PE     Provider Edge &nbs= p; PW     Pseudowire   = PWE3   Pseudowire Emulation Edge-to-Edge &= nbsp; RBridge Routing Bridge    RDI  &n= bsp; Remote Defect Indication    SDH  &= nbsp; Synchronous Digital Hierarchy    SONET = ; Synchronous Optical Networking    TRILL&n= bsp; Transparent Interconnection of Lots of Links &nb= sp; TTL    Time To Live    V= CCV   Virtual Circuit Connectivity Verification <= br> Mizrahi, et al.        Expire= s April 21, 2014          = ;       [Page 8] Internet-Dra= ft          Overview of OAM To= ols            = October 2013 2.2. Terminology used in OAM Standards 2.2.1. General Terms    A wide vari= ety of terms is used in various OAM standards. This   = ; section presents a comparison of the terms used in various OAM    standards, without fully quoting the definition of each term= .    An interesting overview of the term OAM and = its derivatives is    presented in [OAM-Def]. A thesa= urus of terminology for MPLS-TP terms    is presented= in [TP-Term], and provides a good summary of some of the = ; OAM related terminology. 2.2.2. Operations, Adminis= tration and Maintenance    The following definiti= on of OAM is quoted from [OAM-Def]:    The compon= ents of the "OAM" acronym (and provisioning) are defined as<= br>   follows:    o Operations - Op= eration activities are undertaken to keep the    = ;   network (and the services that the network provides) up and       running. It includes monito= ring the network and finding problems.     = Ideally these problems should be found before users are affected.    o Administration - Administration activities inv= olve keeping track       of resources = in the network and how they are used. It includes &= nbsp;    all the bookkeeping that is necessary to track netw= orking       resources and the network= under control.    o Maintenance - Maintenance ac= tivities are focused on facilitating     &n= bsp; repairs and upgrades -- for example, when equipment must be       replaced, when a router needs a patch for = an operating system       image, or wh= en a new switch is added to a network. Maintenance =      also involves corrective and preventive measures t= o make the       managed network run m= ore effectively, e.g., adjusting device     = ; configuration and parameters. SB> I think that t= he class of OAM that you explain is actually SB> M =3D=3D Me= asurement. Maint implies maint of service which includes SB>= protection switching which you have put out of scope. 2.2.= 3. Functions, Tools and Protocols OAM Function =    An OAM function is an instrumentation measurement = type or diagnostic. Mizrahi, et al.  =       Expires April 21, 2014   &nbs= p;             = [Page 9] Internet-Draft      =     Overview of OAM Tools      = ;       October 2013 &nbs= p; OAM functions are the atomic building blocks of OAM, where each    function defines an OAM capability. =    Typical examples of OAM functions are presented in Section 3.<= /tt> OAM Protocol    A protocol used f= or implementing one or more OAM functions.    The= OWAMP-Test [OWAMP] is an example of an OAM protocol. SB>= ; Isn't your definition DP measurements? I am struggling to SB&= gt; work out if OWAMP is a DP measurement, or a synthetic SB>= ; Transport measurement. SB> I think that OWAMP is UDP isn't= it, so is really measuring SB> what the system does to UDP = packets. OAM Tool    An OAM tool = is a specific means of applying one or more OAM    fu= nctions.    In some cases an OAM protocol *is* an= OAM tool, e.g., OWAMP-Test. In    other cases an OAM= tool uses a set of protocols that are not strictly   = ; OAM-related; for example, Traceroute (Section 4.2.) can be &n= bsp; implemented using UDP and ICMP messages, without using an OAM    protocol per se. 2.2.4. Data Plane, = Control Plane and Management Plane Data Plane <= tt>   The data plane is the set of functions used to transfer dat= a in the    stratum or layer under consideration [ITU= -Terms].    .    The Da= ta Plane is also known as the Forwarding Plane or the User &nbs= p; Plane. SB> I am not sure that is quite right. Control Plane    The control plane= is the set of protocols and mechanisms that enable   = ; routers to efficiently learn how to forward packets towards their   final destination (based on [Comp]). SB&g= t; Er no. The routers may not learn in the classic sense of learn. = SB> they may be told by the CP. Management Plane=    The term Management Plane, as described in [M= ng], is used to describe    the exchange of managemen= t messages through management protocols    (often tra= nsported by IP and by IP transport protocols) between &nb= sp; management applications and the managed entities such as network   nodes. Mizrahi, et al.  &n= bsp;     Expires April 21, 2014    =             [Page 10= ] Internet-Draft       &= nbsp; Overview of OAM Tools       =       October 2013 Data Plane = vs. Control Plane vs. Management Plane    The dis= tinction between the planes is at times a bit vague. For = example, the definition of "Control Plane" above may imply= that OAM    tools such as ping, BFD and others are i= n fact in the control plane.    This document foc= uses on data plane OAM tools, i.e., tools used for   = monitoring the data plane. While these tools could arguably be    considered to be in the control plane, these tools monitor th= e data    plane, and hence it is imperative to have f= ate-sharing between OAM    traffic that monitors the = data plane and the data plane traffic it    monitors.=    Another potentially vague distinction is betw= een the management plane    and control plane. The ma= nagement plane should be seen as separate    from, bu= t possibly overlapping with, the control plane (based on = [Mng]). 2.2.5. The Players &nb= sp; An OAM tool is used between two (or more) "players". Various = terms    are used in IETF documents to refer to the p= layers that take part in    OAM. Table 2 summarizes t= he terms used in each of the categories    discussed = in this document.        = ;   +--------------------------+--------------------------+<= br>          | Category&nb= sp;            =     | Terms        &= nbsp;           |          +--------------= ------------+--------------------------+    &nbs= p;      | Ping / Traceroute    = ;    |-Host        &= nbsp;            |           | ([ICMPv= 4], [ICMPv6],     |-Node     &= nbsp;           &nbs= p;   |        &nbs= p; | [TCPIP-Tools])       &n= bsp; |-Interface         = ;       |     = ;      |       =             &nb= sp;      |-Gateway     &n= bsp;            |           + --------= ---------------- + ------------------------ +    = ;       | BFD [BFD]    &n= bsp;           | System&n= bsp;            = ;      |      = ;     + ------------------------ + --------------------= ---- +           |= MPLS OAM [MPLS-OAM-FW]   | LSR     &nbs= p;            &= nbsp;   |        &= nbsp; + ------------------------ + ------------------------ +          | MPLS-TP OAM [= TP-OAM-FW] |-End Point - MEP       = ;   |         = ; |           =             &nb= sp; |-Intermediate Point - MIP |     =       + ------------------------ + ---------------= --------- +         &nb= sp; | Pseudowire OAM [VCCV]    |-PE    &= nbsp;           &nbs= p;      |     &nbs= p;     |        = ;            &n= bsp;     |-LCCE      &nbs= p;            &= nbsp; |           = + ------------------------ + ------------------------ + &= nbsp;        | OWAMP and TWAMP &nbs= p;        |-Host    =             &nb= sp;    | Mizrahi, et al.  &nbs= p;     Expires April 21, 2014    &n= bsp;           [Page 11]<= /tt> Internet-Draft       &nb= sp; Overview of OAM Tools       &n= bsp;     October 2013   &= nbsp;       | ([OWAMP], [TWAMP])  &= nbsp;    |-End system      &nb= sp;        |   &nb= sp;       + ------------------------ + ------= ------------------ +        =    | TRILL OAM [TRILL-OAM]    |-RBridge  = ;            &n= bsp;   |        &n= bsp; +--------------------------+--------------------------+ =             = ;       Table 2 Maintenance Point Terminology= SB> Shouldn't you start with a rigorous definition and = then show SB> how the less rigorous terms map to it? 2.2.6. Proactive and On-demand Activation &n= bsp; The different OAM tools may be used in one of two basic types of<= br>   activation: Proactive &= nbsp; Proactive activation - indicates that the tool is activated on = a    continual basis, where messages are sent periodi= cally, and errors are    detected when a certain numb= er of expected messages are not received. On-demand    On-demand activation - indicates that the tool is act= ivated    "manually" to detect a specific a= nomaly. 2.2.7. Connectivity Verification and Continuity Che= cks    Two distinct classes of failure management= functions are used in OAM    protocols, connectivity= verification and continuity checks. The    distincti= on between these terms is defined in [MPLS-TP-OAM], and is &nbs= p; used similarly in this document. Continuity Check<= /tt>    Continuity checks are used to verify that a de= stination is reachable,    and are typically sent pro= actively, though they can be invoked on-    demand as= well. Connectivity Verification SB> CV = is surely about verifying that Bob is Bob? SB> What you are = about to describe is path verification.    A conn= ectivity verification function allows Alice to check whether &n= bsp; she is connected to Bob or not. This function also allows Alice = to    verify that messages from Bob are received thro= ugh the correct path,    thereby verifying not only t= hat the two MPs are connected, but also    that they = are connected through the expected path, allowing detection &nb= sp; of unexpected topology changes. It is noted that while the CV    function is performed in the data plane, the "ex= pected path" is Mizrahi, et al.   &= nbsp;    Expires April 21, 2014     = ;           [Page 12] Internet-Draft        = Overview of OAM Tools        = ;     October 2013    pre= determined either in the control plane or in the management plane. =    A connectivity verification (CV) protocol typically uses a= CV    message, followed by a CV reply that is sent b= ack to the originator.    A CV function can be applie= d proactively or on-demand.    Connectivity verif= ication and continuity checks are considered    compl= ementary mechanisms, and are often used in conjunction with each    other. 2.2.8. Connection Oriented vs. Connec= tionless Communication Connection Oriented =    In Connection Oriented technologies an end-to-end connection i= s    established (by a control protocol or provisione= d by a management    system) prior to the transmissio= n of data.    Typically a connection identifier i= s used to identify the connection.    In connection o= riented technologies it is often the case (although   = ; not always) that all packets belonging to a specific connection use<= br>   the same route through the network. Con= nectionless    In Connectionless technologies dat= a is typically sent between end    points without pri= or arrangement. Packets are routed independently    b= ased on their destination address, and hence different packets may =    be routed in a different way across the network. <= br>Discussion    The OAM tools described in t= his document include tools that support    connection= oriented technologies, as well as tools for connectionless &nb= sp; technologies.    In connection oriented= technologies OAM is used to monitor a    *specific* = connection; OAM packets are forwarded through the same &n= bsp; route as the data traffic and receive the same treatment. In <= tt>   connectionless technologies, OAM is used between a source a= nd    destination pair without defining a specific co= nnection. Moreover, in    some cases the route of OAM= packets may differ from the one of the    data traff= ic. For example, the connectionless IP Ping (Section 4.1.) &nbs= p; tests the reachability from a source to a given destination, while=    the connection oriented LSP Ping (Section 4.4.) i= s used for    monitoring a specific LSP (connection),= and provides the capability    to monitor all the av= ailable paths used by an LSP. Mizrahi, et al. =        Expires April 21, 2014  &nbs= p;             = [Page 13] Internet-Draft      = ;    Overview of OAM Tools     &nbs= p;       October 2013 &nb= sp; It should be noted that in some cases connectionless protocols ar= e    monitored by connection oriented OAM protocols. = For example, while IP    is a connectionless protocol= , it can monitored by BFD (Section 4.3.    ), which i= s connection oriented. 2.2.9. Point-to-point vs. Point-to-m= ultipoint Services Point-to-point (P2P) &nb= sp; A P2P service delivers data from a single source to a single=    destination. Point-to-multipoint (P2MP= )    An P2MP service delivers data from a single = source to a one or more    destinations (based on [Si= gnal]).    [Signal] also defines a MP2MP service = as a service that delivers data    from more than one= source to one or more receivers. SB> MP2P is a very int= eresting and important class - it is what SB> a VPN service = (such as RFC2547) looks like, and has some interesting SB> i= nstrumentation problems. Discussion &= nbsp; The OAM tools described in this document include tools for P2P   services, as well as tools for P2MP services.    The distinction between P2P services and P2MP services a= ffects the    corresponding OAM tools. A P2P service = is typically simpler to    monitor, as it consists of= a single pair of end points. P2MP services    presen= t several challenges. For example, in a P2MP service, the OAM &= nbsp; mechanism not only verifies that each of the destinations is    reachable from the source, but also verifies that th= e P2MP    distribution tree is intact and loop-free. = Another challenge in P2MP    services is performance = monitoring; while in P2P packet loss is    measured b= y maintaining packet counters at the two end-points, in &= nbsp; P2MP packet loss must be carefully measured by generating synthetic    traffic to each corresponding end-point and maintai= ning a separate    counter for each peer end-point. SB> Incorrect. You can monitor live traffic. Think counti= ng I-frames SB> as but one example. 2.2.10. = Failures    The terms Failure, Fault, and Defect = are used interchangeably in the    standards, referri= ng to a malfunction that can be detected by a    conn= ectivity or a continuity check. In some standards, such as &nbs= p; 802.1ag [IEEE802.1Q] , there is no distinction between these terms= ,    while in other standards each of these terms ref= ers to a different    type of malfunction. Mizrahi, et al.        Exp= ires April 21, 2014         &n= bsp;      [Page 14] Internet-Draft=           Overview of OAM Tool= s             O= ctober 2013    The terminology used in IETF M= PLS-TP OAM is based on the ITU-T    terminology, whic= h distinguishes between these three terms in    [ITU-= T-G.806]; Fault    The term Fault= refers to an inability to perform a required action, &nb= sp; e.g., an unsuccessful attempt to deliver a packet. Defe= ct    The term Defect refers to an interruption i= n the normal operation,    such as a consecutive peri= od of time where no packets are delivered    successf= ully. Failure    The term Failure= refers to the termination of the required function. &nbs= p; While a Defect typically refers to a limited period of time, a <= tt>   failure refers to a long period of time. 3.= OAM Functions    This subsection provides a brie= f summary of the common OAM functions    used in OAM-= related standards. These functions are used as building &= nbsp; blocks in the OAM standards described in this document. <= tt>   o Connectivity Verification (CV) and/or Continuity Checks (= CC):       As defined in Section 2.2.7= .    o Path Discovery / Fault Localization:<= br>      This function can be used to trace th= e route to a destination,       i.e., = to identify the nodes along the route to the destination. = ;     When more than one route is available to a specif= ic destination,       this function tr= aces one of the available routes. When a failure   &n= bsp;   occurs, this function also allows to detect the location o= f the       failure. = ;     Note that the term route tracing (or Traceroute) = that is used in       the context of I= P and MPLS, is sometimes referred to as path    =    tracing in the context of other protocols, such as TRILL.= SB> What about path verification? &nbs= p; o Performance Monitoring:       Typ= ically refers to:        = ; o Loss Measurement (LM) - monitors the packet loss rate. = Mizrahi, et al.        Expir= es April 21, 2014         &nbs= p;      [Page 15] Internet-Draft&n= bsp;         Overview of OAM Tools&= nbsp;            Oct= ober 2013         o = Delay Measurement (DM) - monitors the delay and delay &nb= sp;        variation. 4.= OAM Tools in the IETF - a Detailed Description   = ; This section presents a detailed description of the sets of OAM- =    related tools in each of the categories in Table 1. 4.1. IP Ping    Ping is a common networ= k diagnosis application for IP networks that    uses = ICMP. According to [NetTerms], 'Ping' is an abbreviation for &n= bsp; Packet internet groper, although the term has been so commonly u= sed    that it stands on its own. SB= > I bet the true origin of the name lies with SONAR, and the restSB> is post-hoc justification    As defi= ned in [NetTerms], it is a program    used to test re= achability of destinations by sending them an ICMP   = echo request and waiting for a reply.    The ICM= P Echo request/reply exchange in Ping is used as a continuity &= nbsp; check function for the Internet Protocol. The originator transm= its an    ICMP Echo request packet, and the receiver = replies with an Echo    reply. ICMP ping is defined i= n two variants, [ICMPv4] is used for    IPv4, and [IC= MPv6] is used for IPv6.    Ping implementations t= ypically use ICMP messages. UDP Ping is a    variant = that uses UDP messages instead of ICMP echo messages. = ; Ping is a single-ended continuity check, i.e., it allows the   *initiator* of the Echo request to test the reachability= . If it is    desirable for both ends to test the rea= chability, both ends have to    invoke Ping independe= ntly.    Note that since ICMP filtering is deploy= ed in some routers and    firewalls, the usefulness o= f Ping is sometimes limited in the wider    internet.= This limitation is equally relevant to Traceroute. 4.2. IP= Traceroute    Traceroute ([TCPIP-Tools], [NetToo= ls]) is an application that allows    users to discov= er a path between an IP source and an IP destination. = ; The most common way to implement Traceroute [TCPIP-Tools] is   described as follows. Traceroute sends a sequence of UDP= packets to    UDP port 33434 at the destination. By = default, Traceroute begins by    sending three packet= s (the number of packets is configurable in most    T= raceroute implementations), each with an IP Time-To-Live (or Hop    Limit in IPv6) value of one to the destination. These packet= s expire    as soon as they reach the first router in= the path. Consequently, Mizrahi, et al.  &nb= sp;     Expires April 21, 2014    &= nbsp;           [Page 16]= Internet-Draft       &n= bsp; Overview of OAM Tools       &= nbsp;     October 2013   = that router sends three ICMP Time Exceeded Messages back to the    Traceroute application. Traceroute now sends another three U= DP    packets, each with the TTL value of 2. These me= ssages cause the    second router to return ICMP mess= ages. This process continues, with    ever increasing= values for the TTL field, until the packets actually &nb= sp; reach the destination. Because no application listens to port 33434    at the destination, the destination returns ICMP Dest= ination    Unreachable Messages indicating an unreach= able port. This event    indicates to the Traceroute = application that it is finished. The    Tracero= ute program displays the round-trip delay associated with each =    of the attempts.    While Traceroute= is a tool that finds *a* path from A to B, it should &nb= sp; be noted that traffic from A to B is often forwarded through Equal=    Cost Multiple Paths (ECMP). Paris Traceroute [Paris] i= s an extension    to Traceroute that attempts to disc= overs all the available paths from    A to B by scann= ing different values of header fields (such as UDP   = ports) in the probe packets.    It is noted that= Traceroute is an application, and not a protocol. As &nb= sp; such, it has various different implementations. One of the most   common ones uses UDP probe packets, as described above. O= ther    implementations exist that use other types of= probe messages, such as    ICMP or TCP. =    Note that IP routing may be asymmetric. While Traceroute d= iscovers a    path between a source and destination, = it does not reveal the reverse    path. <= tt>   A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been def= ined in    the context of Traceroute. These documents= define several extensions,    including extensions t= o the ICMP Destination Unreachable message,    that c= an be used by Traceroute applications. 4.3. Bidirectional F= orwarding Detection (BFD) 4.3.1. Overview &= nbsp; While multiple OAM tools have been defined for various protocol= s in    the protocol stack, Bidirectional Forwarding = Detection [BFD], defined    by the IETF BFD working g= roup, is a generic OAM tool that can be    deployed o= ver various encapsulating protocols, and in various medium &nbs= p; types. The IETF has defined variants of the protocol for IP ([BFD-=    IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and f= or pseudowires [BFD-    VCCV]. The usage of BFD in MP= LS-TP is defined in [TP-CC-CV]. Mizrahi, et al.=         Expires April 21, 2014 &nbs= p;            &= nbsp; [Page 17] Internet-Draft     = ;     Overview of OAM Tools    &nbs= p;        October 2013 <= tt>   BFD includes two main OAM functions, using two types of BFD= packets:    BFD Control packets, and BFD Echo packet= s. 4.3.2. Terminology    BFD oper= ates between two *systems*. The BFD protocol is run between &nb= sp; two systems after establishing a *session*. SB>= ; Isn't there a P2MP BFD? 4.3.3. BFD Control    BFD supports a bidirectional continuity check, using BFD con= trol    packets, that are exchanged within a BFD sess= ion. BFD sessions    operate in one of two modes:    o Asynchronous mode (i.e. proactive): in this mod= e BFD control       packets are sent p= eriodically. When the receiver detects that no   &nbs= p;   BFD control packets have been received during a predetermine= d       period of time, a failure is d= etected.    o Demand mode: in this mode, BFD cont= rol packets are sent on-demand.       = Upon need, a system initiates a series of BFD control packets to       check the continuity of the session. BFD c= ontrol packets are sent       independ= ently in each direction.    Each of the end-point= s (referred to as systems) of the monitored path    m= aintains its own session identification, called a Discriminator,    both of which are included in the BFD Control Packets that a= re    exchanged between the end-points. At the = time of session    establishment, the Discriminators = are exchanged between the two-end    points. In= addition, the transmission (and reception) rate is   = ; negotiated between the two end-points, based on information included=    in the control packets. These transmission rates= may be renegotiated    during the session. <= br>   During normal operation of the session, i.e. no failure= s are    detected, the BFD session is in the Up state= . If no BFD Control    packets are received dur= ing a period of time called the Detection    Time, th= e session is declared to be Down. The detection time is a = ; function of the pre-configured or negotiated transmission time, and= a    parameter called Detect Mult. Detect Mult deter= mines the number of    missing BFD Control packets th= at cause the session to be declared as    Down. This = parameter is included in the BFD Control packet. 4.3.4. BFD= Echo    A BFD echo packet is sent to a peer syst= em, and is looped back to the    originator. The echo= function can be used proactively, or on-demand. Mizrah= i, et al.        Expires April 21, 2014&= nbsp;           &nbs= p;   [Page 18] Internet-Draft   &n= bsp;      Overview of OAM Tools   &= nbsp;         October 2013 =    The BFD echo function has been defined in BFD for = IPv4 and IPv6    ([BFD-IP]), but is not used in BFD f= or MPLS LSPs, PWs, or in BFD for    MPLS-TP. = 4.4. MPLS OAM    The IETF MPLS working gr= oup has defined OAM for MPLS LSPs. The    requirement= s and framework of this effort are defined in    [MPL= S-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM &= nbsp; tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for = P2MP    services is defined in [MPLS-P2MP]. <= br>   LSP Ping is modeled after the Ping/Traceroute paradigm = and thus it    may be used in one of two modes:<= br>    o "Ping" mode: In this mode LSP Ping is u= sed for end-to-end       connectivity = verification between two LERs.    o "Tracero= ute" mode: This mode is used for hop-by-hop fault &n= bsp;    isolation.    LSP Ping ext= ends the basic ICMP Ping operation (of data-plane    = connectivity verification) with functionality to verify data-plane =    vs. control-plane consistency for a Forwarding Equivalence= Class    (FEC) and also Maximum Transmission Unit (M= TU) problems.    The challenge in MPLS networks i= s that the traffic of a given LSP may    be load bala= nced across Equal Cost Multiple paths (ECMP). LSP Ping &n= bsp; monitors all the available paths of an LSP by monitoring its <= tt>   different Forwarding Equivalence Classes (FEC). SB> That is one challange, the real problem is that the labelsSB> are opaque at a mid-point and that the payload is not <= tt>SB> known at that point either. Also you do not have an automatic SB> return path path other than MPLS-TP. It's not like IP where= SB> you can reverse the SA and DA into DA and SA. <= br>   Conversely, MPLS-TP    does not u= se ECMP, and thus does not require OAM over multiple paths. &nb= sp; The Traceroute functionality may be used to isolate and localize = the    MPLS faults, using the Time-to-live (TTL) indi= cator to incrementally    identify the sub-path of th= e LSP that is successfully traversed    before the fa= ulty link or node. SB> Can't yo also do this in regular = MPLS    It should be noted that LSP Ping supports= unique identification of    the LSP within an addres= sing domain. The identification is checked    using t= he full FEC identification. LSP Ping is easily extensible to &n= bsp; include additional information needed to support new functionali= ty,    by use of Type-Length-Value (TLV) constructs. = The usage of TLVs is    typically not easy to perform= in hardware, and is thus typically    handled by the= control plane.    LSP Ping supports both asynchr= onous, as well as, on-demand    activation. <= br> SB> You should get George Swallow to take a look at 4.4<= br> Mizrahi, et al.        Expire= s April 21, 2014          = ;      [Page 19] Internet-Draft&nb= sp;         Overview of OAM Tools&n= bsp;            Octo= ber 2013 4.5. MPLS-TP OAM 4.5.1. Overvi= ew    The MPLS working group has defined the OAM = toolset that fulfills the    requirements for MPLS-TP= OAM. The full set of requirements for MPLS-    TP OA= M are defined in [MPLS-TP-OAM], and include both general = requirements for the behavior of the OAM tools and a set of =    operations that should be supported by the OAM toolset.&nb= sp; The set of    mechanisms required are further ela= borated in [TP-OAM-FW], which    describes the genera= l architecture of the OAM system as well as    giving= overviews of the functionality of the OAM toolset. &= nbsp; Some of the basic requirements for the OAM toolset for MPLS-TP are:    o MPLS-TP OAM must be able to support both an I= P based and non-IP       based environ= ment. If the network is IP based, i.e. IP routing and &nb= sp;    forwarding are available, then the MPLS-TP OAM toolse= t should rely       on the IP routing = and forwarding capabilities. On the other hand,   &nb= sp;   in environments where IP functionality is not available, th= e OAM       tools must still be able t= o operate without dependence on IP     &nbs= p; forwarding and routing. SB> "should rely on the = IP routing and forwarding capabilities" That is SB> rat= her ambiguous. As I recall this is only to get responses SB>= back from MIPs where the path is broken. SB> -TP uses co-ro= uted bidirectional channels and again as I recall SB> the &q= uot;normal" response is back via that.    o = OAM packets and the user traffic are required to be congruent &= nbsp;     (i.e. OAM packets are transmitted in-band) an= d there is a need to       differentia= te OAM packets from data plane ones. Inherent in this &nb= sp;    requirement is the principle that MPLS-TP OAM be inde= pendent of       any existing control-= plane, although it should not preclude use of    = ;   the control-plane functionality. SB> So yo= u miss the key point in that we use L13 as an inband SB> OAM= discriminator. 4.5.2. Terminology Maintena= nce Entity (ME)    The MPLS-TP OAM tools are desi= gned to monitor and manage a    Maintenance Entity (M= E). An ME, as defined in [TP-OAM-FW], defines a &nb= sp; relationship between two points of a transport path to which    maintenance and monitoring operations apply.    The term Maintenance Entity (ME) is used in ITU-T Recommendat= ions    (e.g. [ITU-T-Y1731]), as well as in the MPLS-= TP terminology    ([TP-OAM-FW]). Main= tenance Entity Group (MEG) Mizrahi, et al.&= nbsp;       Expires April 21, 2014  = ;            &n= bsp; [Page 20] Internet-Draft     =      Overview of OAM Tools     = ;        October 2013    The collection of one or more MEs that belongs to the same t= ransport    path and that are maintained and monitore= d as a group are known as a    Maintenance Entity Gro= up (based on [TP-OAM-FW]). Maintenance Point (MP) <= br>   A Maintenance Point (MP) is a functional entity that is= defined at a    node in the network, and can initiat= e and/or react to OAM messages.    This document focu= ses on the data-plane functionality of MPs, while    = MPs interact with the control plane and with the management plane as   well.    The term MP is used i= n IEEE 802.1ag, and was similarly adopted in    MPLS-= TP ([TP-OAM-FW]). Maintenance End Point (MEP) <= tt>   A Maintenance End Point (MEP) is one of the end points of a= n ME, and    can initiate OAM messages and respond to= them (based on [TP-OAM-FW]). Maintenance Intermediate Poin= t (MIP)    In between MEPs, there are zero or mor= e intermediate points, called    Maintenance Entity G= roup Intermediate Points (based on [TP-OAM-FW]). &nbs= p; A Maintenance Intermediate Point (MIP) is an intermediate point th= at    does not generally initiate OAM frames (one exc= eption to this is the    use of AIS notifications), b= ut is able to respond to OAM frames that    are desti= ned to it. A MIP in MPLS-TP identifies OAM packets destined &nb= sp; to it by the value of the TTL field in the OAM packet. The term    Maintenance Point is a general term for MEPs and MI= Ps. Up and Down MEPs    The IEEE = 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs &nbs= p; and Down MEPs. A MEP is a bridge interface that is monitored by an=    OAM protocol either in the direction facing the n= etwork, or in the    direction facing the bridge. A D= own MEP is a MEP that receives OAM    packets from, a= nd transmits them to the direction of the network. An &nb= sp; Up MEP receives OAM packets from, and transmits them to the direction    of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses = a similar    distinction on the placement of the MEP = - either at the ingress,    egress, or forwarding fun= ction of the node (Down / Up MEPs). This    pla= cement is important for localization of a failure. = Mizrahi, et al.        Expires A= pril 21, 2014          &n= bsp;     [Page 21] Internet-Draft =          Overview of OAM Tools = ;            October= 2013    The distinction between Up and Down = MEPs was defined in [TP-OAM-FW],    but has not been = used in other MPLS-TP RFCs, as of the writing of    t= his document. 4.5.3. Generic Associated Channel    In order to address the requirement for in-band transmiss= ion of MPLS-    TP OAM traffic, MPLS-TP uses a Generi= c Associated Channel (G-ACh),    defined in [G-ACh] f= or LSP-based OAM traffic. This mechanism is based    = on the same concepts as the PWE3 ACH and VCCV mechanisms. However,    to address the needs of LSPs as differentiated from = PW, the following    concepts were defined for [G-ACh= ]:    o An Associated Channel Header (ACH), that = uses a format similar to       the PW = Control Word, is a 4-byte header that is prepended to OAM = ;     packets.    o A Generic= Associated Label (GAL). The GAL is a reserved MPLS label = ;     value (13) that indicates that the packet is an A= CH packet and the       payload follow= s immediately after the label stack.    It should= be noted that while the G-ACh was defined as part of the = ; MPLS-TP definition effort, the G-ACh is a generic tool that can be<= /tt>    used in MPLS in general, and not only in MPLS-TP.<= /tt> SB> Whilst historically what you say is true WRT PWE3, I= think the SB> approach confuses the reader, particularly as= they have not yet SB> met PWE3 in this document. 4.5.4. MPLS-TP OAM Toolset    To address th= e functionality that is required of the OAM toolset, the = MPLS WG conducted an analysis of the existing IETF and ITU-T OAM    tools and their ability to fulfill the required funct= ionality. The    conclusions of this analysis a= re documented in [OAM-Analys]. The MPLS    working gr= oup currently plans to use a mixture of OAM tools that are &nbs= p; based on various existing standards, and adapt them to the   requirements of [MPLS-TP-OAM]. Some of the main building = blocks of    this solution are based on: =    o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) fo= r       proactive continuity check and= connectivity verification.    o LSP Ping as defi= ned in [LSP-Ping] for on-demand connectivity    =    verification.    o New protocol pack= ets, using G-ACH, to address different     = functionality.    o Performance measuremen= t protocols that are based on the      = ; functionality that is described in [ITU-T-Y1731]. Miz= rahi, et al.        Expires April 21, 20= 14            &= nbsp;   [Page 22] Internet-Draft   = ;       Overview of OAM Tools  &nbs= p;          October 2013<= br>    The following sub-sections describe the OAM too= ls defined for MPLS-TP    as described in [TP-OAM-FW]= . 4.5.4.1. Continuity Check and Connectivity Verification    Continuity Check and Connectivity Verification = are presented in    Section 2.2.7. of this document.&= nbsp; As presented there, these tools may    be used = either proactively or on-demand. When using these tools &= nbsp; proactively, they are generally used in tandem.    For MPLS-TP there are two distinct tools, the proactive tool = is    defined in [TP-CC-CV] while the on-demand tool = is defined in    [OnDemand-CV]. In on-demand mode, th= is function should support    monitoring between the = MEPs and, in addition, between a MEP and MIP.    [TP-= OAM-FW] highlights, when performing Connectivity Verification,   the need for the CC-V messages to include unique identif= ication of    the MEG that is being monitored and the= MEP that originated the    message. =    The proactive tool [TP-CC-CV] is based on extensions to BFD (s= ee    Section 4.3.) with the additional limitation th= at the transmission    and receiving rates are based = on configuration by the operator. The    on-dem= and tool [OnDemand-CV] is an adaptation of LSP Ping (see = Section 4.4.) for the required behavior of MPLS-TP. = 4.5.4.2. Route Tracing    [MPLS-TP-OAM] defines t= hat there is a need for functionality that    would a= llow a path end-point to identify the intermediate and end- &nb= sp; points of the path. This function would be used in on-demand mode= .    Normally, this path will be used for bidirection= al PW, LSP, and    sections, however, unidirectional = paths may be supported only if a    return path exist= s. The tool for this is based on the LSP Ping (see = Section 4.4.) functionality and is described in [OnDemand-CV].<= br> 4.5.4.3. Lock Instruct    The Lock Ins= truct function [Lock-Loop] is used to notify a transport = path end-point of an administrative need to disable the transport    path. This functionality will generally be use= d in conjunction with    some intrusive OAM function,= e.g. Performance measurement, Diagnostic    testing,= to minimize the side-effect on user data traffic. = Mizrahi, et al.        E= xpires April 21, 2014         =        [Page 23] Internet-Dra= ft          Overview of OAM To= ols            = October 2013 4.5.4.4. Lock Reporting &= nbsp; Lock Reporting is a function used by an end-point of a path to = report    to its far-end end-point that a lock condit= ion has been affected on    the path. 4.5.4.5. Alarm Reporting    Alarm Reporting [TP-= Fault] provides the means to suppress alarms    follo= wing detection of defect conditions at the server sub-layer. &n= bsp; Alarm reporting is used by an intermediate point of a path, that=    becomes aware of a fault on the path, to report t= o the end-points of    the path. [TP-OAM-FW] states t= hat this may occur as a result of a    defect conditi= on discovered at a server sub-layer. This generates an &n= bsp; Alarm Indication Signal (AIS) that continues until the fault is   cleared. The consequent action of this function is detai= led in    [TP-OAM-FW]. 4.5.4.6. Remot= e Defect Indication    Remote Defect Indication (= RDI) is used proactively by a path end-    point to r= eport to its peer end-point that a defect is detected on a &nbs= p; bidirectional connection between them. [MPLS-TP-OAM] points out th= at    this function may be applied to a unidirectiona= l LSP only if there a    return path exists. [T= P-OAM-FW] points out that this function is    associa= ted with the proactive CC-V function. 4.5.4.7. Client Failu= re Indication    Client Failure Indication (CFI) = is defined in [MPLS-TP-OAM] to allow    the propagati= on information from one edge of the network to the   = other. The information concerns a defect to a client, in the case =    that the client does not support alarm notification.<= br> 4.5.4.8. Performance Monitoring    The= definition of MPLS performance monitoring was motivated by the    MPLS-TP requirements [MPLS-TP-OAM], but was defined generical= ly for    MPLS in [MPLS-LM-DM]. An additional documen= t [TP-LM-DM] defines a    performance monitoring prof= ile for MPLS-TP. 4.5.4.8.1. Packet Loss Measurement (LM)    Packet Loss Measurement is a function used to ve= rify the quality of    the service. Packet loss, as d= efined in [IPPM-1LM] and [MPLS-TP-OAM],    indicates = the ratio of the number of user packets lost to the total = ; number of user packets sent during a defined time interval. Mizrahi, et al.        Expi= res April 21, 2014         &nb= sp;      [Page 24] Internet-Draft&= nbsp;         Overview of OAM Tools=              Oc= tober 2013    There are two possible ways of = determining this measurement:    o Using OAM pack= ets, it is possible to compute the statistics based   = ;    on a series of OAM packets. This, however, has the disa= dvantage of       being artificial, an= d may not be representative since part of the    = ;   packet loss may be dependent upon packet sizes and upon the       implementation of the MEPs that t= ake part in the protocol.    o Sending delimiting= messages for the start and end of a measurement   &n= bsp;   period during which the source and sink of the path count = the       packets transmitted and rece= ived. After the end delimiter, the     &nbs= p; ratio would be calculated by the path OAM entity. SB>= This needs some references - To some of the early work and to the SB> more recent work by TI. SB> Note that this contr= adicts earlier statements about P2MP live SB> traffic measur= ement. 4.5.4.8.2. Packet Delay Measurement (DM)    Packet Delay Measurement is a function that is used to me= asure one-    way or two-way delay of a packet transm= ission between a pair of the    end-points of a path = (PW, LSP, or Section). Where:    o One-way packet= delay, as defined in [IPPM-1DM], is the time    = ;   elapsed from the start of transmission of the first bit of th= e       packet by a source node until = the reception of the last bit of      = that packet by the destination node. Note that one-way delay &= nbsp;     measurement requires the clocks of the two en= d-points to be       synchronized.    o Two-way packet delay, as defined in [IPPM-2DM],= is the time       elapsed from the st= art of transmission of the first bit of the    &= nbsp; packet by a source node until the reception of the last bit of = the       loop-backed packet by the sa= me source node, when the loopback is     &n= bsp; performed at the packet's destination node. Note that due to <= tt>      possible path asymmetry, the one-way pack= et delay from one end-       point to = another is not necessarily equal to half of the two-way &= nbsp;    packet delay.     &= nbsp; As opposed to one-way delay measurement, two-way delay measurement       does not require the two end-point= s to be synchronized.    For each of these two me= trics, the DM function allows the MEP to    measure t= he delay, as well as the delay variation. Delay measurement &nb= sp; is performed by exchanging timestamped OAM packets between the    participating MEPs. = Mizrahi, et al.        Expir= es April 21, 2014         &nbs= p;      [Page 25] Internet-Draft&n= bsp;         Overview of OAM Tools&= nbsp;            Oct= ober 2013 4.6. Pseudowire OAM 4.6.1. Ps= eudowire OAM using Virtual Circuit Connectivity Verification &n= bsp; (VCCV)    VCCV, as defined in [VCCV], = provides a means for end-to-end fault    detection an= d diagnostics tools to be extended for PWs (regardless of = ; the underlying tunneling technology). The VCCV switching function    provides a control channel associated with each PW.= [VCCV] defines    three Control Channel (CC) types, = i.e., three possible methods for    transmitting and = identifying OAM messages:    o CC Type 1: In-band= VCCV, as described in [VCCV], is also referred   &nb= sp;   to as "PWE3 Control Word with 0001b as first nibble&qu= ot;. It uses the       PW Associ= ated Channel Header [PW-ACH].    o CC Type 2: Out= -of-band VCCV [VCCV], is also referred to as "MPLS &= nbsp;    Router Alert Label". In this case the control = channel is created       by using the = MPLS router alert label [RFC3032] immediately above   = ;    the PW label.    o CC Type 3:= TTL expiry VCCV [VCCV], is also referred to as "MPLS PW &= nbsp;     Label with TTL =3D=3D 1", i.e., the cont= rol channel is identified when       t= he value of the TTL field in the PW label is set to 1. &nbs= p; VCCV currently supports the following OAM tools: ICMP Ping, LSP Pi= ng,    and BFD. ICMP and LSP Ping are IP encapsulated= before being sent over    the PW ACH. BFD for VCCV [= BFD-VCCV] supports two modes of    encapsulation - ei= ther IP/UDP encapsulated (with IP/UDP header) or    P= W-ACH encapsulated (with no IP/UDP header) and provides support to =    signal the AC status. The use of the VCCV control channel = provides    the context, based on the MPLS-PW label, = required to bind and    bootstrap the BFD session to = a particular pseudo wire (FEC),    eliminating the ne= ed to exchange Discriminator values.    VCCV cons= ists of two components: (1) signaled component to    = communicate VCCV capabilities as part of VC label, and (2) switching   component to cause the PW payload to be treated as a con= trol packet.    VCCV is not directly dependent up= on the presence of a control plane.    The VCCV capab= ility negotiation may be performed as part of the PW &nbs= p; signaling when LDP is used. In case of manual configuration of the<= br>   PW, it is the responsibility of the operator to set con= sistent    options at both ends. The manual option wa= s created specifically to    handle MPLS-TP use cases= where no control plane was a requirement.    However= , new use cases such as pure mobile backhaul find this &n= bsp; functionality useful too. SB> There is a strange lo= gic in the flow above - it is not depenent, it uses SB> the = CP - it can be configured Mizrahi, et al.  &n= bsp;     Expires April 21, 2014    =             [Page 26= ] Internet-Draft       &= nbsp; Overview of OAM Tools       =       October 2013   = ; The PWE3 working group has conducted an implementation survey of VCCV    [VCCV-SURVEY], which analyzes which VCCV mechanisms a= re used in    practice. 4.6.2. Pseudo= wire OAM using G-ACh    As mentioned above, VCCV = enables OAM for PWs by using a control    channel for= OAM packets. When PWs are used in MPLS-TP networks, &nbs= p; rather than the control channels defined in VCCV, the G-ACh can be<= br>   used as an alternative control channel. The usage of th= e G-ACh for    PWs is defined in [PW-G-ACh]. = 4.6.3. Attachment Circuit - Pseudowire Mapping SB&g= t; Isn't this message mapping?    The PWE3 workin= g group has defined a mapping and notification of    = defect states between a pseudowire (PW) and the Attachment Circuits   (ACs) of the end-to-end emulated service. This mapping is= of key    importance to the end-to-end functionality= . Specifically, the mapping    is provided by [PW-MAP= ], by [L2TP-EC] for L2TPv3 pseudowires, and    Sectio= n 5.3 of [ATM-L2] for ATM. 4.7. OWAMP and TWAMP 4.7.1. Overview SB> See my earlier note about wheth= er his is measuring SB> data plane performance or transport = layer performance.    The IPPM working group in t= he IETF defines common criteria and    metrics for me= asuring performance of IP traffic ([IPPM-FW]). Some of &n= bsp; the key RFCs published by this working group have defined metrics for<= /tt>    measuring connectivity [IPPM-Con], delay ([IPPM-1D= M], [IPPM-2DM]),    and packet loss [IPPM-1LM]. It sh= ould be noted that the work of the    IETF in the con= text of performance metrics is not limited to IP    n= etworks; [PM-CONS] presents general guidelines for considering new =    performance metrics.    The IPPM= working group has defined not only metrics for performance &nb= sp; measurement, but also protocols that define how the measurement i= s    carried out. The One-way Active Measurement Prot= ocol [OWAMP] and the    Two-Way Active Measurement Pr= otocol [TWAMP] define a method and    protocol for me= asuring performance metrics in IP networks.    OW= AMP [OWAMP] enables measurement of one-way characteristics of IP    networks, such as one-way packet loss and one-way delay.&nbs= p; For its    proper operation OWAMP requires accurat= e time of day setting at its    end points. <= br>   TWAMP [TWAMP] is a similar protocol that enables measur= ement of both    one-way and two-way (round trip) cha= racteristics. Mizrahi, et al.    &n= bsp;   Expires April 21, 2014      =           [Page 27] Internet-Draft          = Overview of OAM Tools         =     October 2013    OWAMP and = TWAMP are both comprised of two separate protocols: &= nbsp; o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop=       test sessions and to fetch their res= ults. Continuity Check and       Conne= ctivity Verification are tested and confirmed by establishing &= nbsp;     the OWAMP/TWAMP Control Protocol TCP connecti= on.    o OWAMP-Test/TWAMP-Test: used to exchange = test packets between two       measure= ment nodes. Enables the loss and delay measurement   =     functions, as well as detection of other anomalies, such= as packet       duplication and packe= t reordering.    It should be noted that while [O= WAMP] and [TWAMP] define tools for    performance mea= surement, they do not define the accuracy of these   = tools. The accuracy depends on scale, implementation and network <= tt>   configurations.    Alternative pr= otocols for performance monitoring are defined, for   = ; example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet<= br>   OAM [ITU-T-Y1731]. 4.7.2. Control and T= est Protocols    OWAMP and TWAMP control protocol= s run over TCP, while the test    protocols run over = UDP. The purpose of the control protocols is to &nb= sp; initiate, start, and stop test sessions, and for OWAMP to fetch   results. The test protocols introduce test packets = (which contain    sequence numbers and timestamps) al= ong the IP path under test    according to a schedule= , and record statistics of packet arrival.    Multipl= e sessions may be simultaneously defined, each with a session &= nbsp; identifier, and defining the number of packets to be sent, the = amount    of padding to be added (and thus the packet= size), the start time,    and the send schedule (whi= ch can be either a constant time between    test pack= ets or exponentially distributed pseudo-random). Statistics &nb= sp; recorded conform to the relevant IPPM RFCs. = ; OWAMP and TWAMP test traffic is designed with security in mind. Tes= t    packets are hard to detect because they are simp= ly UDP streams    between negotiated port numbers, wi= th potentially nothing static in    the packets. = ; OWAMP and TWAMP also include optional authentication &n= bsp; and encryption for both control and test packets. = 4.7.3. OWAMP    OWAMP defines the following logic= al roles: Session-Sender, Session-    Receiver, Serve= r, Control-Client, and Fetch-Client. The Session- &= nbsp; Sender originates test traffic that is received by the Session-<= br> Mizrahi, et al.        Ex= pires April 21, 2014         &= nbsp;      [Page 28] Internet-Draf= t          Overview of OAM Too= ls             = October 2013    Receiver. The Server co= nfigures and manages the session, as well as    retur= ning the results. The Control-Client initiates requests for <= tt>   test sessions, triggers their start, and may trigger their<= /tt>    termination. The Fetch-Client requests the r= esults of a completed    session. Multiple role= s may be combined in a single host - for    example, = one host may play the roles of Control-Client, Fetch-Client, &n= bsp; and Session-Sender, and a second playing the roles of Server and=    Session-Receiver.    In= a typical OWAMP session the Control-Client establishes a TCP &= nbsp; connection to port 861 of the Server, which responds with a ser= ver    greeting message indicating supported security= /integrity modes. The    Control-Client responds with= the chosen communications mode and the    Server acc= epts the modes. The Control-Client then requests and fully    describes a test session to which the Server responds with i= ts    acceptance and supporting information. Mo= re than one test session    may be requested with add= itional messages. The Control-Client then    st= arts a test session and the Server acknowledges. The Session-   Sender then sends test packets with pseudorandom padding = to the    Session-Receiver until the session is compl= ete or until the Control-    client stops the session= . Once finished, the Fetch-Client sends a    fe= tch request to the server, which responds with an acknowledgement <= tt>   and immediately thereafter the result data. 4.7.4. TWAMP    TWAMP defines the following logi= cal roles: session-sender, session-    reflector, ser= ver, and control-client. These are similar to the &= nbsp; OWAMP roles, except that the Session-Reflector does not collect any    packet information, and there is no need for a Fetc= h-Client.    In a typical TWAMP session the Contr= ol-Client establishes a TCP    connection to port 862= of the Server, and mode is negotiated as in    OWAMP= . The Control-Client then requests sessions and starts them. =    The Session-Sender sends test packets with pseudorandom pa= dding to    the Session-Reflector which returns them = with insertion of    timestamps. 4.8.= TRILL    The requirements of OAM in TRILL are de= fined in [TRILL-OAM]. The    challenge in TRILL OAM, = much like in MPLS networks, is that traffic    betwee= n RBridges RB1 and RB2 may be forwarded through more than one &= nbsp; path. Thus, an OAM protocol between RBridges RB1 and RB2 must b= e able    to monitor all the available paths between = the two RBridge. Mizrahi, et al.  &nb= sp;     Expires April 21, 2014    &= nbsp;           [Page 29]= Internet-Draft       &n= bsp; Overview of OAM Tools       &= nbsp;     October 2013   = During the writing of this document the detailed definition of the   TRILL OAM tools are still work in progress. This subsecti= on presents    the main requirements of TRILL OAM.    The main requirements defined in [TRILL-OAM] are= :    o Continuity Checking (CC) - the TRILL OAM p= rotocol must support a       function = for CC between any two RBridges RB1 and RB2.    o= Connectivity Verification (CV) - connectivity between two RBridges      RB1 and RB2 can be verified on a per-fl= ow basis.    o Path Tracing - allows an RBridge t= o trace all the available paths       = to a peer RBridge.    o Performance monitoring - = allows an RBridge to monitor the packet     = ; loss and packet delay to a peer RBridge. 4.9. Summa= ry of OAM Tools    This subsection provides a sho= rt summary of each of the OAM tool    categories desc= ribed in this document.    A detailed list of the= RFCs related to each category is given in    Appendi= x A.1.    +-----------+--------------------------= ----------------+------------+    | Category | = Description          &nbs= p;            &= nbsp;      | Transport | &= nbsp; |           | =             &nb= sp;            =             &nb= sp;   | Technology |    +-----------+------= ------------------------------------+------------+   = |IP Ping    | Ping ([IntHost], [NetTerms]) is a simple | IP= v4/IPv6 |    |     &nb= sp;     | application for testing reachability that|&nb= sp;           | <= tt>   |         &nbs= p; | uses ICMP Echo messages ([ICMPv4],      = |            |=    |         = ; | [ICMPv6]).         &= nbsp;           &nbs= p;         |    = ;        |    +---= --------+------------------------------------------+------------+ <= tt>   |IP         | Trace= route ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | &= nbsp; |Traceroute | an application that allows users to trace|  &= nbsp;         | &= nbsp; |           | the p= ath between an IP source and an IP |     &nb= sp;      |    |  &= nbsp;        | destination, i.e., to ide= ntify the nodes |         &nbs= p; |    |      &n= bsp;    | along the path. If more than one path  &= nbsp; |            |=    |        =    | exists between the source and destination|   =          |   = |           | Traceroute= traces *a* path. The most     |    = ;        |    |&nb= sp;          | common implemen= tation of Traceroute      |    = ;        |    |&nb= sp;          | uses UDP probe = messages, although there |       &= nbsp;    | Mizrahi, et al.  &n= bsp;     Expires April 21, 2014    =             [Page 30= ] Internet-Draft       &= nbsp; Overview of OAM Tools       =       October 2013   = ; |           | are other= implementations that use       |  =           | = |           | diff= erent probes, such as ICMP or TCP.   |    &nb= sp;       |    +-------= ----+------------------------------------------+------------+ &= nbsp; |BFD        | Bidirectional = Forwarding Detection (BFD) | generic    | = |           | is d= efined in [BFD] as a framework for a |      &= nbsp;     |    |   = ;        | lightweight generic OAM tool.= The       |    &nb= sp;       |    | &= nbsp;         | intention is to def= ine a base tool       |   &nbs= p;        |    |&n= bsp;          | that can be us= ed with various          = |            = |    |        = ;   | encapsulation types, network     &= nbsp;       |     &n= bsp;      |    |  =          | environments, and in var= ious medium      |     &n= bsp;      |    |  =          | types.   =             &nb= sp;            =        |      &= nbsp;     |    +-----------+-----= -------------------------------------+------------+   = ; |MPLS OAM   | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS&n= bsp;      |    |  =          | [MPLS-OAM-FW] and [LSP-P= ing], is an OAM |        &nbs= p;   |    |     &n= bsp;     | tool for point-to-point and   = ;           |  =           | = |           | poin= t-to-multipoint MLPS LSPs.        &= nbsp; |          &n= bsp; |    |       =     | It includes two main functions: Ping and |  =           | = |           | Trac= eroute.           &n= bsp;            = ;      |       =      |    |   &nbs= p;       | It is noted that while this catego= ry     |        = ;    |    |    &nb= sp;      | focuses on LSP Ping, other OAM tools&nb= sp;    |        &nbs= p;   |    |     &n= bsp;     | can be used in MPLS networks, e.g., BFD. |&n= bsp;           | =    +-----------+------------------------------------------+--= ----------+    |MPLS-TP OAM| MPLS-TP OAM is defined i= n a set of RFCs. | MPLS-TP    |    |&n= bsp;          | The OAM requir= ements for MPLS Transport |       =      |    |   &nbs= p;       | Profile (MPLS-TP) are defined in&n= bsp;        |    &nb= sp;       |    | &= nbsp;         | [MPLS-TP-OAM]. Each= of the tools in the |        = ;    |    |    &nb= sp;      | OAM toolset is defined in its own RFC, = as|            |    |        &nbs= p; | specified in Section A.1.      &nb= sp;         |   &nbs= p;        |    +--= ---------+------------------------------------------+------------+ =    |Pseudowire | The PWE3 OAM architecture defines control| P= seudowire |    |OAM     &nbs= p; | channels that support the use of existing|   &nbs= p;        |    |&n= bsp;          | IETF OAM tools= to be used for a pseudo- |       =      |    |   &nbs= p;       | wire (PW). The control chann= els that are|          &n= bsp; |    |       =     | defined in [VCCV] and [PW-G-ACh] may be | &= nbsp;          | &= nbsp; |           |= used in conjunction with ICMP Ping, LSP |    &nb= sp;       |    | &= nbsp;         | Ping, and BFD to pe= rform CC and CV       |   &nbs= p;        |    |&n= bsp;          | functionality.= In addition the channels |       =      |    |   &nbs= p;       | support use of any of the MPLS-TP = based |          &n= bsp; |    |       =     | OAM tools for completing their respective|  =           | = |           | OAM = functionality for a PW.        &nbs= p;     |        = ;    |    +-----------+---------------= ---------------------------+------------+ Mizrahi, et a= l.        Expires April 21, 2014 &n= bsp;            = ; [Page 31] Internet-Draft    &nb= sp;     Overview of OAM Tools    &n= bsp;        October 2013    |OWAMP and | The One Way Active Measurement Protoco= l | IPv4/IPv6 |    |TWAMP  &nbs= p;   | (OWAMP) and the Two Way Active Measure- |  = ;          | = ; |           | men= t Protocols (TWAMP) are two protocols |      =       |    |  &nbs= p;        | defined in the IP Performanc= e Metrics    |       &nbs= p;    |    |    &n= bsp;      | (IPPM) working group in the IETF. Thes= e |           = |    |       &nbs= p;   | protocols allow various performance    = ; |           = |    |       &nbs= p;   | metrics to be measured, such as packet   | =            | =    |           = | loss, delay and delay variation,       = ; |           = |    |       &nbs= p;   | duplication and reordering.     &= nbsp;        |    &n= bsp;       |    +------= -----+------------------------------------------+------------+ =    |TRILL OAM | The requirements of OAM in TRILL are &= nbsp;   | TRILL      | = ; |           | def= ined in [TRILL-OAM]. These        &= nbsp;   |         &n= bsp; |    |      =      | requirements include continuity checking,| =            | =    |           = | connectivity verification, path tracing |    &n= bsp;       |    | =           | and performance mo= nitoring. During the   |       = ;     |    |   &nb= sp;       | writing of this document the deta= iled    |        &nb= sp;   |    |     &= nbsp;     | definition of the TRILL OAM tools &nbs= p;      |       = ;     |    |   &nb= sp;       | is work in progress.  &= nbsp;           &nbs= p;      |       = ;     |    +-----------+---------= ---------------------------------+------------+   &nb= sp;            = Table 3 Summary of OAM-related IETF Tools 4.10. Summ= ary of OAM Functions    Table 4 summarizes the OA= M functions that are supported in each of    the cate= gories that were analyzed in this section. The columns of = ; this tables are the typical OAM functions described in Section 1.3.=        +-----------+-------+= --------+--------+-------+----------+     &= nbsp; |           |= Continu|Connecti|Path    |Perform|Other   &nb= sp; |        |   &= nbsp;       |ity    |vity = ;   |Discover|ance   |Function | &nbs= p;      |       = ;    |Check |Verifica|y     &= nbsp; |Monitor|s         | =        | Category |  &nbs= p;    |tion    |     = ;   |ing    |      &= nbsp;   |        +-----= ------+-------+--------+--------+-------+----------+ &nbs= p;     |IP Ping    |Echo   |&n= bsp;       |     &nb= sp; |       |    &n= bsp;     |      &n= bsp; + --------- + ----- + ------ + ------ + ----- + -------- +        |IP     &nbs= p;   |       |   &nb= sp;    |Tracerou|       | = ;         |   = ;     |Traceroute |      = |        |te    &nb= sp; |       |     &n= bsp;    |        += --------- + ----- + ------ + ------ + ----- + -------- + = ;      |BFD      &nb= sp; |BFD    |BFD     |   =      |       |RDI usi-&nb= sp; |        |   &= nbsp;       |Control|Control |  &nb= sp;     |       |ng BFD&n= bsp;   |        | =           |/ Echo |  = ;      |       = |       |Control   | &= nbsp;      + --------- + ----- + ------ + ------ += ----- + -------- + Mizrahi, et al.   &n= bsp;    Expires April 21, 2014     =            [Page 32]= Internet-Draft        &= nbsp; Overview of OAM Tools        =      October 2013    = ;    |MPLS OAM   |     &n= bsp; |"Ping" |"Tracero|     &= nbsp; |          |        |(LSP Ping) |    =    |mode    |ute"    | &n= bsp;     |       &nb= sp; |        |  &= nbsp;        |    &n= bsp; |        |mode  &nb= sp; |       |     &n= bsp;    |        += --------- + ----- + ------ + ------ + ----- + -------- + = ;      |MPLS-TP    |CC  &= nbsp; |CV/pro- |Route   |-LM    |-Diagnos- |=        |OAM   &nb= sp;    |       |active |= Tracing |-DM    | tic Test |    &= nbsp;   |         &n= bsp; |       |or on- |   = ;     |       |-Lock = ;    |        |&nb= sp;          |  &nbs= p;    |demand |      &nb= sp; |       |-Alarm    |<= br>       |     =       |       | = ;       |      = |       |Reporting | = ;      |       =     |       |   = ;     |        |&nbs= p;      |-Client   | &= nbsp;     |       &n= bsp;   |       |   &= nbsp;    |        | =       |Failure   | &nb= sp;     |       &nbs= p;   |       |   &nb= sp;    |        | &n= bsp;     |Indication|    &nb= sp;   |         &nbs= p; |       |     &nb= sp; |        |   &n= bsp;   |-RDI      | &n= bsp;     + --------- + ----- + ------ + ------ + ----- = + -------- +        |Pseudowire |= BFD    |-BFD    |LSP-Ping|   &= nbsp;   |          |=        |OAM   &nb= sp;    |       |-ICMP &nb= sp; |        |    &n= bsp; |          |       |     &= nbsp;     |       | Ping&= nbsp; |        |   =     |          = |        |    = ;       |      = |-LSP-   |        | &nbs= p;     |        = ; |        |  &nb= sp;        |    &nbs= p; | Ping   |        |&n= bsp;      |      &nb= sp;   |        + ------= --- + ----- + ------ + ------ + ----- + -------- +   =      |OWAMP and | - control   &nbs= p; |        |-Delay |  &= nbsp;       |    &= nbsp;   |TWAMP      |   protoc= ol     |        | me= asur|          | &= nbsp;      |      &n= bsp;    |        &nb= sp;       |     &nbs= p; | ement |          |<= /tt>        |    &= nbsp;      |      &n= bsp;         |   &nb= sp;    |-Packet|       &n= bsp; |        |  =          |    &= nbsp;           | &n= bsp;      | loss |    &n= bsp;     |      &n= bsp; |           | &= nbsp;           &nbs= p; |        | measur|  &= nbsp;       |    &= nbsp;   |         &n= bsp; |           &nb= sp;    |        | ement |=           | =       + --------- + ----- + ------ + ------ + ----= - + -------- +        |TRILL OAM&= nbsp; |CC     |CV      |Path&n= bsp;   |-Delay |        &= nbsp; |        |   = ;        |     = |        |tracing | measur| =          |   =      |        &= nbsp; |       |    =     |        | ement |&nb= sp;         | &nb= sp;     |       &nbs= p;   |       |   &nb= sp;    |        |-Packet|=           | =       |       &= nbsp;   |       |   =      |        | loss= |          |        |      = ;     |       | &nbs= p;      |       = ; | measur|          |       |     &n= bsp;     |       | &= nbsp;      |      &n= bsp; | ement |          |=        +-----------+-------+--------+= --------+-------+----------+      &nbs= p;   Table 4 Summary of the OAM Functionality in IETF OAM Tools 5. Security Considerations    This= memo presents an overview of existing OAM tools, and proposes =    no new OAM tools. Therefore, this document introduces no secur= ity Mizrahi, et al.      = Expires April 21, 2014       &nbs= p;        [Page 33] Inte= rnet-Draft          Overview o= f OAM Tools          &nbs= p; October 2013    considerations. Howe= ver, the OAM tools reviewed in this document can    a= nd do present security issues. The reader is encouraged to review <= tt>   the Security Considerations section of each document refere= nced by    this memo. 6. IANA Conside= rations    There are no new IANA considerations i= mplied by this document. 7. Acknowledgments    The authors gratefully acknowledge Sasha Vainshtein, Carlos    Pignataro, David Harrington, Dan Romascanu, Ron Bon= ica and other    members of the OPSAWG mailing list f= or their helpful comments.    This document was p= repared using 2-Word-v2.0.template.dot. 8. References<= br> 8.1. Informative References    [ATM-L2= ]      Singh, S., Townsley, M., and C. Pignataro,<= /tt>           &nb= sp;      "Asynchronous Transfer Mode (ATM) ov= er Layer 2         &nbs= p;        Tunneling Protocol Version 3 (= L2TPv3)", RFC 4454, May      &nbs= p;           2006.    [BFD]        = ; Katz, D., Ward, D., "Bidirectional Forwarding Detection =             &nb= sp;    (BFD)", RFC 5880, June 2010. &nb= sp; [BFD-Gen]     Katz, D., Ward, D., "Gener= ic Application of        &nb= sp;         Bidirectional Forwardin= g Detection (BFD)", RFC 5882,     &nbs= p;            June 2= 010.    [BFD-IP]      Ka= tz, D., Ward, D., "Bidirectional Forwarding Detection &nbs= p;            &= nbsp;   (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, Jun= e           &= nbsp;      2010.    [BFD= -LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and S= wallow,          &= nbsp;       G., "Bidirectional Forwardin= g Detection (BFD) for MPLS       =            Label Switched= Paths (LSPs)", RFC 5884, June 2010.    [BFD= -Multi]   Katz, D., Ward, D., "Bidirectional Forwarding Dete= ction          &nb= sp;       (BFD) for Multihop Paths", RFC= 5883, June 2010. Mizrahi, et al. =        Expires April 21, 2014  &nbs= p;             = [Page 34] Internet-Draft      = ;    Overview of OAM Tools     &nbs= p;       October 2013 &nb= sp; [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bid= irectional Forwarding        = ;          Detection (BFD) for= the Pseudowire Virtual Circuit      &= nbsp;           Connectiv= ity Verification (VCCV)", RFC 5885, June    = ;            &n= bsp; 2010.    [Comp]     = ;   Bonaventure, O., "Computer Networking: Principles,<= br>           &n= bsp;     Protocols and Practice", 2008.    [Cont]        Dugal, = D., Pignataro, C., Dunn, R., "Protecting the   &= nbsp;           &nbs= p; Router Control Plane", RFC 6192, March 2011. =    [Dup]         Uijterwa= al, H., "A One-Way Packet Duplication Metric", =             &nb= sp;   RFC 5560, May 2009.    [G-ACh]&nb= sp;      Bocci, M., Vigoureux, M., Bryant, S., &qu= ot;MPLS Generic         = ;         Associated Channel",= RFC 5586, June 2009.    [ICMP-Ext]  &n= bsp; Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP             &n= bsp;    Extensions for Multiprotocol Label Switching", = RFC           = ;       4950, August 2007. &n= bsp; [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C= ., Shen, N., Rivers,        =           JR., "Extending= ICMP for Interface and Next-Hop      =             Identifi= cation", RFC 5837, April 2010.    [ICMP-MP]&= nbsp;    Bonica, R., Gan, D., Tappan, D., Pignataro, C.,            =       "Extended ICMP to Support Multi-Part Me= ssages", RFC        &nb= sp;         4884, April 2007.<= br>    [ICMPv4]      Postel, J., = "Internet Control Message Protocol", STD 5, &nb= sp;            =    RFC 792, September 1981.    [ICMPv6]=       Conta, A., Deering, S., and M. Gupta, "= Internet Control        &nbs= p;         Message Protocol (ICMPv6= ) for the Internet Protocol       = ;           Version 6 (IP= v6) Specification", RFC 4443, March 2006.   = [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropol= itan          &nbs= p;       area networks - Media Access Control= (MAC) Bridges and        &n= bsp;         Virtual Bridged Local = Area Networks", October 2012.    [IEEE802.3a= h] IEEE 802.3, "IEEE Standard for Information technology -             &n= bsp;    Local and metropolitan area networks - Carrier sense=           &n= bsp;      multiple access with collision detection= (CSMA/CD)         &nbs= p;        access method and physical lay= er specifications",       &n= bsp;          clause 57, Decem= ber 2008. Mizrahi, et al.   &nbs= p;    Expires April 21, 2014     &n= bsp;          [Page 35] Internet-Draft        &nb= sp; Overview of OAM Tools        &n= bsp;    October 2013    [IntHo= st]     Braden, R., "Requirements for Internet Hos= ts --          &nb= sp;       Communication Layers", RFC 112= 2, October 1989.    [IPPM-1DM]    = Almes, G., Kalidindi, S., Zekauskas, M., "A One-way =             &nb= sp;   Delay Metric for IPPM", RFC 2679, September 1999.=    [IPPM-1LM]    Almes, G., Kalidindi,= S., Zekauskas, M., "A One-way     &nb= sp;            Packe= t Loss Metric for IPPM", RFC 2680, September   &= nbsp;           &nbs= p; 1999.    [IPPM-2DM]    Al= mes, G., Kalidindi, S., Zekauskas, M., "A Round-trip = ;            &n= bsp;   Delay Metric for IPPM", RFC 2681, September 1999.    [IPPM-Con]    Mahdavi, J., Paxson,= V., "IPPM Metrics for Measuring     &= nbsp;            Con= nectivity", RFC 2678, September 1999.    [IP= PM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Math= is, M.,          &= nbsp;       "Framework for IP Performanc= e Metrics", RFC 2330, May      &n= bsp;           1998.=    [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372= .1, "Operations,        = ;          Administration and = Maintenance mechanism for MPLS-TP      = ;            in Pack= et Transport Network (PTN)", November 2012. &nbs= p; [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,<= /tt>           &nb= sp;      administration and maintenance mechanisms= for MPLS-TP         &n= bsp;        networks using the tools def= ined for MPLS", November      &nb= sp;           2012.<= br>    [ITU-T-CT]    Betts, M., "Alloc= ation of a Generic Associated Channel     &= nbsp;            Typ= e for ITU-T MPLS Transport Profile Operation,    = ;            &n= bsp; Maintenance, and Administration (MPLS-TP OAM)", RFC &= nbsp;           &nbs= p;    6671, November 2012.    [ITU= -T-G.806] ITU-T Recommendation G.806, "Characteristics of =             &nb= sp;    transport equipment - Description methodology and            =       generic functionality", January 2009.    [ITU-T-Y1711] ITU-T Recommendation Y.1711, &quo= t;Operation & Maintenance      &nb= sp;           mechanism f= or MPLS networks", February 2004.    [ITU-T-= Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and =             = ;     Mechanisms for Ethernet-based Networks", Jul= y 2011.    [ITU-Terms]   ITU-R/ITU-T Te= rms and Definitions, online, 2013. Mizrahi, et = al.        Expires April 21, 2014 &= nbsp;           &nbs= p; [Page 36] Internet-Draft    &n= bsp;     Overview of OAM Tools    &= nbsp;        October 2013    [L2TP-EC]     McGill, N. and C. Pign= ataro, "Layer 2 Tunneling      &n= bsp;           Protocol V= ersion 3 (L2TPv3) Extended Circuit Status    &nb= sp;            = Values", RFC 5641, August 2009.    [Lock-Lo= op]   Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux,           &nb= sp;     M., Dai, X., "MPLS Transport Profile Lock = Instruct and         &n= bsp;        Loopback Functions", RF= C 6435, November 2011.    [LSP-Ping]  &= nbsp; Kompella, K., Swallow, G., "Detecting Multi-Protocol             &n= bsp;    Label Switched (MPLS) Data Plane Failures", RFC= 4379,          &n= bsp;       February 2006. &nb= sp; [Mng]         Farrel, A.,= "Inclusion of Manageability Sections in    = ;            &n= bsp; Path Computation Element (PCE) Working Group Drafts",             &n= bsp;    RFC 6123, February 2011.   = ; [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay            =       Measurement for MPLS Networks", RFC 637= 4, September         &n= bsp;        2011. = [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G., Al= lan, D.,          =         Matsushima, S., "Operations= and Management (OAM)        = ;          Requirements for Mu= lti-Protocol Label Switched (MPLS)     &nbs= p;            Networ= ks", RFC 4377, February 2006.    [MPLS-OAM-F= W] Allan, D., Nadeau, T., "A Framework for Multi-Protocol =             &nb= sp;    Label Switching (MPLS) Operations and Management=            &= nbsp;     (OAM)", RFC 4378, February 2006.    [MPLS-P2MP]   Yasukawa, S., Farrel, A., Kin= g, D., Nadeau, T.,        &n= bsp;         "Operations and M= anagement (OAM) Requirements for      =             Point-to= -Multipoint MPLS Networks", RFC 4687,    &n= bsp;            = ; September 2006.    [MPLS-TP-OAM] Vigoureux, M.,= Ward, D., Betts, M., "Requirements for    =             &nb= sp; OAM in MPLS Transport Networks", RFC 5860, May 2010. <= tt>   [NetTerms]    Jacobsen, O., Lynch, D., "= ;A Glossary of Networking       &= nbsp;          Terms", RF= C 1208, March 1991.    [NetTools]  &nbs= p; Enger, R., Reynolds, J., "FYI on a Network Management &= nbsp;           &nbs= p;    Tool Catalog: Tools for Monitoring and Debugging<= br>           &n= bsp;     TCP/IP Internets and Interconnected Devices&qu= ot;, RFC          =         1470, June 1993. Mizrahi, et al.        = Expires April 21, 2014         = ;       [Page 37] Internet-Dr= aft          Overview of OAM T= ools            = ; October 2013    [OAM-Analys] Sprecher= , N., Fang, L., "An Overview of the OAM Tool   &= nbsp;           &nbs= p; Set for MPLS based Transport Networks", RFC 6669,<= br>           &n= bsp;     July 2012.    [OAM-D= ef]     Andersson, L., Van Helvoort, H., Bonica, R., Ro= mascanu,          =         D., Mansfield, S., "Guideli= nes for the use of the OAM       =            acronym in the= IETF ", RFC 6291, June 2011.    [OAM-Label]=    Ohta, H., "Assignment of the 'OAM Alert Label' for           &nb= sp;     Multiprotocol Label Switching Architecture (MPL= S)           =        Operation and Maintenance (OAM) Functi= ons", RFC 3429,        =           November 2002.<= br>    [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., A= ggarwal, R. "MPLS       &nbs= p;          On-Demand Connecti= vity Verification and Route       = ;           Tracing"= , RFC 6426, November 2011.    [OWAMP]  =      Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,= and          &nbs= p;       Zekauskas, M., "A One-way Activ= e Measurement Protocol       &nbs= p;          (OWAMP)", RFC= 4656, September 2006.    [PARIS]  &nbs= p;    Brice Augustin, Timur Friedman and Renata Teixeira,            = ;      "Measuring Load-balanced Paths in the = Internet", IMC,        =           2007.    [PM-CONS]     Clark, A. and B. Claise, &= quot;Guidelines for Considering      &= nbsp;           New Perfo= rmance Metric Development", BCP 170, RFC    = ;            &n= bsp; 6390, October 2011.    [PW-ACH]  &= nbsp;   Bryant, S., Swallow, G., Martini, L., McPherson, D.,=            &= nbsp;     "Pseudowire Emulation Edge-to-Edge (PWE3= ) Control Word         =          for Use over an MPLS PSN&q= uot;, RFC 4385, February 2006.    [PW-G-ACh] = ;   Li, H., Martini, L., He, J., Huang, F., "Using the<= br>           &n= bsp;     Generic Associated Channel Label for Pseudowir= e in the          =         MPLS Transport Profile (MPLS-TP)= ", RFC 6423, November       =            2011. =    [PW-MAP]      Aissaoui, M., B= usschbach, P., Martini, L., Morrow, M.,     = ;             N= adeau, T., and Y(J). Stein, "Pseudowire (PW)   &= nbsp;           &nbs= p; Operations, Administration, and Maintenance (OAM) &nbs= p;            &= nbsp;   Message Mapping", RFC 6310, July 2011. <= tt>   [PW-Map]      M. Aissaoui, P. Buss= chbach, L. Martini, M. Morrow, T.      = ;            Nadeau,= "Pseudowire (PW) Operations, Administration,   =             &nb= sp; and Maintenance (OAM) Message Mapping", RFC 6310, July<= br>           &n= bsp;     2011. Mizrahi, et al. = ;       Expires April 21, 2014  &nb= sp;            = [Page 38] Internet-Draft     &nbs= p;    Overview of OAM Tools     &nb= sp;       October 2013 &n= bsp; [Reorder]     Morton, A., Ciavattone, L., Ra= machandran, G., Shalunov,       &= nbsp;          S., and J. Pers= er, "Packet Reordering Metrics", RFC   &nbs= p;            &= nbsp; 4737, November 2006.    [Signal]  = ;    Yasukawa, S., "Signaling Requirements for Point-to= -           &= nbsp;      Multipoint Traffic-Engineered MPLS Labe= l Switched         &nbs= p;        Paths (LSPs)", RFC 4461, = April 2006.    [TCPIP-Tools] Kessler, G., Shepard= , S., "A Primer On Internet and     &n= bsp;            TCP/= IP Tools and Utilities", RFC 2151, June 1997. &n= bsp; [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., "= Proactive          = ;        Connectivity Verification, Cont= inuity Check and Remote       &nb= sp;          Defect indication= for MPLS Transport Profile", RFC     =              64= 28, November 2011.    [TP-Fault]   = ; Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., = ;            &n= bsp;   "MPLS Fault Management Operations, Administration, an= d           &= nbsp;      Maintenance (OAM)", RFC 6427, Nove= mber 2011.    [TP-LM-DM]    Frost,= D., Bryant, S., "A Packet Loss and Delay   &nbs= p;            &= nbsp; Measurement Profile for MPLS-Based Transport   =             &nb= sp; Networks", RFC 6375, September 2011. &= nbsp; [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Admini= stration and         &n= bsp;        Maintenance Framework for MP= LS-based Transport        &n= bsp;         Networks ", RFC 6= 371, September 2011.    [TP-Term]  &nbs= p; Van Helvoort, H., Andersson, L., Sprecher, N., "A             &n= bsp;    Thesaurus for the Terminology used in Multiprotocol<= /tt>           &nb= sp;      Label Switching Transport Profile (MPLS-T= P)           =        drafts/RFCs and ITU-T's Transport Netw= ork           = ;       Recommendations", work-in-progre= ss, draft-ietf-mpls-        =           tp-rosetta-stone, Ju= ly 2012.    [TRILL-OAM]   Senevirathne,= T., Bond, D., Aldrin, S., Li, Y., Watve,    &nb= sp;            = R., "Requirements for Operations, Administration, and &nb= sp;            =     Maintenance (OAM) in Transparent Interconnection of=            &= nbsp;     Lots of Links (TRILL)", RFC 6905, March = 2013.    [TWAMP]     &nb= sp; Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and = ;            &n= bsp;   Babiarz, J., "A Two-Way Active Measurement Protocol           &nbs= p;      (TWAMP)", RFC 5357, October 2008.    [VCCV]        = Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit &nb= sp;            =     Connectivity Verification (VCCV): A Control Channel=            &= nbsp;     for Pseudowires", RFC 5085, December 200= 7. Mizrahi, et al.      &= nbsp; Expires April 21, 2014        = ;        [Page 39] Inter= net-Draft          Overview of= OAM Tools           = ; October 2013    [VCCV-SURVEY] Del Reg= no, N., Malis, A., "The Pseudowire (PW) &   =             &nb= sp; Virtual Circuit Connectivity Verification (VCCV) &nbs= p;            &= nbsp;   Implementation Survey Results", work-in-progress,            = ;      draft-ietf-pwe3-vccv-impl-survey-results, A= ugust 2013. Appendix A.    &nbs= p;            List o= f OAM Documents SB> My feeling is that this material wou= ld be better locate don a Wiki A.1. List of IETF OAM Docume= nts    Table 5 summarizes the OAM related RFCs pu= blished by the IETF.    It is important to note t= hat the table lists various RFCs that are    differen= t by nature. For example, some of these documents define OAM &n= bsp; tools or OAM protocols (or both), while others define protocols = that    are not strictly OAM-related, but are used by= OAM tools. The table    also includes RFCs that defi= ne the requirements or the framework of    OAM in a s= pecific context (e.g., MPLS-TP).    The RFCs in t= he table are categorized in a few sets as defined in &nbs= p; Section 1.3.    +-----------+-----------------= ---------------------+----------+    | Category = | Title           &= nbsp;           &nbs= p;        | RFC    &= nbsp; |    +-----------+-----------------------------= ---------+----------+    |IP Ping    |= Requirements for Internet Hosts --   | RFC 1122 | &n= bsp; |           | = Communication Layers [IntHost]       | &= nbsp;        |    = |           +------------= --------------------------+----------+    | &nbs= p;         | A Glossary of Networki= ng Terms       | RFC 1208 | = ; |           | [Ne= tTerms]           &n= bsp;            = ;   |          |    |        &nbs= p; +--------------------------------------+----------+ &n= bsp; |           | = Internet Control Message Protocol    | RFC 792 |<= br>   |         = | [ICMPv4]         &nbs= p;            &= nbsp;      |      &n= bsp;   |    |     =       +--------------------------------------+----= ------+    |       = ;    | Internet Control Message Protocol    |= RFC 4443 |    |      &= nbsp;    | (ICMPv6) for the Internet Protocol   |&= nbsp;         | &= nbsp; |           | Versi= on 6 (IPv6) Specification       |  =         |    |&nbs= p;          | [ICMPv6] &n= bsp;            = ;            &n= bsp; |          |   +-----------+--------------------------------------+----= ------+    |IP      &nb= sp; | A Primer On Internet and TCP/IP      |= RFC 2151 |    |Traceroute | Tools and Utilities [TCP= IP-Tools]    |       &nbs= p; |    |      &n= bsp;    +--------------------------------------+----------+<= /tt>    |        &= nbsp; | FYI on a Network Management Tool     | RF= C 1470 | Mizrahi, et al.     &= nbsp; Expires April 21, 2014       = ;         [Page 40] Internet-Draft          Overv= iew of OAM Tools          = ;   October 2013    |  &n= bsp;        | Catalog: Tools for Monitor= ing and    |        = |    |      &nbs= p;    | Debugging TCP/IP Internets and   &nbs= p;   |          |    |        &nb= sp; | Interconnected Devices [NetTools]    | &nbs= p;        |    |&n= bsp;          +---------------= -----------------------+----------+    |  &= nbsp;        | Internet Control Message = Protocol    | RFC 792 |    |&nbs= p;          | [ICMPv4] &n= bsp;            = ;            &n= bsp; |          |   |         &= nbsp; +--------------------------------------+----------+ = ; |           | Int= ernet Control Message Protocol    | RFC 4443 | &= nbsp; |           |= (ICMPv6) for the Internet Protocol   |    &n= bsp;     |    |   =         | Version 6 (IPv6) Specification=        |      &= nbsp;   |    |     = ;      | [ICMPv6]     &nb= sp;            =            |  &= nbsp;       |    | = ;          +------------------= --------------------+----------+    |  &nbs= p;        | Extended ICMP to Support Mul= ti-Part | RFC 4884 |    |   &nbs= p;       | Messages [ICMP-MP]  &nbs= p;            &= nbsp;   |          |=    |        =    +--------------------------------------+----------+    |          = ; | Extending ICMP for Interface and     | RFC 5837 |    |        &n= bsp; | Next-Hop Identification [ICMP-Int]   |  &n= bsp;       |    +------= -----+--------------------------------------+----------+ = |BFD        | Bidirectional Forwa= rding Detection   | RFC 5880 |    | &n= bsp;         | [BFD]  &nb= sp;            =             &nb= sp;    |        &nbs= p; |    |       &n= bsp;   +--------------------------------------+----------+   |         &= nbsp; | Bidirectional Forwarding Detection   | RFC 5881 |   |         &n= bsp; | (BFD) for IPv4 and IPv6 (Single Hop) |     =      |    |   &nbs= p;       | [BFD-IP]    &n= bsp;            = ;            | =          |   = |           +-----------= ---------------------------+----------+    | &nb= sp;         | Generic Application o= f Bidirectional | RFC 5882 |    |   &n= bsp;       | Forwarding Detection [BFD-Gen]&n= bsp;      |      &nb= sp;   |    |     &= nbsp;     +--------------------------------------+-----= -----+    |       =     | Bidirectional Forwarding Detection   | RFC 5= 883 |    |       &= nbsp;   | (BFD) for Multihop Paths [BFD-Multi] |   = ;       |    | &nb= sp;         +----------------------= ----------------+----------+    |   &n= bsp;       | Bidirectional Forwarding Detecti= on   | RFC 5884 |    |   &nb= sp;       | for MPLS Label Switched Paths (LS= Ps) |          | &= nbsp; |           |= [BFD-LSP]           = ;            &n= bsp;    |        &nb= sp; |    |       &= nbsp;   +--------------------------------------+----------+<= br>   |         = | Bidirectional Forwarding Detection   | RFC 5885 |   |         &= nbsp; | for the Pseudowire Virtual Circuit   |   &= nbsp;      |    |  = ;         | Connectivity Verificati= on (VCCV)     |      &nbs= p;   |    |     &n= bsp;     | [BFD-VCCV]     &nbs= p;            &= nbsp;        |    &n= bsp;     |    +-----------+------= --------------------------------+----------+    |MPLS= OAM   | Operations and Management (OAM)    &= nbsp; | RFC 4377 | Mizrahi, et al.   &nb= sp;    Expires April 21, 2014     &= nbsp;          [Page 41]<= br> Internet-Draft        &n= bsp; Overview of OAM Tools        &= nbsp;    October 2013    |&nbs= p;          | Requirements for= Multi-Protocol Label|         = ; |    |       &nb= sp;   | Switched (MPLS) Networks [MPLS-OAM] |  &n= bsp;       |    | =           +-------------------= -------------------+----------+    |   = ;        | A Framework for Multi-Protoco= l       | RFC 4378 |   = |           | Label Swit= ching (MPLS) Operations    |     &n= bsp;    |    |    =        | and Management (OAM) [MPLS-OAM-FW]&n= bsp; |          |   |         &= nbsp; +--------------------------------------+----------+ = ; |           | Det= ecting Multi-Protocol Label       | RFC 4379 = |    |        = ;   | Switched (MPLS) Data Plane Failures |  &nbs= p;       |    | &n= bsp;         | [LSP-Ping] &nbs= p;            &= nbsp;            |&n= bsp;         | &n= bsp; |           +-------= -------------------------------+----------+    | = ;          | Operations and Ma= nagement (OAM)      | RFC 4687 | = ; |           | Req= uirements for Point-to-Multipoint |      &nbs= p;   |    |     &n= bsp;     | MPLS Networks [MPLS-P2MP]   &= nbsp;        |    &n= bsp;     |    |   =         +-------------------------------= -------+----------+    |     = ;      | ICMP Extensions for Multiprotocol &n= bsp; | RFC 4950 |    |    &= nbsp;      | Label Switching [ICMP-Ext]  = ;         |    =       |    +-----------+----= ----------------------------------+----------+    |MP= LS-TP    | Requirements for OAM in MPLS-TP   =    | RFC 5860 |    |OAM   &n= bsp;    | [MPLS-TP-OAM]      &= nbsp;           &nbs= p;     |        = ; |    |      &nb= sp;    +--------------------------------------+----------+    |        &n= bsp; | MPLS Generic Associated Channel      = | RFC 5586 |    |      =      | [G-ACh]       = ;            &n= bsp;          |  &nb= sp;       |    | &= nbsp;         +--------------------= ------------------+----------+    |   =         | MPLS-TP OAM Framework &nb= sp;            = | RFC 6371 |    |     = ;      | [TP-OAM-FW]     =             &nb= sp;        |    &nbs= p;     |    |   &n= bsp;       +---------------------------------= -----+----------+    |     &= nbsp;     | Proactive Connectivity Verification, | RFC = 6428 |    |       =     | Continuity Check, and Remote Defect |  = ;        |    |&nb= sp;          | Indication for = the MPLS Transport    |      &= nbsp;   |    |     = ;      | Profile [TP-CC-CV]    = ;            &n= bsp; |          |   |         &= nbsp; +--------------------------------------+----------+ = ; |           | MPL= S On-Demand Connectivity        &nb= sp; | RFC 6426 |    |     &n= bsp;     | Verification and Route Tracing  &n= bsp;    |        &nb= sp; |    |       &= nbsp;   | [OnDemand-CV]       =             &nb= sp;    |        &nbs= p; |    |       &n= bsp;   +--------------------------------------+----------+   |         &= nbsp; | MPLS Fault Management Operations,    | RFC 6427 |    |        &nb= sp; | Administration, and Maintenance (OAM)|    &= nbsp;     |    |   = ;        | [TP-Fault]   &= nbsp;           &nbs= p;           |  = ;        |    |&nb= sp;          +----------------= ----------------------+----------+    |  &n= bsp;        | MPLS Transport Profile Loc= k Instruct | RFC 6435 | Mizrahi, et al.  &nbs= p;     Expires April 21, 2014    &n= bsp;           [Page 42]<= /tt> Internet-Draft       &nb= sp; Overview of OAM Tools       &n= bsp;     October 2013    = |           | and Loopbac= k Functions [Lock-Loop]   |      &n= bsp;   |    |     =       +--------------------------------------+----= ------+    |       = ;    | Packet Loss and Delay Measurement for| RFC 6374 |    |        &nbs= p; | MPLS Networks [MPLS-LM-DM]      &n= bsp;    |        &nb= sp; |    |       &= nbsp;   +--------------------------------------+----------+<= br>   |         = | A Packet Loss and Delay Measurement | RFC 6375 |    |          = | Profile for MPLS-Based Transport     |  &n= bsp;       |    | =           | Networks [TP-LM-DM= ]            &n= bsp;     |       &nb= sp; |    +-----------+-------------------------= -------------+----------+    |Pseudowire | Pseudowire= Virtual Circuit          = ; | RFC 5085 |    |OAM     &= nbsp; | Connectivity Verification (VCCV):    | &n= bsp;        |    |=            | A Control Ch= annel for Pseudowires    |     &nbs= p;    |    |    &n= bsp;      | [VCCV]     &n= bsp;            = ;             |=           | = |           +-----= ---------------------------------+----------+    |&nb= sp;          | Bidirectional F= orwarding Detection   | RFC 5885 |    |&nbs= p;          | for the Pseudowi= re Virtual Circuit   |       &= nbsp; |    |      = ;     | Connectivity Verification (VCCV)  &nb= sp; |          |   |         &n= bsp; | [BFD-VCCV]         &nbs= p;            &= nbsp;    |        &n= bsp; |    |       =     +--------------------------------------+----------+=    |         = ; | Using the Generic Associated Channel | RFC 6423 | &nb= sp; |           | L= abel for Pseudowire in the MPLS     |   =        |    | &nbs= p;         | Transport Profile (MPL= S-TP)          |  &n= bsp;       |    | =           | [PW-G-ACh] &n= bsp;            = ;             |=           | = |           +-----= ---------------------------------+----------+    |&nb= sp;          | Pseudowire (PW)= Operations,          | RFC 63= 10 |    |       &n= bsp;   | Administration, and Maintenance (OAM)|   =        |    | &nbs= p;         | Message Mapping [PW-Ma= p]             = |          | = ; +-----------+--------------------------------------+----------+    |OWAMP and | A One-way Active Measurement Proto= col| RFC 4656 |    |TWAMP    &nbs= p; | [OWAMP]          &nb= sp;            =        |      &= nbsp;   |    |     = ;      +--------------------------------------+---= -------+    |      &nbs= p;    | A Two-Way Active Measurement Protocol| RFC 5357 |    |        &nb= sp; | [TWAMP]         &n= bsp;            = ;        |     =      |    |   &nbs= p;       +-----------------------------------= ---+----------+    |     &nb= sp;     | Framework for IP Performance Metrics | RFC 23= 30 |    |       &n= bsp;   | [IPPM-FW]        = ;            &n= bsp;       |     &nb= sp;    |    |    &= nbsp;      +--------------------------------------= +----------+    |      =      | IPPM Metrics for Measuring   &nbs= p;       | RFC 2678 |   = ; |           | Connectiv= ity [IPPM-Con]          &= nbsp;   |          |=    |        =    +--------------------------------------+----------+    |          = ; | A One-way Delay Metric for IPPM      | RFC 267= 9 | Mizrahi, et al.      = Expires April 21, 2014       &nbs= p;        [Page 43] Inte= rnet-Draft          Overview o= f OAM Tools          &nbs= p; October 2013    |   &= nbsp;       | [IPPM-1DM]   &nb= sp;            =            |  &= nbsp;       |    | = ;          +------------------= --------------------+----------+    |  &nbs= p;        | A One-way Packet Loss Metric= for IPPM| RFC 2680 |    |    &nb= sp;      | [IPPM-1LM]     = ;            &n= bsp;         |   &nb= sp;      |    |  &= nbsp;        +--------------------------= ------------+----------+    |    =        | A Round-trip Delay Metric for IPPM&n= bsp; | RFC 2681 |    |    &= nbsp;      | [IPPM-2DM]    &nb= sp;            =           |   &= nbsp;      |    |  = ;         +------------------------= --------------+----------+    |   &nbs= p;       | Packet Reordering Metrics &nb= sp;          | RFC 4737 |=    |         = ; | [Reorder]         &n= bsp;            = ;      |       =    |    |     &nbs= p;     +--------------------------------------+--------= --+    |       &nb= sp;   | A One-Way Packet Duplication Metric | RFC 5560 |    |        &nb= sp; | [Dup]         &nbs= p;            &= nbsp;         |   &n= bsp;      |    +-----------+= --------------------------------------+----------+   = |TRILL OAM | Requirements for Operations,    &nb= sp;    | RFC 6905 |    |  &n= bsp;        | Administration, and Mainte= nance (OAM)|          |   |         &= nbsp; | in Transparent Interconnection of    |  &n= bsp;       |    | =           | Lots of Links (TRI= LL)            =     |          = |    +-----------+-----------------------------------= ---+----------+         = ;         Table 5 Summary of IETF O= AM Related RFCs A.2. List of Selected Non-IETF OAM Document= s    In addition to the OAM tools defined by the = IETF, the IEEE and ITU-T    have also defined various= OAM tools that focus on Ethernet, and    various oth= er transport network environments. These various tools, &= nbsp; defined by the three standard organizations, are often tightly   coupled, and have had a mutual effect on each other. The= ITU-T and    IETF have both defined OAM tools for MP= LS LSPs, [ITU-T-Y1711] and    [LSP-Ping]. The followi= ng OAM standards by the IEEE and ITU-T are to    some= extent linked to IETF OAM tools listed above and are mentioned    here only as reference material:   = o OAM tools for Layer 2 have been defined by the ITU-T in &nbs= p;     [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE8= 02.1Q] . The IEEE       802.3 standard= defines OAM for one-hop Ethernet links     = ; [IEEE802.3ah].    o The ITU-T has defined= OAM for MPLS LSPs in [ITU-T-Y1711], and    &nbs= p; MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. &n= bsp; It should be noted that these non-IETF documents deal in many ca= ses    with OAM functions below the IP layer (Layer 2= , Layer 2.5) and in Mizrahi, et al.  &nbs= p;     Expires April 21, 2014    &n= bsp;           [Page 44]<= /tt> Internet-Draft       &nb= sp; Overview of OAM Tools       &n= bsp;     October 2013    = some cases operators use a multi-layered OAM approach, which is a <= tt>   function of the way their networks are designed.    Table 6 summarizes some of the main OAM standards publis= hed by non-    IETF standard organizations. This docu= ment focuses on IETF OAM    standards, but these non-= IETF standards are referenced in this    document whe= re relevant.    +-----------+--------------------= ------------------+---------------+    |  &= nbsp;        | Title   &n= bsp;            = ;            &n= bsp;   |Standard/Draft |    +-----------+--= ------------------------------------+---------------+ &nb= sp; |ITU-T      | Operation & Maintenance mech= anism    | ITU-T Y.1711 |    |MP= LS OAM   | for MPLS networks [ITU-T-Y1711]    = ; |           =     |    |    &nbs= p;      +--------------------------------------+--= -------------+    |     &nbs= p;     | Assignment of the 'OAM Alert Label' | RF= C 3429      |    | &nbs= p;         | for Multiprotocol Labe= l Switching    |       &n= bsp;       |    | =           | Architecture (MPLS= ) Operation and    |      &nbs= p;        |    |&n= bsp;          | Maintenance (O= AM) Functions          | =             &nb= sp; |    |       &= nbsp;   | [OAM-Label]       &n= bsp;            = ;      |       =         |    |&nbs= p;          |   = ;            &n= bsp;            = ;          |   =             |   |         &= nbsp; | Note: although this is an IETF      = |            &n= bsp; |    |      =      | document, it is listed as one of the| = ;            &n= bsp; |    |       =     | non-IETF OAM standards, since it  &nbs= p; |            = ;   |    |     &nb= sp;     | was defined as a complementary part |&n= bsp;            = ; |    |      &nb= sp;    | of ITU-T Y.1711.     = ;            &n= bsp; |          &nb= sp;    |    +-----------+-------------= -------------------------+---------------+    |ITU-T&= nbsp;     | Operations, administration and  &= nbsp;    |ITU-T G.8113.2 |    |MPLS-TP= OAM| Maintenance mechanisms for MPLS-TP   |   &nb= sp;           | <= tt>   |         &nbs= p; | networks using the tools defined for |     &n= bsp;         | &n= bsp; |           | MPLS [= ITU-G8113.2]          &nb= sp;        |    &nbs= p;          | &nbs= p; |           |&nb= sp;            =             &nb= sp;            |&nbs= p;            &= nbsp; |    |       = ;    | Note: this document describes the   |=             &nb= sp; |    |      &= nbsp;    | OAM toolset defined by the IETF for | =             &nb= sp; |    |       &= nbsp;   | MPLS-TP, whereas ITU-T G.8113.1   = |           &= nbsp;   |    |     = ;      | describes the OAM toolset defined&n= bsp; |          &nb= sp;    |    |    &= nbsp;      | by the ITU-T.   =             &nb= sp;       |     &nbs= p;         | &nbs= p; |           +---------= -----------------------------+---------------+    |&n= bsp;          | Operations, Ad= ministration and       |ITU-T G.8113.1 |=    |         = ; | Maintenance mechanism for MPLS-TP in |    &nb= sp;          | &nb= sp; |           | P= acket Transport Network (PTN)       | &n= bsp;            = ; |    |       &nb= sp;   +--------------------------------------+---------------+    |        &nb= sp; | Allocation of a Generic Associated   | RFC 6671 =      | Mizrahi, et al.  &= nbsp;     Expires April 21, 2014    = ;            [Page 4= 5] Internet-Draft       =    Overview of OAM Tools       = ;      October 2013 &nbs= p; |           | Channel = Type for ITU-T MPLS Transport|       &nb= sp;       |    | &= nbsp;         | Profile Operation, = Maintenance, and |        &nb= sp;      |    |  &= nbsp;        | Administration (MPLS-TP O= AM)         |   &nbs= p;           |    |          = ; | [ITU-T-CT]          &= nbsp;           &nbs= p;    |         = ;      |    |  &nb= sp;        |    &nbs= p;            &= nbsp;           &nbs= p;        |     = ;          | = ; |           |&nbs= p; Note: although this is an IETF      | &nbs= p;             = |    |        = ;   | document, it is listed as one of the|  &nbs= p;            |=    |         = ; | non-IETF OAM standards, since it    | &= nbsp;           &nbs= p; |    |       &n= bsp;   | was defined as a complementary part |  &= nbsp;            |    |        &n= bsp; | of ITU-T G.8113.1.      &n= bsp;           | &nb= sp;            = |    +-----------+----------------------------------= ----+---------------+    |ITU-T   &nbs= p; | OAM Functions and Mechanisms for     | ITU-T= Y.1731 |    |Ethernet   | Ethernet-b= ased Networks          &n= bsp;   |         &nb= sp;     |    |OAM  &nbs= p;     | [ITU-T-Y1731]     &nb= sp;            =       |       &= nbsp;       |    +-----= ------+--------------------------------------+---------------+ =    |IEEE       | Connectivity Fault= Management        | IEEE 802.1ag = |    |CFM        |= [IEEE802.1Q]          &n= bsp;            = ; |           =     |    |    &nbs= p;      |       = ;            &n= bsp;            = ;      |       =         |    |&nbs= p;          | Note: CFM = was originally published |       &= nbsp;       |    | = ;          | as IEEE 802= .1ag, but is now         | &nb= sp;            = |    |       &nbs= p;   | incorporated in the 802.1Q standard.|  &nb= sp;            |    +-----------+--------------------------------------+-= --------------+    |IEEE     = ; | Management of Data Driven and Data   | IEEE 802.1ag&nbs= p; |    |DDCFM      | Depend= ent Connectivity Faults        | &n= bsp;            = ; |    |       &nb= sp;   | [IEEE802.1Q]       &nb= sp;            =      |        &= nbsp;      |    |  = ;         |    =             &nb= sp;            =          |    &= nbsp;          | &= nbsp; |           |= Note: DDCFM was originally published|     &= nbsp;         | &= nbsp; |           | = as IEEE 802.1Qaw, but is now        |&n= bsp;            = ; |    |      &nb= sp;    | incorporated in the 802.1Q standard.| &n= bsp;            = ; |    +-----------+---------------------------------= -----+---------------+    |IEEE   &nbs= p;   | Media Access Control Parameters,     |= IEEE 802.3ah |    |802.3   &nbs= p; | Physical Layers, and Management      |&= nbsp;           &nbs= p; |    |link level | Parameters for Subscriber= Access     |       =         |    |OAM&= nbsp;       | Networks [IEEE802.3ah] &nb= sp;            = |            &= nbsp; |    |      = ;     |        =             &nb= sp;            =      |        &= nbsp;      |    |  = ;         | Note: link level = OAM was originally |         &= nbsp;     |    |   = ;        | defined in IEEE 802.3ah= , and is now |          &= nbsp;    |    |    = ;       | incorporated in the 802.3 sta= ndard. |           &= nbsp;   |    +-----------+-----------------= ---------------------+---------------+     =      Table 6 Non-IETF OAM Standards Mentioned in this D= ocument Mizrahi, et al.    &nbs= p;   Expires April 21, 2014      &n= bsp;         [Page 46] = Internet-Draft          Ov= erview of OAM Tools         &n= bsp;   October 2013 Authors' Addresse= s    Tal Mizrahi    Marvell=    6 Hamada St.    Yokneam, 20= 692    Israel    Email: talmi@marvell.com    Nurit Sprecher    Nokia Siemens Network= s    3 Hanagar St. Neve Ne'eman B &= nbsp; Hod Hasharon,   45241    Israel<= br>    Email: nu= rit.sprecher@nsn.com    Elisa Bellagamba<= /tt>    Ericsson    6 Farogatan St.<= /tt>    Stockholm,   164 40 &n= bsp; Sweden    Phone: +46 761440785 &= nbsp; Email: elisa.b= ellagamba@ericsson.com    Yaacov Weingart= en    34 Hagefen St.    Karnei = Shomron,   4485500    Israel    Email: wyaacov@gmail.co= m Mizrahi, et al.&n= bsp;       Expires April 21, 2014  =             &nb= sp; [Page 47]On 17/10/2013 22:46, Tal Mizra= hi wrote:
Hi Benoit, Stewart,

Thanks for your effort to review the draft and for = the comments you sent. We highly appreciate it, and it has helped = to significantly improve the document.

We believe we res= olved the most significant issue, which is to accurately and clearly define= the scope and target audience, and to align the scope description to the a= ctual content of the document.
The main purpose of this mail is to make sure we resolved your= comments before we re-submit the draft and proceed with the request for fe= edback from the OPSA WG and the routing area WG.

Here is a list of modifications we made following your comments:=
1= .     = ; The most significan= t comment, from both Stewart and Benoit was about aligning expectations bet= ween the content of the document and the goal, target audience, and scope:<= br>We clarified the *scope* and the *target audience* in the = abstract and at the very beginning of the Introduction. Scope: about 2 y= ears ago we had a lot of discussions about the scope of the document, and b= ased on Ron Bonica’s advice we defined the current scope. Mainly, as = Ron said, we had to draw the line *somewhere* and no matter where we= drew the line someone would have objections. One of the things we decided = then, based on feedback from Stewart/Sasha was to removed descriptions of I= TU-T and IEEE OAM protocols. I agree with both your comments that the sc= ope was not crystal clear so far, and thus we have clarified the scope in t= he current draft:
- &n= bsp;        The draft does not include *all* OA= M activity in the IETF, but only IP unicast, MPLS, pseudowires, MPLS-TP, an= d TRILL.
= -   &nb= sp;      Focus on data-plane.
2.      <= span dir=3DLTR>Following a comment from Stewart: we added a s= ubsection about connection oriented vs. connectionless technologies, and po= int to point vs point to multipoint.
3.      Following a comment from Stewart, Benoit: We clarif= ied the text that explains the scope of OAM (in the introduction) based on = RFC 6291.
4.  &= nbsp;   Fol= lowing a comment from Benoit: We added an explicit quote of the OAM definit= ion from RFC 6291.
5.&n= bsp;     Following a comment from Stewart, Benoit: We changed the definition= s of control plane and data plane with Stewart’s help.
6.      Following a comment from St= ewart: we changed the definitions of OAM functions and OAM tools. Anothe= r comment from Stewart was that the terms ‘tool’ and ‘mec= hanism’ were used interchangeably in an inaccurate way. We replaced a= ll the potentially confusing instances of ‘mechanism’ by ‘= ;tool’.
7. &= nbsp;    Following a comment from Benoit: you have commented about the term ̵= 6;transport technology’. We completely removed this term from the doc= ument.

We are sending a word document = with tracked changes compared to the draft we sent you on the 17^{th of September.}
We plan t= o submit an updated draft before the 21^st of October deadline.

We will highly appreciate your comments.

Thanks,
= Tal.

From: Benoit Cl= aise [mailto:bclaise@cisco.com] Sent: Tuesday, October 08, 2013 4:46 PM To: draft-ietf-opsawg-oam-= overview@tools.ietf.org; Scott O. Bradner; opsawg-chairs@tools.ietf.org; Joel jaeggli Cc= : Stewart Bryant; Adrian Farrel; me Subject: draft-ietf-opsaw= g-oam-overview status

Dear all, Tal asked me to= discuss the draft-ietf-opsawg-oam-overview draft status. For the sa= ke of transparency, let me share my message with everybody. I copied the= document authors, Scott Bradner as the document shepherd, the OPSAWG-chair= s, and the routing ADs (Stewart and Adrian) Stewart, as the last DIS= CUSS holder (btw 2011) and Tal had a conf. call Five = or six minor issues Two major issues: = 1. Huge task, large scope going over all IETF pro= tocols 2. Must speak with your res= ponsible AD I sent back this document to the WG. See http://www.i= etf.org/mail-archive/web/opsawg/current/msg02931.html Tal and I = discussed: - The comparison with RFC6632, which is a overview with clae= ar objectives and target audience The OAM document is someh= ow the companion document to RFC 6632 - This document has got a = ; bigger task that the authors apparently thought it would be - The = document goal and audience are not clearly defined (actually it's spread al= l over the place) Who will want to be reading this document? What= for?

in th= is memo are applicable to IP unicast, MPLS, pseudowires, MPLS for the transport profile (MPLS-TP), and TRILL. While = OAM mechanisms that are applicable to oth= er technologies exist, they are beyond the = ; scope of this memo. Why not others?<= br>Section 1.4 Focusing on Data Plane OAM Tools The considerations of the control plane = maintenance tools and the functionality o= f the management plane are out of scope for this = ; document, which concentrates on presenting the data plane tools tha= t are used for OAM. You see, it's not clear from the beginning (the abstract) w= hat the focus is, who is the audience, and what the document goals are: the= re are pieces of it all over the place. = The overview of all OAM protocols in the IETF is a moving target. = You need a lot of energy to finish this document, and you must be qui= ck (moving target) - Do you want to classify the different OAM techn= iques as we did for RFC 6632, based on different criteria s? We had a= clear audience in mind when creating RFC 6632. For example, if you look wh= ich protocol(s) might be of interest to you, see &= nbsp; A.1. Protocols Classified by Standards Maturity in the IETF .....77= A.2. Protocols Matched to Management Tasks .............= .........79= A.3. Push versus Pull Mechanism ............= .....................80 A.4. Passive versus Active Monit= oring ...........................80 A.5. Supported Dat= a Model Types and Their Extensibility ........81 - The advice is to present during the OPSAWG to get some feedback = regarding the direction (focus, document goal, and target audience) for thi= s document: reduce scope versus cover all the OAM features in the IETF? = Also, the same talk should be done at the Routing Area (Stewart agreed to f= ind some time for it). Actually, the feedback from the routing guys is even= more important, as they are the guys specifying OAM techniques. So they wi= ll be the readers for this document (I guess) SOME MORE FEEDBACK &n= bsp; = ; +--------------+------------+ &= nbsp; | Category = ; | Transport | &n= bsp; = ; | = | Technology | &n= bsp; = ; +--------------+------------+ &= nbsp; |IP Ping&= nbsp; | IPv4/IPv6 | &= nbsp; +--------------+-----------= -+

&n= bsp; = ; |BFD &nb= sp; | generic |<= /pre> = ; +--------------+---= ---------+ &= nbsp; &nbs= p; |MPLS OAM | MPLS &n= bsp; | = ; &n= bsp; +--------------+------------+ &= nbsp; &nbs= p; |MPLS-TP OAM | MPLS-TP &n= bsp; | = ; += --------------+------------+ &= nbsp; &nbs= p; |Pseudowire OAM| Pseudowires| &nb= sp; = +--------------+------------+ &n= bsp; |OWAMP and= | IPv4/IPv6 | &nb= sp; = |TWAMP &n= bsp; | &nb= sp; | = &nb= sp; +--------------+------------+ &n= bsp; = ; |TRILL OAM | TRILL &= nbsp; | &nbs= p; &= nbsp; +--------------+------------+ = Ta= ble 1 Categories of OAM-related IETF Documents You should define what you mean by transport technology. It's not = L4 - Terminology It's key to have an OAM definition.It's true that you mentioned earlier: The= re are several different interpretations to the "OAM" acronym. This document refers to Operations, Adminis= tration and Maintenance, as recommended i= n [OAM-Def]. However, cut and paste th= e definition. Same remark for some other definitions. For example Control Plane The Control Plane, as described in [Cont], i= s generally described as the hardware and= software components for handling packets destined to = the device itself as well as building and sending packets orig= inated locally on the device.<= /pre>If it's a described in [cont], then copy it verba= tim - It's good that a single document contains the definitions of c= ontrol plane, data plane and management plane. - I stopped my= review at the end of section 2 Regards, Benoit &nb= sp; -- For corporate legal information go= to: http://www.cisco.= com/web/about/doing_business/legal/cri/index.html = <= /p>= --_000_74470498B659FA4687F0B0018C19A89C01D438CE63D5ILMB01marve_-- From sob@harvard.edu Tue Dec 17 11:25:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A4D1AE2FC for ; Tue, 17 Dec 2013 11:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbFEdAeQClVk for ; Tue, 17 Dec 2013 11:24:36 -0800 (PST) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 70A251AE1D2 for ; Tue, 17 Dec 2013 11:24:36 -0800 (PST) Received: from ENTWEDGE0000004.university.harvard.edu (entwedge0000004.university.harvard.edu [10.35.202.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 55795E9826 for ; Tue, 17 Dec 2013 14:24:35 -0500 (EST) Received: from ENTWHUBT0000005.university.harvard.edu (10.32.208.51) by entwedge0000004.university.harvard.edu (10.35.202.51) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 17 Dec 2013 14:24:34 -0500 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.83]) by ENTWHUBT0000005.university.harvard.edu ([10.32.208.51]) with mapi id 14.03.0146.000; Tue, 17 Dec 2013 14:24:35 -0500 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: draft-ietf-opsawg-oam-overview WGLC (again) Thread-Index: AQHO+12eeYMubdkUsUOIKskNjdAp7A== Date: Tue, 17 Dec 2013 19:24:34 +0000 Message-ID: <84657F87-5FC1-43BF-8D63-4367D827A84B@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.229.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D4AB9B6CD169D4995C6C6E951754D17@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] draft-ietf-opsawg-oam-overview WGLC (again) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 19:25:06 -0000 this message represents the start of a new WGLC for draft-ietf-opsawg-oam-= overview please take a look at the document and let the WG know what you think=20 please do so before Jan 7 tnx Scott http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-11= From warren@kumari.net Tue Dec 17 11:56:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140C1AE300 for ; Tue, 17 Dec 2013 11:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUnHR6tkI1bY for ; Tue, 17 Dec 2013 11:56:23 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF991AE287 for ; Tue, 17 Dec 2013 11:56:23 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id B75BA1B405B4; Tue, 17 Dec 2013 14:56:21 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Dec 2013 14:56:21 -0500 Message-Id: <052E826B-BDB7-46FC-A36B-434208A1EF09@kumari.net> To: opsawg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [OPSAWG] OPSAWG meeting in London -- asking for agenda time. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 19:56:24 -0000 Dear OpsAWG, It seems to have become a matter of standard practice for someone to = request time on the agenda to discuss a draft that we've never seen = before and which has received no discussion. We always write back and tell them there really needs to be discussion = on the mailing list so that we can gauge interest, relevance, and = quality, and so the author sends email to opsawg@ietf.org. =20 You can save yourself a round trip and some by starting a mailing list = discussion first. Remember, meeting time is primarily for resolving open questions and = issues, not for introducing new work or making a sales pitch for your = draft / idea. W -- Do not meddle in the affairs of dragons, for you are crunchy and taste = good with ketchup.=20 From stefan.winter@restena.lu Wed Dec 18 00:36:31 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB82C1AE325 for ; Wed, 18 Dec 2013 00:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHX36wM3ySW0 for ; Wed, 18 Dec 2013 00:36:29 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B39C91AE309 for ; Wed, 18 Dec 2013 00:36:28 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A6C0510584 for ; Wed, 18 Dec 2013 09:36:26 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 983DB10583 for ; Wed, 18 Dec 2013 09:36:26 +0100 (CET) Message-ID: <52B15E82.4090709@restena.lu> Date: Wed, 18 Dec 2013 09:36:18 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: opsawg@ietf.org X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lbI4M0SCpLKfcMbn8wE9XaafTRtrSIAM4" X-Virus-Scanned: ClamAV Subject: [OPSAWG] Upcoming I-D: EAP metadata format X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 08:36:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lbI4M0SCpLKfcMbn8wE9XaafTRtrSIAM4 Content-Type: multipart/mixed; boundary="------------090604070102060900060509" This is a multi-part message in MIME format. --------------090604070102060900060509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I'm currently in the process of writing an -00 I-D on an aspect of network management which has IMHO been neglected standards-wise so far: Configuration of EAP authentication, particularly in the IEEE 802.1X/WiFi space (but also relevant for other EAP-based network access control and ABFAB) - on the end-user device (i.e. EAP peer). The issue is that the IETF has produced EAP and EAP methods; they have many properties which need to be setup on the EAP server and matched as configuration items on the EAP peer. Deploying EAP is a complex task both for an EAP server operator *and for the users who have to setup everything correctly on their machine*. EAP is being used for WiFi, and there in an increasing manner in the buzzwordy "BYOD" scenarios; and a further use case comes up in "Hotspot 2.0" where the user does not have any particular relationship to the EAP server operator besides the desire for internet connectivity. In these scenarios, the EAP server operator does not have full administrative control over the end-user device; yet, a complex configuration task needs to be carried out on that device to make the EAP setup * functional (i.e. the end user must have set up enough parameters correctly to be able to authenticate to an EAP server at all) * secure (i.e. the end user must have set up all the parameters which ensure unambiguous mutual authentication to *only* his EAP server) * privacy-preserving (i.e. the end user is able to conceal his username from the EAP pass-through authenticator) In our EAP-based "eduroam" WiFi roaming consortium, we meanwhile have millions of users, thousands of EAP servers and thus just as many different EAP settings for users of those EAP servers. IOW, we have the operational capacity and enough real-life experience to credibly assert that initial EAP setup is a tough job if having to be done manually by the user. To alleviate the problem, it would be desirable to be able to convey the configuration information in a machine parseable way so that all the gory details need not be known/understood by the user. There is currently no standard way of communicating configuration parameters about an EAP setup to the EAP peer. Device manufacturers sometimes have developed their own proprietary configuration formats, e.g. Apple's "mobileconfig" (MIME type application/x-apple-aspen-config). Other devices at least provide an API for such configuration; if there were a standard way to communicate the settings to such a device, an application could consume the configuration information and create the necessary settings automatically. Android 4.3+ (API level 18) is one such example. Yet other devices do not have an API nor good UI for a manual setup. At least one device type developer base has communicated to us that if there were a standard way of getting EAP configuration data for WiFi OTA, they would likely make use of it. To overcome this proprietary/mixed-capability situation, we would like to propose that the IETF develops a metadata format which can communicate EAP settings and EAP method deployment details; with the eventual goal that EAP peer devices would be enabled to consume the file, act on it, and set up EAP in a complete, secure and (if so desired) privacy-preserving way. I have talked to the OPS ADs in Berlin, who encouraged me to go ahead with the specification and gave the advice that the place to take this to is opsarea/opsawg - hence this mail. We have already developed a preliminary XML specification which is rich enough to convey most if not all EAP deployment details, and which I hope serves as a good starting point for IETF work. I'll assemble an accompanying I-D which explains the current schema and documents the design decisions we've taken so far. I would appreciate discussion on the topic here in opsawg; and as soon as I've pushed out the draft itself, I'll be more than happy to receive comments and bashing ;-) (And if discussion does happen on the list, I'd also like to request a talking slot in the London meeting) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090604070102060900060509 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090604070102060900060509-- --lbI4M0SCpLKfcMbn8wE9XaafTRtrSIAM4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSsV6KAAoJEMDeajWKOdxmmaYP/iiBTdNES+LVWS2O5DgxuC97 ThVVIc12YO/MY/9rhXJ2EX3/wie5G2upD6tpfYCriMcLzMXHn6q95ikqM7TEYQPs MlLj0fJB8dPqNnVzY8Mm5yOyygr8yVFKaBSi9ZjRkwRJLLBAmnkCcpAoyD9ZGLS3 WyzJJallHZLN9NpVmRg4xTvVKELPgZ35FNhsz70+ybsIF4W9KmRQ8yQQZ6fhDiBF f802zMlAKL4kVfSa8evKgHLFY4VkuSM640Akzt1H+1dn64SOum3pBhuHpRoRSVVy nEGGRfzlifeSVLjL5WFokroPYMDpMKB5UOors9q26XD7qVTLDGvb6D9Bj3dH1jmL AfoUpUJMix2QK9arijy/HGKzWxvDlQLvU6UBXZJiIONQdQE8nODM1qCpCKHlOL2e qTNY6XOnOiNvgGrGM1GlKfKkJ2YlmoWswMOBtdLnRCy0D+UiaU+UP0PIpqwgKpbo YHK3Bgp8OYPBsKtADfH2b7jFzzXg+c4xkz6sxkaJRdH8kMXYEBIaIBNoi7ltenrn 9oG6LU+DfKBfeM2hDRRwZVZl/+FHYFhPAihlRBJ8WGASNMmb7UOC8LcqVR59GVXB ZKer1T7frIxLk+xr9dcXwu7M4UnKt92w1S7NqytXlixBKPSbknav1AwAbi/EHwWH h8/78/ygdto9BR49NCD8 =TCqZ -----END PGP SIGNATURE----- --lbI4M0SCpLKfcMbn8wE9XaafTRtrSIAM4-- From tom.taylor.stds@gmail.com Sat Dec 21 10:52:30 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382AD1AE00A; Sat, 21 Dec 2013 10:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQZI55N11zmd; Sat, 21 Dec 2013 10:52:28 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 37F671ADFF7; Sat, 21 Dec 2013 10:52:28 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id uy17so9985469igb.4 for ; Sat, 21 Dec 2013 10:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zQJwjSAUrpiQmBS6AWhTr7ohXS90TPSRLRGI6FHKEbo=; b=lBS3jQ6kbl2RdF0/SeExezDs0v/rRwR9Da16HYVL8Tto+q5b/LisMd0ffaYUUiD0uv /Hvn50jAWdK5DZHamIQcNp0sHMVoTq5ZlT4Th+t/2WI28Yk2DCfZSN7xogRhyafXszjn qhDHJkadVM8bvRp4/M2eVZUiUfm92FJutaVfT9lxHCFoL9TsQgCR4gPuR3FZ6e4k/FKw uO7curr+mQtL0y81jZIG+dY3aJ8X41YzfxmlgkOycJTzMb4cv0v4426d91eoGdzQsJ1S cHwaWLpRtl1emkJOtn6c9r0o8aBkjFEQAYRT0/LYjZs8n3OFOgpr85zDlcVJaHacchym WXZQ== X-Received: by 10.43.140.77 with SMTP id iz13mr10569101icc.47.1387651945460; Sat, 21 Dec 2013 10:52:25 -0800 (PST) Received: from [192.168.97.185] ([67.210.160.130]) by mx.google.com with ESMTPSA id nh7sm16168110igb.7.2013.12.21.10.52.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Dec 2013 10:52:24 -0800 (PST) Message-ID: <52B5E367.2090901@gmail.com> Date: Sat, 21 Dec 2013 13:52:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 18:52:30 -0000 I know there is minimal chance of a response at this time of year, but it would be nice to get on with this work. Up to now, the SYSLOG-based NAT logging document has identified individual subscriber sites using identifiers the nature of which is indicated in the text below. In addition, it has used realm identifiers. We are now proposing to rationalize the situation by having the realm absorb all of the other information. In the case of DS-Lite, however, this has an operational impact: administrative action is required to assign a realm identifier to every individual subscriber site served by a DS_Lite tunnel. Is this reasonable, or should realms apply at a more aggregate level? The text that follows would replace existing text in the SYSLOG NAT document talking about realms and subscriber site identifiers. The MIB and IPFIX logging documents would also align themselves with this text. Tom Taylor --------------------- A realm identifies an IP numbering space. A NAT session always maps between an interior and an exterior realm. In simple NAT configurations, it may be possible to identify a default interior realm and/or a default exterior realm for all sessions. Address pools are associated with specific exterior realms. It is necessary to define multiple realms when multiple IP numbering spaces exist. A NAT may distinguish realms in its mapping tables in different ways, depending on implementation and deployment. Examples follow shortly. For external presentation, however, logging will use the realm number. The NAT MIB [reference] provides a mapping between realm number and an administratively-provided realm name, and may provide further information relating that to other information corresponding more closely to the representation by the NAT in its internal tables. A NAT recognizes the incoming realm by three basic means: - at the physical level, by incoming interface; - at layer 2, by incoming VLAN, VLAN stack, or VPN; - at layer 3: -- by PE-based VPN based on incoming destination address and possibly other packet header information and forwarded using VPNs based either on BGP/MPLS or Virtual Routers, or -- by incoming tunnel, typical of various transition technologies. [RFC 4026] is useful to sort out the various VPN concepts. The rest of this description deals with specific cases of layer 3 tunnels associated with transition technologies. The administrator has to be aware of these descriptions for the purpose of assigning realm names to the entities involved, while the NAT designer needs to understand how to implement both NAT operation in the cases described and the mapping between the identifiers concerned and the realm identifier. DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It features an encapsulating/decapsulating service combined with a very large scale NAT44 in the provider network (the Address Family Transitional Router, AFTR). Every outbound IPv4 packet has a source address within the reserved 192.0.0.0/29 range. As a result, Section 6.6 of [RFC 6333] has the following advice on NAT operation for DS-Lite: "6.6. Extended Binding Table The NAT binding table of the AFTR element is extended to include the source IPv6 address of the incoming packets. This IPv6 address is used to disambiguate between the overlapping IPv4 address space of the service provider customers." In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 address of the encapsulating tunnel from the customer device. Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC 6674]. It is based primarily on the aggregation of traffic from a particular access gateway through a single softwire to the AFTR. Within that tunnel, a context identifier identifies the flow of traffic from a particular customer device. The IPv4 source address in outbound packets thus becomes irrelevant for routing, whether or not it is unique. In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from the combination of softwire identifier and context identifier. Section 6 of [RFC 6674] describes the combinations of identifiers that might be deployed, depending on the operator circumstances. Sections 3 and 4 of [RFC 6674] go into the details of NAT operation for Gateway-Initiated DS-Lite. From rajiva@cisco.com Sat Dec 21 18:24:20 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355281AE142; Sat, 21 Dec 2013 18:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVwQCD0JpX_9; Sat, 21 Dec 2013 18:24:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A61341AE141; Sat, 21 Dec 2013 18:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5243; q=dns/txt; s=iport; t=1387679055; x=1388888655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=93BrR2hTpXxCSzxcxgLij+hHl64QQ8MvDgIAT2urhNI=; b=Vv8M5RkoRok9hpvWjzJX4yhPwC1XdL9FHggVP7WnPQbYsbVylheeankb XQh21LM/QGIsFfryjyka24Iot2BxHiI1tlt93Faxqw4i1e3+RSEfAFlXk v3Kaa5fqzWwRrj3dge9RE+SD0gN+ol8fDGoKGSsMog53/E88jflJnVcfq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPdMtlKtJXG8/2dsb2JhbABOCoMLOLlGT4ESFnSCJQEBAQMBAQEBNzQLBQsCAQg2ECEGCyUCBA4Fh3ADCQgNw38NhlITBI0SgTcpMweDI4ETBJYrgWyMWoU6gy0 X-IronPort-AV: E=Sophos;i="4.95,529,1384300800"; d="scan'208";a="8416541" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 22 Dec 2013 02:24:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBM2O3A6016713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 02:24:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sat, 21 Dec 2013 20:24:03 -0600 From: "Rajiv Asati (rajiva)" To: Tom Taylor Thread-Topic: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging Thread-Index: AQHO/n3T84s7bgy1Okq7+apKkTaFvJpffMe4 Date: Sun, 22 Dec 2013 02:24:03 +0000 Message-ID: <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> References: <52B5E367.2090901@gmail.com> In-Reply-To: <52B5E367.2090901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 22 Dec 2013 08:08:35 -0800 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 02:24:20 -0000 > In the case of DS-Lite, however, this has an operational impact: administ= rative action is required to assign a realm identifier to every individual = subscriber site served by a DS_Lite tunnel. Reading section 6, the incoming realm identifier refers/includes the IPv6 a= ddress of the encapsulating tunnel (from the customer device). Why is an ad= min action required? Cheers, Rajiv Sent from my Phone On Dec 22, 2013, at 12:22 AM, "Tom Taylor" wrot= e: > I know there is minimal chance of a response at this time of year, but it= would be nice to get on with this work. >=20 > Up to now, the SYSLOG-based NAT logging document has identified individua= l subscriber sites using identifiers the nature of which is indicated in th= e text below. In addition, it has used realm identifiers. We are now propos= ing to rationalize the situation by having the realm absorb all of the othe= r information. In the case of DS-Lite, however, this has an operational imp= act: administrative action is required to assign a realm identifier to ever= y individual subscriber site served by a DS_Lite tunnel. >=20 > Is this reasonable, or should realms apply at a more aggregate level? >=20 > The text that follows would replace existing text in the SYSLOG NAT docum= ent talking about realms and subscriber site identifiers. The MIB and IPFIX= logging documents would also align themselves with this text. >=20 > Tom Taylor >=20 > --------------------- >=20 > A realm identifies an IP numbering space. A NAT session always maps betwe= en an interior and an exterior realm. In simple NAT configurations, it may = be possible to identify a default interior realm and/or a default exterior = realm for all sessions. >=20 > Address pools are associated with specific exterior realms. >=20 > It is necessary to define multiple realms when multiple IP numbering spac= es exist. A NAT may distinguish realms in its mapping tables in different w= ays, depending on implementation and deployment. Examples follow shortly. F= or external presentation, however, logging will use the realm number. The N= AT MIB [reference] provides a mapping between realm number and an administr= atively-provided realm name, and may provide further information relating t= hat to other information corresponding more closely to the representation b= y the NAT in its internal tables. >=20 > A NAT recognizes the incoming realm by three basic means: > - at the physical level, by incoming interface; > - at layer 2, by incoming VLAN, VLAN stack, or VPN; > - at layer 3: > -- by PE-based VPN based on incoming destination address and > possibly other packet header information and forwarded > using VPNs based either on BGP/MPLS or Virtual Routers, or > -- by incoming tunnel, typical of various transition technologies. > [RFC 4026] is useful to sort out the various VPN concepts. >=20 > The rest of this description deals with specific cases of layer 3 tunnels= associated with transition technologies. The administrator has to be aware= of these descriptions for the purpose of assigning realm names to the enti= ties involved, while the NAT designer needs to understand how to implement = both NAT operation in the cases described and the mapping between the ident= ifiers concerned and the realm identifier. >=20 > DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It featu= res an encapsulating/decapsulating service combined with a very large scale= NAT44 in the provider network (the Address Family Transitional Router, AFT= R). Every outbound IPv4 packet has a source address within the reserved 192= .0.0.0/29 range. As a result, Section 6.6 of [RFC 6333] has the following a= dvice on NAT operation for DS-Lite: >=20 > "6.6. Extended Binding Table >=20 > The NAT binding table of the AFTR element is extended to include the > source IPv6 address of the incoming packets. This IPv6 address is > used to disambiguate between the overlapping IPv4 address space of > the service provider customers." >=20 > In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 ad= dress of the encapsulating tunnel from the customer device. >=20 > Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC = 6674]. It is based primarily on the aggregation of traffic from a particula= r access gateway through a single softwire to the AFTR. Within that tunnel,= a context identifier identifies the flow of traffic from a particular cust= omer device. The IPv4 source address in outbound packets thus becomes irrel= evant for routing, whether or not it is unique. >=20 > In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from t= he combination of softwire identifier and context identifier. Section 6 of = [RFC 6674] describes the combinations of identifiers that might be deployed= , depending on the operator circumstances. Sections 3 and 4 of [RFC 6674] g= o into the details of NAT operation for Gateway-Initiated DS-Lite. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Sun Dec 22 08:56:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8A1AE660; Sun, 22 Dec 2013 08:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzBChNAkKE2t; Sun, 22 Dec 2013 08:56:22 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5A54F1AE725; Sun, 22 Dec 2013 08:56:22 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so19302079igb.0 for ; Sun, 22 Dec 2013 08:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=puk/gJqjpmKqCaEYFRWSEWHc7I4Jlis9F+ms0Bf2Lps=; b=rDGgk4x14bRJsb7C6DjAbaLNYayFdcd6HTPHaLzQOLbrq6gL7CADriR/bLx4rJlKzr AUejS1/qCqakJaDRwca7mcK0bSVgxYwCnNX3ZOpdMuelxEs0Vud828PXoXUGHOF2hjb7 /TOQdeYyZ74RCCJeg+VLgAmZMdPun7fxIYe7thMLUxUvRYpochFijp5K3yQAg/QKY/aP eWh8rZdtFxHYkq1dGpBke1p0SrBj+kdt63SEB/JPPZVSKXligrY0bTDNXU6ft2wi2QE9 4GvwV/dnwtE3Gs/NxxXeaKLzU6u+TMftrC/8hyxbTUnmPzIhWSs6np9wTQJJ4v9snlKK 53Yg== X-Received: by 10.50.21.2 with SMTP id r2mr10800046ige.13.1387731379355; Sun, 22 Dec 2013 08:56:19 -0800 (PST) Received: from [192.168.97.185] ([67.210.160.130]) by mx.google.com with ESMTPSA id kb10sm20121717igb.6.2013.12.22.08.56.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Dec 2013 08:56:18 -0800 (PST) Message-ID: <52B719B2.5000706@gmail.com> Date: Sun, 22 Dec 2013 11:56:18 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <52B5E367.2090901@gmail.com> <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> In-Reply-To: <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [OPSAWG] [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 16:56:24 -0000 Sorry, section 6 of which document? Section 2.3.1 of the SYSLOG document http://www.ietf.org/id/draft-ietf-behave-syslog-nat-logging-05.txt is the most relevant to this discussion. What is termed a generalized internal address in that section represents the prior point of view: that the realm has to be qualified with further information to identify the subscriber site uniquely. The fact is that the characterization in that section is incomplete -- the qualifying information required can also include VLAN and VRF identifiers. I guess the proposed new text effectively incorporates the generalized internal address information into the realm name, so the administrative action required would be something that does that automatically. Tom On 21/12/2013 9:24 PM, Rajiv Asati (rajiva) wrote: >> In the case of DS-Lite, however, this has an operational impact: >> administrative action is required to assign a realm identifier to >> every individual subscriber site served by a DS_Lite tunnel. > > Reading section 6, the incoming realm identifier refers/includes the > IPv6 address of the encapsulating tunnel (from the customer device). > Why is an admin action required? > > Cheers, Rajiv > > Sent from my Phone > .... From internet-drafts@ietf.org Mon Dec 23 07:43:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939171AE0D6; Mon, 23 Dec 2013 07:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUYZY-CYbWqQ; Mon, 23 Dec 2013 07:43:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD41ADEBA; Mon, 23 Dec 2013 07:43:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131223154337.26504.15405.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2013 07:43:37 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 15:43:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : CGN Deployment with BGP/MPLS IP VPNs Authors : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-04.txt Pages : 20 Date : 2013-12-23 Abstract: This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-lsn-deployment-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bclaise@cisco.com Mon Dec 23 08:11:11 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19641AE0E3 for ; Mon, 23 Dec 2013 08:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 927nkB_2QbT9 for ; Mon, 23 Dec 2013 08:11:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 96E821AE0E2 for ; Mon, 23 Dec 2013 08:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7623; q=dns/txt; s=iport; t=1387815065; x=1389024665; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Y0LvCSvZPi/NRzZnYtXt1JgaV5uGqVJkwmMoYRTq60s=; b=Q8wqN6cr94wES2TXbiGmXXWkMVXxVjlCnwTRufZxvp0rigfIAKuhtTwa wQMxHoD54ACYQAIYRsANgGZ2JAasnPXoCdjSqEqOPSkIInPZ9rASYtA+K Mfns7p0J+zm4FNBsdNdnW7IcUX2tNW7fPcy+ZKIDlhMntKtGDYPYl2B/D c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAFpfuFKQ/khR/2dsb2JhbABZgws4T4hksBNPgRwWdIImAQEEAQEBZAcLEAshJQ8CFjAGDQEFAgEBBYd7CAXLDBePJQcJhC0EmBeBMIUVi0+DLjs X-IronPort-AV: E=Sophos;i="4.95,537,1384300800"; d="scan'208,217";a="2685719" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 23 Dec 2013 16:11:04 +0000 Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBNGB4LU022941; Mon, 23 Dec 2013 16:11:04 GMT Message-ID: <52B86098.50404@cisco.com> Date: Mon, 23 Dec 2013 17:11:04 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Victor Kuarsingh References: <20131223154337.26504.15405.idtracker@ietfa.amsl.com> In-Reply-To: <20131223154337.26504.15405.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010603060509070107070808" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 16:11:11 -0000 This is a multi-part message in MIME format. --------------010603060509070107070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Victor, Thanks for the new version. Except this editor change (twice local), everything is fine: Section 1. Introduction OLD: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. NEW: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local operator. I'm sending this document to IETF LC. Regards, Benoit > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. > > Title : CGN Deployment with BGP/MPLS IP VPNs > Authors : Victor Kuarsingh > John Cianfarani > Filename : draft-ietf-opsawg-lsn-deployment-04.txt > Pages : 20 > Date : 2013-12-23 > > Abstract: > This document specifies a framework to integrate a Network Address > Translation layer into an operator's network to function as a Carrier > Grade NAT (also known as CGN or Large Scale NAT). The CGN > infrastructure will often form a NAT444 environment as the subscriber > home network will likely also maintain a subscriber side NAT > function. Exhaustion of the IPv4 address pool is a major driver > compelling some operators to implement CGN. Although operators may > wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near > term needs may not be satisfied with an IPv6 deployment alone. This > document provides a practical integration model which allows the CGN > platform to be integrated into the network, meeting the connectivity > needs of the subscriber while being mindful of not disrupting > existing services and meeting the technical challenges that CGN > brings. The model included in this document utilizes BGP/MPLS IP > VPNs which allow for virtual routing separation helping ease the CGNs > impact on the network. This document does not intend to defend the > merits of CGN. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-lsn-deployment-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > . > --------------010603060509070107070808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Victor, Thanks for the new version. Except this editor change (twice local), everything is fine: Section 1. Introduction OLD: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local local operator. NEW: To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 addresses caches run out on the local operator. I'm sending this document to IETF LC. Regards, Benoit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : CGN Deployment with BGP/MPLS IP VPNs Authors : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-04.txt Pages : 20 Date : 2013-12-23 Abstract: This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-lsn-deployment-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg . --------------010603060509070107070808-- From iesg-secretary@ietf.org Mon Dec 23 08:21:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE36A1AE11C; Mon, 23 Dec 2013 08:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyRXTaAmq9_V; Mon, 23 Dec 2013 08:21:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A291ADF7D; Mon, 23 Dec 2013 08:21:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131223162114.32344.30187.idtracker@ietfa.amsl.com> Date: Mon, 23 Dec 2013 08:21:14 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (CGN Deployment with BGP/MPLS IP VPNs) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 16:21:17 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'CGN Deployment with BGP/MPLS IP VPNs' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-01-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ballot/ No IPR declarations have been submitted directly on this I-D. From bclaise@cisco.com Mon Dec 23 11:57:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23A01AE29B for ; Mon, 23 Dec 2013 11:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMuEZI67hnNX for ; Mon, 23 Dec 2013 11:57:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6721AE289 for ; Mon, 23 Dec 2013 11:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1387828675; x=1389038275; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=PXdnKdMhwfJk7cDE06wlbOLJs9Me1KqVrkz4jY3aIE4=; b=QJ7Ri9Fffsl9u7uEbB3Gq+QoImhmii9tP1xEFDL7IIPqRvSQ5eaCUrgx ZJGriYZF00hECoZUfmA4RPK78SKi7M5og7y6FDHwS4VHIwPW6AOxW7He+ K7MgXNNkOHdmQr0TBugt5kEDF2D1sY1+5QBrDROV5IiInl5FHvaWkAGGN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAH2VuFKQ/khR/2dsb2JhbABZgws4g1SFXbB+gR4WdIIlAQEBBCNVDQQPDQMBAgoWCwICCQMCAQIBOwIIBg0GAgEBiAANsVCaNBeOQxACAT4YBoJogUgEmBeBMIUVi0+DLjs X-IronPort-AV: E=Sophos;i="4.95,538,1384300800"; d="scan'208,217";a="2691394" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 23 Dec 2013 19:57:54 +0000 Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBNJvrSo012897 for ; Mon, 23 Dec 2013 19:57:53 GMT Message-ID: <52B895C2.7020307@cisco.com> Date: Mon, 23 Dec 2013 20:57:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20131223173049.30447.27152.idtracker@ietfa.amsl.com> In-Reply-To: <20131223173049.30447.27152.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131223173049.30447.27152.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030907020404010504000007" Subject: [OPSAWG] Fwd: updated by Amy Vezza X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 19:58:00 -0000 This is a multi-part message in MIME format. --------------030907020404010504000007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Congrats the Ed, the document shepherd Dan Romascanu, the OPSAWG chairs, and the everybody involved. Regards, Benoit -------- Original Message -------- Subject: updated by Amy Vezza Date: Mon, 23 Dec 2013 09:30:49 -0800 From: DraftTracker Mail System To: Benoit Claise Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ IESG has approved the document and state has been changed to Approved-announcement sent --------------030907020404010504000007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Congrats the Ed, the document shepherd Dan Romascanu, the OPSAWG chairs, and the everybody involved. Regards, Benoit -------- Original Message -------- Subject: <draft-ietf-opsawg-rfc5066bis-07.txt> updated by Amy Vezza Date: Mon, 23 Dec 2013 09:30:49 -0800 From: DraftTracker Mail System <iesg-secretary@ietf.org> To: Benoit Claise <bclaise@cisco.com> Please DO NOT reply to this email. I-D: <draft-ietf-opsawg-rfc5066bis-07.txt> ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ IESG has approved the document and state has been changed to Approved-announcement sent --------------030907020404010504000007-- From EdwardB@actelis.com Mon Dec 23 13:29:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156171AE2CD for ; Mon, 23 Dec 2013 13:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHzW3OX0lbQ8 for ; Mon, 23 Dec 2013 13:29:05 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 81CB11AE27D for ; Mon, 23 Dec 2013 13:29:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,539,1384293600"; d="scan'208,217";a="2405307" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 23 Dec 2013 23:29:00 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Mon, 23 Dec 2013 23:29:00 +0200 From: Edward Beili To: Benoit Claise , "Dan Romascanu (dromasca@avaya.com)" , "opsawg@ietf.org" Date: Mon, 23 Dec 2013 23:28:59 +0200 Thread-Topic: [OPSAWG] Fwd: updated by Amy Vezza Thread-Index: Ac8AGUn60ZgWjQH9QQmfvjZCoX/vYwACuodw Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D3A4E0DC@il-mail07.actelis.net> References: <20131223173049.30447.27152.idtracker@ietfa.amsl.com> <52B895C2.7020307@cisco.com> In-Reply-To: <52B895C2.7020307@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4E0DCilmail07act_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Fwd: updated by Amy Vezza X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 21:29:08 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4E0DCilmail07act_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVub2l0LCBEYW4sIHRoZSBPUFNBV0cgY2hhaXJzIGFuZCBldmVyeWJvZHkgaW52b2x2ZWQuDQpU aGFuayB5b3UgdmVyeSBtdWNoLg0KDQpSZWdhcmRzLA0KLUUuDQoNCkZyb206IE9QU0FXRyBbbWFp bHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVub2l0IENsYWlzZQ0K U2VudDogTW9uZGF5LCBEZWNlbWJlciAyMywgMjAxMyAyMTo1OA0KVG86IG9wc2F3Z0BpZXRmLm9y Zw0KU3ViamVjdDogW09QU0FXR10gRndkOiA8ZHJhZnQtaWV0Zi1vcHNhd2ctcmZjNTA2NmJpcy0w Ny50eHQ+IHVwZGF0ZWQgYnkgQW15IFZlenphDQoNCkNvbmdyYXRzIHRoZSBFZCwgdGhlIGRvY3Vt ZW50IHNoZXBoZXJkIERhbiBSb21hc2NhbnUsIHRoZSBPUFNBV0cgY2hhaXJzLCBhbmQgdGhlIGV2 ZXJ5Ym9keSBpbnZvbHZlZC4NCg0KUmVnYXJkcywgQmVub2l0DQoNCg0KLS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0KPGRyYWZ0LWlldGYtb3BzYXdnLXJmYzUw NjZiaXMtMDcudHh0PiB1cGRhdGVkIGJ5IEFteSBWZXp6YQ0KDQpEYXRlOg0KDQpNb24sIDIzIERl YyAyMDEzIDA5OjMwOjQ5IC0wODAwDQoNCkZyb206DQoNCkRyYWZ0VHJhY2tlciBNYWlsIFN5c3Rl bSA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+PG1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9y Zz4NCg0KVG86DQoNCkJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPjxtYWlsdG86YmNs YWlzZUBjaXNjby5jb20+DQoNCg0KDQpQbGVhc2UgRE8gTk9UIHJlcGx5IHRvIHRoaXMgZW1haWwu DQoNCg0KDQpJLUQ6IDxkcmFmdC1pZXRmLW9wc2F3Zy1yZmM1MDY2YmlzLTA3LnR4dD4NCg0KSUQg VHJhY2tlciBVUkw6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v cHNhd2ctcmZjNTA2NmJpcy8NCg0KDQoNCklFU0cgaGFzIGFwcHJvdmVkIHRoZSBkb2N1bWVudCBh bmQgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0byBBcHByb3ZlZC1hbm5vdW5jZW1lbnQgc2VudA0K DQoNCg0KDQoNCg0K --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4E0DCilmail07act_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QmVub2l0LCBEYW4sIHRoZSBPUFNBV0cgY2hhaXJz IGFuZCBldmVyeWJvZHkgaW52b2x2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSB2ZXJ5IG11Y2guPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xv cjp3aW5kb3d0ZXh0Jz4gT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZiA8L2I+QmVub2l0IENsYWlzZTxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBE ZWNlbWJlciAyMywgMjAxMyAyMTo1ODxicj48Yj5Ubzo8L2I+IG9wc2F3Z0BpZXRmLm9yZzxicj48 Yj5TdWJqZWN0OjwvYj4gW09QU0FXR10gRndkOiAmbHQ7ZHJhZnQtaWV0Zi1vcHNhd2ctcmZjNTA2 NmJpcy0wNy50eHQmZ3Q7IHVwZGF0ZWQgYnkgQW15IFZlenphPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+Q29uZ3JhdHMgdGhlIEVkLCB0aGUgZG9jdW1lbnQgc2hlcGhlcmQgRGFu IFJvbWFzY2FudSwgdGhlIE9QU0FXRyBjaGFpcnMsIGFuZCB0aGUgZXZlcnlib2R5IGludm9sdmVk Ljxicj48YnI+UmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9v OnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0w IGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4 dC1hbGlnbjpyaWdodCc+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0 eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPiZsdDtkcmFm dC1pZXRmLW9wc2F3Zy1yZmM1MDY2YmlzLTA3LnR4dCZndDsgdXBkYXRlZCBieSBBbXkgVmV6emE8 bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0n cGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBz dHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+ PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPk1v biwgMjMgRGVjIDIwMTMgMDk6MzA6NDkgLTA4MDA8bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PHRy Pjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxw IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+ RnJvbTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPkRyYWZ0VHJhY2tlciBNYWlsIFN5c3RlbSA8YSBo cmVmPSJtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmciPiZsdDtpZXNnLXNlY3JldGFyeUBp ZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZh bGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlRvOiA8bzpwPjwvbzpw PjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWw+QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5j b20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+PC90ZD48L3Ry PjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3A+PHByZT5QbGVhc2UgRE8gTk9UIHJlcGx5IHRvIHRoaXMgZW1h aWwuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5JLUQ6 ICZsdDtkcmFmdC1pZXRmLW9wc2F3Zy1yZmM1MDY2YmlzLTA3LnR4dCZndDs8bzpwPjwvbzpwPjwv cHJlPjxwcmU+SUQgVHJhY2tlciBVUkw6IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctcmZjNTA2NmJpcy8iPmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctcmZjNTA2NmJpcy88L2E+PG86cD48L286 cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5JRVNHIGhhcyBhcHByb3Zl ZCB0aGUgZG9jdW1lbnQgYW5kIHN0YXRlIGhhcyBiZWVuIGNoYW5nZWQgdG8gQXBwcm92ZWQtYW5u b3VuY2VtZW50IHNlbnQ8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_4087887712E5C648B9F72BB9D912FD4602F6D3A4E0DCilmail07act_-- From tom.taylor.stds@gmail.com Wed Dec 25 06:05:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C51ADF58; Wed, 25 Dec 2013 06:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxEkWnrs293I; Wed, 25 Dec 2013 06:05:31 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E8E121AE28B; Wed, 25 Dec 2013 06:05:30 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl1so25736656igb.5 for ; Wed, 25 Dec 2013 06:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=x2fx6fsnsWI87RjHO080vUeAmspHjEjFOff0DQrXg6w=; b=kuffMGkT24tgYMocSSaS8koP4YkNXiFK2xBQLGt2hOt9OPClXI9aFiiv5cG11yotnY Jy74rOE9KUClWij9ku6b8uIVF4IqlZoS+2U12b9BfvqDNKWeIsnIcNZX5ghEYuMorMyV 93QIGeWEhgX/3TTHHTnm+hZkz6HR3NudSn8ZaLK/owJdFZ4F38QCY8DnTWVXMBFXdXF0 0B+rw4NZHasxQRC7tQYhDxZeErWOc43sRf4a92UNF6RQOWktnqfj8pUBvNbd4eaI+TEI woUt8Z4hWtROqHcY4hIEfbBHhvpGex6bpOsv81e9vZcDE4djcLLXn1Lkbc9u0HCKjcgg LYPw== X-Received: by 10.42.171.69 with SMTP id i5mr164693icz.82.1387980326880; Wed, 25 Dec 2013 06:05:26 -0800 (PST) Received: from [192.168.1.67] ([64.56.250.4]) by mx.google.com with ESMTPSA id l7sm33177774igx.2.2013.12.25.06.05.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Dec 2013 06:05:26 -0800 (PST) Message-ID: <52BAE626.8070604@gmail.com> Date: Wed, 25 Dec 2013 09:05:26 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <52B5E367.2090901@gmail.com> In-Reply-To: <52B5E367.2090901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Cancel: Re: Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 14:05:33 -0000 Further analysis shows it was a foolish idea to try to save a few bytes per log at the expense of other complications. Sorry for the noise. Tom Taylor On 21/12/2013 1:52 PM, Tom Taylor wrote: > I know there is minimal chance of a response at this time of year, but > it would be nice to get on with this work. > > Up to now, the SYSLOG-based NAT logging document has identified > individual subscriber sites using identifiers the nature of which is > indicated in the text below. In addition, it has used realm identifiers. > We are now proposing to rationalize the situation by having the realm > absorb all of the other information. In the case of DS-Lite, however, > this has an operational impact: administrative action is required to > assign a realm identifier to every individual subscriber site served by > a DS_Lite tunnel. > > Is this reasonable, or should realms apply at a more aggregate level? > > The text that follows would replace existing text in the SYSLOG NAT > document talking about realms and subscriber site identifiers. The MIB > and IPFIX logging documents would also align themselves with this text. > > Tom Taylor > > --------------------- > > A realm identifies an IP numbering space. A NAT session always maps > between an interior and an exterior realm. In simple NAT configurations, > it may be possible to identify a default interior realm and/or a default > exterior realm for all sessions. > > Address pools are associated with specific exterior realms. > > It is necessary to define multiple realms when multiple IP numbering > spaces exist. A NAT may distinguish realms in its mapping tables in > different ways, depending on implementation and deployment. Examples > follow shortly. For external presentation, however, logging will use the > realm number. The NAT MIB [reference] provides a mapping between realm > number and an administratively-provided realm name, and may provide > further information relating that to other information corresponding > more closely to the representation by the NAT in its internal tables. > > A NAT recognizes the incoming realm by three basic means: > - at the physical level, by incoming interface; > - at layer 2, by incoming VLAN, VLAN stack, or VPN; > - at layer 3: > -- by PE-based VPN based on incoming destination address and > possibly other packet header information and forwarded > using VPNs based either on BGP/MPLS or Virtual Routers, or > -- by incoming tunnel, typical of various transition technologies. > [RFC 4026] is useful to sort out the various VPN concepts. > > The rest of this description deals with specific cases of layer 3 > tunnels associated with transition technologies. The administrator has > to be aware of these descriptions for the purpose of assigning realm > names to the entities involved, while the NAT designer needs to > understand how to implement both NAT operation in the cases described > and the mapping between the identifiers concerned and the realm identifier. > > DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It > features an encapsulating/decapsulating service combined with a very > large scale NAT44 in the provider network (the Address Family > Transitional Router, AFTR). Every outbound IPv4 packet has a source > address within the reserved 192.0.0.0/29 range. As a result, Section 6.6 > of [RFC 6333] has the following advice on NAT operation for DS-Lite: > > "6.6. Extended Binding Table > > The NAT binding table of the AFTR element is extended to include the > source IPv6 address of the incoming packets. This IPv6 address is > used to disambiguate between the overlapping IPv4 address space of > the service provider customers." > > In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 > address of the encapsulating tunnel from the customer device. > > Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC > 6674]. It is based primarily on the aggregation of traffic from a > particular access gateway through a single softwire to the AFTR. Within > that tunnel, a context identifier identifies the flow of traffic from a > particular customer device. The IPv4 source address in outbound packets > thus becomes irrelevant for routing, whether or not it is unique. > > In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from > the combination of softwire identifier and context identifier. Section 6 > of [RFC 6674] describes the combinations of identifiers that might be > deployed, depending on the operator circumstances. Sections 3 and 4 of > [RFC 6674] go into the details of NAT operation for Gateway-Initiated > DS-Lite. From internet-drafts@ietf.org Thu Dec 26 09:58:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72721AE274; Thu, 26 Dec 2013 09:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL675OWXd1Ps; Thu, 26 Dec 2013 09:58:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6091AE262; Thu, 26 Dec 2013 09:58:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131226175800.27239.66831.idtracker@ietfa.amsl.com> Date: Thu, 26 Dec 2013 09:58:00 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-06.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 17:58:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Mechanisms for Optimal LAG/ECMP Component Link Ut= ilization in Networks Authors : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Sanjay Khanna Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-06.txt Pages : 23 Date : 2013-12-26 Abstract: Demands on networking infrastructure are growing exponentially due to bandwidth hungry applications such as rich media applications and inter-data center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal cost multi-paths as techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancin= g/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-large-flow-load-balanc= ing-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ramk@Brocade.com Thu Dec 26 11:17:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB21AE02F for ; Thu, 26 Dec 2013 11:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWDYzG_5dvLh for ; Thu, 26 Dec 2013 11:17:12 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2EB1AE03A for ; Thu, 26 Dec 2013 11:17:12 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id rBQJFdjN005458; Thu, 26 Dec 2013 11:17:00 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1h0f9d8sx1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Dec 2013 11:17:00 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Dec 2013 11:17:00 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 26 Dec 2013 11:16:51 -0800 From: ramki Krishnan To: Benoit Claise , "draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org" Date: Thu, 26 Dec 2013 11:16:49 -0800 Thread-Topic: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments Thread-Index: Ac73UAZHNl+Feq3FTT+w+t18UIAcoQLHtCrg Message-ID: References: <52A9D813.3060701@cisco.com> In-Reply-To: <52A9D813.3060701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2C0010DDFF6HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-26_06:2013-12-24,2013-12-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312260124 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version needed to address the IETF LC comments X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 19:17:15 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2C0010DDFF6HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, The last call comments and your comments are addressed in the latest versio= n of the draft. https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancin= g/ Thanks, Ramki From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, December 12, 2013 5:37 AM To: draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org Cc: opsawg@ietf.org Subject: [OPSAWG] draft-ietf-opsawg-large-flow-load-balancing: new version = needed to address the IETF LC comments Dear draft-ietf-opsawg-large-flow-load-balancing authors, I started to AD review of draft-ietf-opsawg-large-flow-load-balancing (Sorr= y for the delay btw). Then I reviewed the WG LC feedback (email from Melinda, "[OPSAWG] WG last c= all for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Netw= orks", on August 24th), and I realized that I have the same feedback as Dan= Romascanu in http://www.ietf.org/mail-archive/web/opsawg/current/msg02891.= html Then I reviewed all the WGLC feedback, and it appears that this document wa= s sent on my plate, while the most up to date draft version 5 still doesn't= address the WGLC feedback. For example: http://www.ietf.org/mail-archive/web/opsawg/current/msg02897.h= tml "It refers to all of them, i.e. LAG, ECMP, and even the (hierarchical) comb= ination. We can try and provide some clarification around that. We will a= dd 802.1AX as a reference for LAG." Please post a revised version that addresses the WGLC comments. While you are at it (and since I reviewed 1/3 of the document), here is par= t of my feedback. I'll restart my AD review with the next version Regards, Benoit =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - You use the term flow is a lot. Your definition is in line with the Flow = definition in RFC 7011 (IPFIX). Why not reuse it? Even your specific flow definition could re use the same "Flow" definition = from RFC 7011 Large Flow(s): long-lived large Flow(s) Small Flow(s): long-lived small Flow(s) and short-lived small/large Flow= (s) - How many flow categories do you want to stress? 1. Introduction: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows (which include long- lived small flows, short-lived small/large flows) 1.2. Terminology Large flow(s): long-lived large flow(s) Small flow(s): long-lived small flow(s) and short-lived small/large flow(s) 2. Flow Categorization In general, based on the size and duration, a flow can be categorized into any one of the following four types, as shown in Figure 1: (a) Short-Lived Large Flow (SLLF), (b) Short-Lived Small Flow (SLSF), (c) Long-Lived Large Flow (LLLF), and (d) Long-Lived Small Flow (LLSF). Please be consistent. This is slightly confusing. This only makes sense with the sentence at the end of section 2. In this document, we categorize Long-lived large flow(s) as "Large" flow(s), and all of the others -- Long-lived small flow(s) and short- lived small/large flow(s) as "Small" flow(s). Proposal (to make it clear earlier in document): OLD: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows (which include long- lived small flows, short-lived small/large flows) NEW: Network traffic can be predominantly categorized into two traffic types: long-lived large flows and other flows. These other flow, which include long-lived small flows and short-lived small/large flows, are considered as small flows in this document. EDITORIAL - Please expand LAG/ECMP in the abstract. While ECMP is known, LAG is not. - (load/mix and comma) OLD: If the traffic load constitutes flows such that the result of the hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component link, if, the individual flow rates are much smaller as compared to the link capacity, NEW: If the traffic mix constitutes flows such that the result of the hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component link, if the individual flow rates are much smaller as compared to the link capacity, - EDITORIAL OLD: Where: ->-> small flows =3D=3D=3D> large flow NEW: Where: -> small flow =3D=3D=3D> large flow Alternatively, make it clear in the figure that "-> -> ->" means 3 small fl= ows, by having each flow on a new line. In the same figure, what does "--/---/-" mean? - To demonstrate the limitations of local optimization, consider a two- level fat-tree topology with three leaf nodes (L1, L2, L3) and two spine nodes (S1, S2) and assume all of the links are 10 Gbps. Let L1 have two flows of 4 Gbps each towards L3, and let L2 have one flow of 7 Gbps also towards L3. If L1 balances the load optimally between S1 and S2, and L2 sends the flow via S1, then the downlink from S1 to L3 would get congested resulting in packet discards. On the other hand, if L1 had sent both its flows towards S1 and L2 had sent its flow towards S2, there would have been no congestion at either S1 or S2. A figure would be appreciated. - as a courtesy for the RFC editors, please order the references - idnits complains about the date. - RFC 5101 -> RFC 7011 --_000_C7634EB63EFD984A978DFB46EA5174F2C0010DDFF6HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = Dear Benoit, The last call comments = and your comments are addressed in the latest version of the draft. https:/= /datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ Thanks, Ramki = = From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Beh= alf Of Benoit Claise Sent: Thursday, December 12, 2013 5:37 A= M To: draft-ietf-opsawg-large-flow-load-balancing@tools.ietf.org<= br>Cc: opsawg@ietf.org Subject: [OPSAWG] draft-ietf-opsawg= -large-flow-load-balancing: new version needed to address the IETF LC comme= nts = Dear draft-ietf-opsawg-large-flow-load-balancing a= uthors, I started to AD review of draft-ietf-opsawg-large-flow-load-= balancing (Sorry for the delay btw). Then I reviewed the WG LC feedback = (email from Melinda, "[OPSAWG] WG last call for "Mechanisms for O= ptimal LAG/ECMP Component Link Utilization in Networks", on August 24t= h), and I realized that I have the same feedback as Dan Romascanu in htt= p://www.ietf.org/mail-archive/web/opsawg/current/msg02891.html T= hen I reviewed all the WGLC feedback, and it appears that this document was= sent on my plate, while the most up to date draft version 5 still doesn't = address the WGLC feedback. For example: http://www.ietf.org/mail-arch= ive/web/opsawg/current/msg02897.html "It refers to all of them, i.e. LAG, ECMP, and even the (hierarchical= ) combination. We can try and provide some clarification around that.= We will add 802.1AX as a reference for LAG." Please post a revised vers= ion that addresses the WGLC comments. While you are at it (and since= I reviewed 1/3 of the document), here is part of my feedback. I'll rest= art my AD review with the next version Regards, Benoit =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - You use the te= rm flow is a lot. Your definition is in line with the Flow definition in RF= C 7011 (IPFIX). Why not reuse it? Even your specific flow definition could re use the same "Flow"= definition from RFC 7011 = Large Flow(s): long-lived large Flow(s) <= o:p> Small Flow(s): long-lived small Flo= w(s) and short-lived small/large Flow(s) - How many flow categories do you want to stress?= 1. Introduction: Network traff= ic can be predominantly categorized into two traf= fic type= s: long-lived large flows and other flows (which include long- &nb= sp; lived small flows, short-lived small/large flows) 1.2. Ter= minology Large = flow(s): long-lived large flow(s) = Small flow(s): long-lived small flow(s) an= d short-lived small/large &nbs= p; = flow(s) 2. Flow Categorization In= general, based on the size and duration, a flow can be categorized into any one of the following four = types, as shown in Figure 1: (a) Short-Lived Large Flow (SLLF), (b) Short-Lived Small Flow = (SLSF), = (c) Long-Lived Large Flow (LLLF), and (d) Long-Lived Small Flow (LLSF).= Please be consistent. This is = slightly confusing. This only makes sense with the sen= tence at the end of section 2. In this do= cument, we categorize Long-lived large flow(s) as "Large" flow(s), and all of the others -- Long-lived sma= ll flow(s) and short- lived small/large f= low(s) as "Small" flow(s). = Proposal (to make it clear earlier in document):OLD: Network traffic can be predomi= nantly categorized into two traffic types= : long-lived large flows and other flows (which include long- lived small flows, short-lived small/large flows) = NEW: Network traffic can be predominantly= categorized into two traffic types: long= -lived large flows and other flows. These other flow= , wh= ich include long-lived small flows and short-lived small/large flows,<= /o:p> are considered as small flows in this document= . EDITORIAL - Please expand LAG/ECMP in the abs= tract. While ECMP is known, LAG is not. - (load/mix and comma)<= pre>OLD: If the traffic load const= itutes flows such that the result of the = hash function across these flows is fairly uniform so that a similar number of flows is mapped to each component lin= k, if, the individual flow rates a= re much smaller as compared to the link capacity, NEW:= If the traffic mix constitutes fl= ows such that the result of the hash func= tion across these flows is fairly uniform so that a similar number of flows is mapped to each component link, if the= individual flow rates are much smaller a= s compared to the link capacity, - EDITORIAL OLD: Where: ->-> small flows &nbs= p; =3D=3D=3D> large flow<= pre> NEW: Where: ->&nbs= p; small flow &nbs= p; =3D=3D=3D> large flow Alternatively, make it clear in the figure that "-> -> -= >" means 3 small flows, by having each flow on a new line. In the same figure, what does &quo= t;--/---/-" mean? - To demonstrate the limitations of local op= timization, consider a two- level fat-tre= e topology with three leaf nodes (L1, L2, L3) and two = spine nodes (S1, S2) and assume all of the links are 10 Gbps.&= nbsp; Let L1 have two flows of 4 Gbps eac= h towards L3, and let L2 have one flow of = 7 Gbps also towards L3. If L1 balances the load optimally between S1= and S2, and L2 sends the flow via S1, th= en the downlink from S1 to L3 would get c= ongested resulting in packet discards. On the other hand,<= /pre> if L1 had sent both its flows towards S1 and L2 had = sent its flow towards S2, there would hav= e been no congestion at either S1 or S2. A figure would be appreciated. &nb= sp; - as a courtesy for the RFC editors, please order the r= eferences - idnits complai= ns about the date. - RFC 5= 101 -> RFC 7011 = --_000_C7634EB63EFD984A978DFB46EA5174F2C0010DDFF6HQ1EXCH01corp_--

Subject:	<draft-ietf-opsawg-rfc5066bis-07.txt> updated by Amy Vezza
Date:	Mon, 23 Dec 2013 09:30:49 -0800
From:	DraftTracker Mail System <iesg-secretary@ietf.org>
To:	Benoit Claise <bclaise@cisco.com>