<= /div> --_000_6ea48f1e591b4e32986eb0e755ae80beBLUPR05MB433namprd05pro_-- From nobody Sun Mar 30 12:41:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6022A1A08DA for ; Sun, 30 Mar 2014 12:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.383 X-Spam-Level: X-Spam-Status: No, score=-98.383 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no 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 p9E9ZcsbDY0V for ; Sun, 30 Mar 2014 12:41:27 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 493781A08D6 for ; Sun, 30 Mar 2014 12:41:27 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2UJfMAp029532; Sun, 30 Mar 2014 20:41:22 +0100 Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2UJfKnW029518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Mar 2014 20:41:21 +0100 From: "Adrian Farrel" To: "'Lizhong Jin'" , References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> In-Reply-To: <53345952.a70e440a.2a29.4f84@mx.google.com> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy Date: Sun, 30 Mar 2014 20:41:20 +0100 Message-ID: <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKieMH6bvwQq0oDr/K5WljRkwwysgG2FEXSmUX6OZA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20600.002 X-TM-AS-Result: No--34.071-10.0-31-10 X-imss-scan-details: No--34.071-10.0-31-10 X-TMASE-MatchedRID: A5gI4x1FTANDZFBd1jLr/vHkpkyUphL9cqe/MA7DLQ4M74Nf6tTB9k61 9syQGOLuxKfcydp3f/eaqc65bpqmHmob6A84c/fI/O70vD0Lt8CBHKTJ+sfXGTCmUYns3FLTBGM rBxMZ3dl3eZS0w1USylh82ZaRfk83lEx3ASJaTY1/TWpwlAOFXmWuy5Lm0L4/GNAPebYwJ/uyVb 9d3WTXxz45sOlVgH7G4l59+dj7mAFveCKWtaLcaGZUc2jtcaSdcfU+0yIKuYW0rcU5V/oSe7TTK vbqPUhkEBooN3jW6Av6uiZyo4QnOgVnfa7xoeys9Jn/ZrGuc8Hj5lyuq8IOQWecrqZc3vabTo+d 5kYVw/HUxyYwfjKBedxkXtWpVMfZj64zP5bTFPlwUSK4/EeOxb7VXHusOfivqPm/sjj9KBgHam+ XwtBHJd+mUZy4LP52MFGjWhwUm9sX8+K+77XxXVz+axQLnAVB2D/7bUIJlF1PtLhlThdPEHjhnZ sAD4ZcpN7G8f7epcfkkSE4ev0cuYHDqMX5R2gd9Ib/6w+1lWRaCvPATPKcuU+u8oS4XkKMd/FEI aZIs9+ZuWTyJWxWVqIftEiPb1TuCNmyKN5cwZbXIwmz2YEJxc5Wq23zjsBa/w7gypBC/U+5wFiK VeyETNBoNQ7YmgClsI2++dG5lmwKS5E11pdKlJ3iEJrvFJmh853YiZBxTIQtxWNuz6R5rKRjMtw 20pZotEVswsXx/BsT6MVz8IOEn6ZUkC8x8kLgLNe+DcIJHlSd3F/g7OlulSBzIZ6+1+0no8WMkQ Wv6iWhMIDkR/KfwI2j49Ftap9EkGUtrowrXLg= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/lilH8qJyMl-y7R19V7oIictIcXA Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 19:41:29 -0000 Hi Lizhong, > Sorry for the late reply. Please see my reply inline below. > Please co-authors help to correct if I am wrong. [snip] > > I can't see how this is a BCP. I realise that RFC 2026 section 5 is = not > > really clearly written, but this is a technical spec that describes = how > > to build a particular function in the network. Standards Track would = be > > just fine (even though there are no bits and bytes defined) because = you > > are defining procedures (using 2119 language) that an implementation > > has to perform to make this function work (i.e., interoperate). > > [Lizhong] thank you for pointing out this. We will change to Standards = Track. Good. I hope the WG is paying attention! > > Section 1 > > > > Please give a little more information about what the "solution" is. = You > > don't need to go into full detail, but you do need to give some > > overview. Things I'd like to see covered... > > - motivation is to provide service protection mechanisms in the = event > > of edge node failure > > - basic mechanism is to provide edge node redundancy > > - solution is dependent on the use of ICCP (with reference) to > > coordinate between redundant edge nodes > > - no changes to any protocol message formats are needed for this > > solution and no new protocol options are defined > > - this solution is a description of how existing protocol building > > blocks may be deployed to achieve the desired function, but also > > defines implementation behavior necessary for the function to = work. > [Lizhong] accepted, and I try to rephrase as below: > In many existing Virtual Private LAN Service (VPLS) deployments based = on > [RFC4762], inter-domain connectivity has been deployed without node > redundancy, or with node redundancy in a single domain. This document = is to > provide a service protection mechanism for inter-domain VPLS based on > [RFC4762]. The protection mechanism will provide edge node redundancy = and > link redundancy in both domains. The domain in this document refers = to > autonomous system (AS), or other administrative domains. > The solution relies on the use of ICCP [ietf-pwe3-iccp] to coordinate = between > redundant edge nodes, and use of Pseudowire (PW) Preferential = Forwarding > Status Bit [RFC 6870] to negotiate the PW status. There is no change = to any > protocol message formats and no new protocol options introduced. This = solution > is a description of reusing existing protocol building blocks to = achieve the desired > function, but also defines implementation behavior necessary for the = function to > work. Works for me. [snip] > > Figure 2 might usefully be redrawn to show how PW3 and PW4 attach to > > the PEs. > [Lizhong] do you mean the PW is broken to the PE in the figure? Will = fix that. > Thanks. Yeah. PW3 should connect to PE3 etc. > > Section 5 says > > > > For the inter-domain four-PW scenario, > > it is required for PEs to ensure that the same mode is supported = on > > the two ICCP peers in the same redundancy group (RG). > > > > But you don't say how this is achieved. > [Lizhong] will add: One method to ensure mode consistency is by manual > operation. Other methods are also possible and is out of the scope of = this > document. I'm OK with that, but it is a bit thin. Operators are famous for not = configuring the same thing at two ends of a link. > > Section 5.2 > > > > Before > > deploying this inter-domain VPLS, the operators MUST negotiate to > > configure same PW high/low priority at two PW end-points. > > > > How do they do this? > [Lizhong] we check this with the operator. When they do inter-AS = connection, > there will be some kind of contract to ensure the interconnection. The = PW > priority could be one part of the contract/negotiation. This is more = of the > operation method. Now I think we should not use RFC2119 word "MUST" = here. > "should" would be a better word here. Yup, "should" is better, and maybe add "The inter-domain VPLS = relationship normally involves a contractual process between operators, = and the configuration of PW roles forms part of this process." > > Section 5.3 > > > > In this use case, there are generally three options > > > > So, sometimes two options and sometimes four options? :-) > > Delete "generally", but also make clear what the three options are. > [Lizhong] it would be clear to say: In this use case, there are two = options to > provide protection: 1:1 and 3:1 protection. OK [snip] > > Section 6 > > > > There seem to be some independent actions needed (operator = negotiation, > > setting of mode). Are these security vulnerabilities? > > > > ICCP is being run on the Internet and not in a chassis. Does that = make > > a difference to the security model? > [Lizhong] yes, more consideration is required. I try to change: > Besides of the security properties of [I-D.ietf-pwe3-iccp] and = [RFC4762], this draft > will have additional security consideration. > When deploying the inter-domain redundancy mechanism described in this > document, some manual operation/negotiation is required to be done = correctly > and securely. E.g., each node within one RG should be configured with = same > redundancy mode; the two operators should negotiate to configure same = PW > priority at two nodes. If the configuration consistency is broken, the = inter-domain > redundancy mechanism may not work properly. > Since ICCP is now deployed between two PEs or ASBRs, the LDP session = could be > secured with TCP Authentication Option [RFC5925]. This provides = integrity and > authentication for the ICCP messages. The LDP MD5 authentication key = option, as > described in section 2.9 of [RFC5036] MAY also be used. That is good except that MD5 is pretty much regarded as useless as a = security tool these days. How about adding to the end of your text: "The attention of implementers and deployers is drawn to [RFC6941] and = [RFC6952] with special attention to the recommendation to use TCP-AO = [RFC5925] for enhanced security of LDP sessions." Cheers, Adrian From nobody Sun Mar 30 20:58:09 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2CA1A0960 for ; Sun, 30 Mar 2014 20:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 MpGRWcf1ZIYE for ; Sun, 30 Mar 2014 20:58:04 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B0FEA1A094C for ; Sun, 30 Mar 2014 20:58:04 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so7408571pde.15 for ; Sun, 30 Mar 2014 20:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=WhDEthzXG+mzpr+uVg+p5KrVaL33QNahXmcfbFVHyBs=; b=uSW7yjzGKR3QOkZyWqCygPT/Me8FyhxG6FZfgg0+rmw7vWkgMD7DlDuW8NA0m0Vi40 4A4Z6uHKfJU4TixS2wxoYZ99Rrd8aOjkYGApRxbMDhIKU6AtQ6vD1/6kBHKzYuEOpmdq VgjCTYchIigbip3nSR4u0eycZW4OvCRrfu8J58FsqdD4iw7t6Ubw/PNeTc60whO2s76Y 6D5iLyQigBAIuibZfhARNHvJ29MgADv206eK5bee/jbzcIUil/P7e1V0IT84/FwhkzsU ZRVGg2wquNmye83VXTOC47JBeR9fvQRmcvui0ho2fRkcVKZdK9DzdHe2xt7aiIx9zuhS n1Pw== X-Received: by 10.66.26.81 with SMTP id j17mr22425801pag.87.1396238281714; Sun, 30 Mar 2014 20:58:01 -0700 (PDT) Received: from [10.65.17.169] (mobile-198-228-222-036.mycingular.net. [198.228.222.36]) by mx.google.com with ESMTPSA id vb7sm40311928pbc.13.2014.03.30.20.58.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Mar 2014 20:58:00 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F01BE61B-DFB4-4B30-BD7B-B37749454BDC Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Date: Sun, 30 Mar 2014 20:57:59 -0700 To: "Xialiang (Frank)" Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ut5ZOEk8WzaOJwqzB0YOsgJEaJI Cc: "l2vpn@ietf.org" , "sajassi@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 03:58:06 -0000 --Apple-Mail-F01BE61B-DFB4-4B30-BD7B-B37749454BDC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Frank, Got the email. Sorry for the delay. One if us will get back to you, soon Cheers Sam Sent from my iPhone > On Mar 26, 2014, at 8:47 PM, "Xialiang (Frank)" wrote: >=20 > Hi draft authors, > I have posted my comments about this draft 10 days ago, and don=E2=80=99t g= et your feedback until now. > So, I send this email again to notify you and hope to get your clarificati= on. > Thanks! > =20 > B.R. > Frank > =20 > From: Xialiang (Frank)=20 > Sent: Tuesday, March 18, 2014 3:07 PM > To: 'ssalam@cisco.com'; 'sajassi@cisco.com'; 'aldrin.ietf@gmail.com'; 'jdr= ake@juniper.net' > Cc: l2vpn@ietf.org > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi authors, > I have reviewed this important draft, and have some comments as below: > 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity p= oint of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; > 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? > 3. In section 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? > 4. In section 3.2.1, I do not quite understand the describing reason for t= he inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive som= e unnecessary packets? Why not use unicast packets for Loss Measurement? > =20 > Hoping for your feedback~~ > =20 > B.R. > Frank --Apple-Mail-F01BE61B-DFB4-4B30-BD7B-B37749454BDC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Frank,

Got the email. Sorry f= or the delay. One if us will get back to you, soon

Cheers

S= am
Sent from my iPhone

On Mar 26, 2014, at 8:47 PM, "Xialia= ng (Frank)" <frank.xialiang@= huawei.com> wrote:

=

Hi draft= authors,

I have p= osted my comments about this draft 10 days ago, and don=E2=80=99t get your f= eedback until now.

So, I se= nd this email again to notify you and hope to get your clarification.

Thanks!<= o:p>

&nb= sp;

B.R.

Frank

&nb= sp;

From: Xialiang (Frank)=
Sent: Tuesday, March 18, 2014 3:07 PM
To: 'ssalam@cisco.com'; 'sajassi@cisco.com'; 'aldrin.ietf@gmail.com'; 'jdrake@juniper.net'
Cc: l2vpn@ietf.org
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":<= /o:p>

Hi authors,
I have reviewed this important d= raft, and have some comments as below:

1. By comparing with RFC6136 (L2= VPN OAM req and frm), from the integrity point of view, I think there are so= me part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalabil= ity, Transport/Application Independence;

2. In section 3.1.1.1, what is t= he definition of per user flow? Why is it different to support it between E-= VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the s= ection of "a representative path" mean using test flow to detect the node fa= ilure? if yes, how to do? Is it a necessary requirement of proactive fault d= etection?

4. In section 3.2.1, I do not qu= ite understand the describing reason for the inaccuracy of Loss Measurement.= Do you mean that test packets of Loss Measurement are all BUM packets? Can y= ou clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packets for Loss Measurement?=

Hoping for your feedback~~<= /o:p>

B.R.

Frank

= --Apple-Mail-F01BE61B-DFB4-4B30-BD7B-B37749454BDC-- From nobody Mon Mar 31 02:06:53 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922E81A098E for ; Mon, 31 Mar 2014 02:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 FmFi0F8YL1NE for ; Mon, 31 Mar 2014 02:06:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1051A098D for ; Mon, 31 Mar 2014 02:06:50 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id AA37D180150F; Mon, 31 Mar 2014 11:06:46 +0200 (CEST) Message-ID: <53393028.3040602@pi.nu> Date: Mon, 31 Mar 2014 11:06:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Lizhong Jin' , draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org Subject: Re: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> In-Reply-To: <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vVjXHMp6BIjVkF1MdAFVJbk8jK4 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:06:51 -0000 Adrian, On 2014-03-30 21:41, Adrian Farrel wrote: >> >[Lizhong] thank you for pointing out this. We will change to Standards Track. > Good. I hope the WG is paying attention! As part of the working group I find that what you say above it not entirely clear. I can think of two things: 1. It will have an effect on the Shepherd Write-up, I guess that Giles can take care of that. 2. I also think that changing a draft from BCP to PS would need to confirmed by the working group. I support this change but I guess a short wglc would be in place. /Loa > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Mar 31 05:19:29 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B68B1A07C2 for ; Mon, 31 Mar 2014 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.783 X-Spam-Level: X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no 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 t22ySKQnEYAH for ; Mon, 31 Mar 2014 05:19:25 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id DBC701A07B0 for ; Mon, 31 Mar 2014 05:19:24 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VCJJ83024476; Mon, 31 Mar 2014 13:19:19 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VCJGhl024414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 13:19:18 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , "'Lizhong Jin'" , References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> <53393028.3040602@pi.nu> In-Reply-To: <53393028.3040602@pi.nu> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy Date: Mon, 31 Mar 2014 13:19:18 +0100 Message-ID: <00d101cf4cdb$71b99410$552cbc30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKieMH6bvwQq0oDr/K5WljRkwwysgG2FEXSAieGbsoB3Axjp5km9s9Q Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20600.007 X-TM-AS-Result: No--14.467-10.0-31-10 X-imss-scan-details: No--14.467-10.0-31-10 X-TMASE-MatchedRID: eP8acdNseTlDZFBd1jLr/vHkpkyUphL9Za7LkubQvj8Y0A95tjAn+/dO IHrYOwAQpXW4iKpJiG0cMKF+qCRP0lmCvWO6jvPwMIiU395I8H00AKed0u9fB0UNHQAoZf5cmCs m0zDyYj7RFPQDdklzg3p6Bw0EVM2R088R7Ofw5yfpnOP6QxEGtn0tCKdnhB58O5QxsrU10s/6C0 ePs7A07Y6HM5rqDwqtRkErup0rUN7hjV6OJz3xcDWT7IkqByCo6fq43GLsQMu2f8Xmimxl/A== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/VE-O4dbcuxaGUe-AG2fpm60S2Js Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:19:27 -0000 Hi Loa, > >> >[Lizhong] thank you for pointing out this. We will change to = Standards Track. > > > > Good. I hope the WG is paying attention! >=20 > As part of the working group I find that what you say above it not > entirely clear. >=20 > I can think of two things: >=20 > 1. It will have an effect on the Shepherd Write-up, I guess that Giles > can take care of that. >=20 > 2. I also think that changing a draft from BCP to PS would need to > confirmed by the working group. I support this change but I guess = a > short wglc would be in place. Good, you see, you were paying attention. Shepherd write-up is something between me and the shepherd, we can take = care of that. Change of status from BCP to Standards track is something the WG has to = be happy with. The WG chairs are the people who assess whether the WG is = happy. They can use any tool they like. Cheers, Adrian From nobody Mon Mar 31 07:47:48 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353BC1A0A24 for ; Mon, 31 Mar 2014 07:47:46 -0700 (PDT) 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 FeMhbduSGpHn for ; Mon, 31 Mar 2014 07:47:38 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B577F1A6F0A for ; Mon, 31 Mar 2014 07:47:38 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so8287283pbb.31 for ; Mon, 31 Mar 2014 07:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=SZ+U0T1cnXYF8+I7hU32qkUu1FX4RXAlha546dp44i4=; b=gM56gSp4qqpRfoG2RHrasUmOjiGH8Rgdy3StXsMMCeTFooa4vaHLJfCfSlT+QOwH58 QbSTyTM5lc1247/0wCpFRDCGc/od0mbfRJv+7kftta6YIK7ggnwfi0jTFZqR8Mn3GGWD MQ7yOAnbxGo7d18tpIU5ok3bLALjkWsOxsWx8Gqwz0t/lKCdHJzGY2wpkp5GD7XXCpyI fGZXy4HsTifdEZcMZjokrIN0YhH7E9F7NmScE/pqDxQg5s6F1xRn7x6xX+7Rko9ODWw8 qK6bdfyJGoYXbx66nkN8cLkxahJM05IJ0xgZATJkp0v2SW4F8E8DptRQHhSTVnE1ha6W JNeA== X-Received: by 10.66.189.226 with SMTP id gl2mr25619939pac.65.1396277255609; Mon, 31 Mar 2014 07:47:35 -0700 (PDT) Received: from LIZHONGJ ([140.206.240.36]) by mx.google.com with ESMTPSA id fk4sm41665592pab.23.2014.03.31.07.47.30 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Mar 2014 07:47:34 -0700 (PDT) From: "Lizhong Jin" To: , References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> In-Reply-To: <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy Date: Mon, 31 Mar 2014 22:47:24 +0800 Message-ID: <011d01cf4cf0$2702f140$7508d3c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKieMH6bvwQq0oDr/K5WljRkwwysgG2FEXSAieGbsqZNfiKYA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/tCiFpxznJEmp9kJttcQgRzftcYM Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:47:46 -0000 Hi Adrian, Thank you for the quick reply. See my reply inline below. We will post a new version accordingly soon to reflect these comments. Regards Lizhong > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 2014=E5=B9=B43=E6=9C=8831=E6=97=A5 3:41 > To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain- > redundancy.all@tools.ietf.org > Cc: l2vpn@ietf.org > Subject: RE: AD review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy >=20 > Hi Lizhong, >=20 > > Sorry for the late reply. Please see my reply inline below. > > Please co-authors help to correct if I am wrong. >=20 > [snip] >=20 > > > I can't see how this is a BCP. I realise that RFC 2026 section 5 = is > > > not really clearly written, but this is a technical spec that > > > describes how to build a particular function in the network. > > > Standards Track would be just fine (even though there are no bits > > > and bytes defined) because you are defining procedures (using 2119 > > > language) that an implementation has to perform to make this = function > work (i.e., interoperate). > > > > [Lizhong] thank you for pointing out this. We will change to = Standards Track. >=20 > Good. I hope the WG is paying attention! [Lizhong] OK, we will post a new version accordingly. >=20 > > > Section 1 > > > > > > Please give a little more information about what the "solution" = is. > > > You don't need to go into full detail, but you do need to give = some > > > overview. Things I'd like to see covered... > > > - motivation is to provide service protection mechanisms in the = event > > > of edge node failure > > > - basic mechanism is to provide edge node redundancy > > > - solution is dependent on the use of ICCP (with reference) to > > > coordinate between redundant edge nodes > > > - no changes to any protocol message formats are needed for this > > > solution and no new protocol options are defined > > > - this solution is a description of how existing protocol building > > > blocks may be deployed to achieve the desired function, but also > > > defines implementation behavior necessary for the function to = work. > > [Lizhong] accepted, and I try to rephrase as below: > > In many existing Virtual Private LAN Service (VPLS) deployments = based > > on [RFC4762], inter-domain connectivity has been deployed without = node > > redundancy, or with node redundancy in a single domain. This = document > > is to provide a service protection mechanism for inter-domain VPLS > > based on [RFC4762]. The protection mechanism will provide edge node > > redundancy and link redundancy in both domains. The domain in this > > document refers to autonomous system (AS), or other administrative > domains. > > The solution relies on the use of ICCP [ietf-pwe3-iccp] to = coordinate > > between redundant edge nodes, and use of Pseudowire (PW) = Preferential > > Forwarding Status Bit [RFC 6870] to negotiate the PW status. There = is > > no change to any protocol message formats and no new protocol = options > > introduced. This solution is a description of reusing existing > > protocol building blocks to achieve the desired function, but also > > defines implementation behavior necessary for the function to work. >=20 > Works for me. [Lizhong] Thanks. >=20 > [snip] >=20 > > > Figure 2 might usefully be redrawn to show how PW3 and PW4 attach = to > > > the PEs. > > [Lizhong] do you mean the PW is broken to the PE in the figure? Will = fix that. > > Thanks. >=20 > Yeah. PW3 should connect to PE3 etc. [Lizhong] Thanks. >=20 > > > Section 5 says > > > > > > For the inter-domain four-PW scenario, > > > it is required for PEs to ensure that the same mode is = supported on > > > the two ICCP peers in the same redundancy group (RG). > > > > > > But you don't say how this is achieved. > > [Lizhong] will add: One method to ensure mode consistency is by = manual > > operation. Other methods are also possible and is out of the scope = of > > this document. >=20 > I'm OK with that, but it is a bit thin. Operators are famous for not = configuring > the same thing at two ends of a link. [Lizhong] I understand. At current stage, let's keep it simple. >=20 > > > Section 5.2 > > > > > > Before > > > deploying this inter-domain VPLS, the operators MUST negotiate = to > > > configure same PW high/low priority at two PW end-points. > > > > > > How do they do this? > > [Lizhong] we check this with the operator. When they do inter-AS > > connection, there will be some kind of contract to ensure the > > interconnection. The PW priority could be one part of the > > contract/negotiation. This is more of the operation method. Now I = think we > should not use RFC2119 word "MUST" here. > > "should" would be a better word here. >=20 > Yup, "should" is better, and maybe add "The inter-domain VPLS = relationship > normally involves a contractual process between operators, and the > configuration of PW roles forms part of this process." [Lizhong] OK, thanks. >=20 > > > Section 5.3 > > > > > > In this use case, there are generally three options > > > > > > So, sometimes two options and sometimes four options? :-) Delete > > > "generally", but also make clear what the three options are. > > [Lizhong] it would be clear to say: In this use case, there are two > > options to provide protection: 1:1 and 3:1 protection. >=20 > OK >=20 > [snip] >=20 > > > Section 6 > > > > > > There seem to be some independent actions needed (operator > > > negotiation, setting of mode). Are these security vulnerabilities? > > > > > > ICCP is being run on the Internet and not in a chassis. Does that > > > make a difference to the security model? > > [Lizhong] yes, more consideration is required. I try to change: > > Besides of the security properties of [I-D.ietf-pwe3-iccp] and > > [RFC4762], this draft will have additional security consideration. > > When deploying the inter-domain redundancy mechanism described in = this > > document, some manual operation/negotiation is required to be done > > correctly and securely. E.g., each node within one RG should be > > configured with same redundancy mode; the two operators should > > negotiate to configure same PW priority at two nodes. If the > > configuration consistency is broken, the inter-domain redundancy > mechanism may not work properly. > > Since ICCP is now deployed between two PEs or ASBRs, the LDP session > > could be secured with TCP Authentication Option [RFC5925]. This > > provides integrity and authentication for the ICCP messages. The LDP > > MD5 authentication key option, as described in section 2.9 of = [RFC5036] > MAY also be used. >=20 > That is good except that MD5 is pretty much regarded as useless as a = security > tool these days. >=20 > How about adding to the end of your text: >=20 > "The attention of implementers and deployers is drawn to [RFC6941] = and > [RFC6952] with special attention to the recommendation to use TCP-AO > [RFC5925] for enhanced security of LDP sessions." [Lizhong] OK, thanks. >=20 > Cheers, > Adrian >=20 From nobody Mon Mar 31 12:46:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFE01A6F9B; Mon, 31 Mar 2014 12:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uOAbWjlDQcvK; Mon, 31 Mar 2014 12:46:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7677A1A6FCC; Mon, 31 Mar 2014 12:46:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2744E7FC399; Mon, 31 Mar 2014 12:46:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7152 on Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) From: rfc-editor@rfc-editor.org Message-Id: <20140331194639.2744E7FC399@rfc-editor.org> Date: Mon, 31 Mar 2014 12:46:39 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/S7_zBqFqVTwOogdWiIGRZ_p7ljg Cc: l2vpn@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:46:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7152 Title: Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) Author: R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul Status: Informational Stream: IETF Date: March 2014 Mailbox: raymond.key@ieee.org, simon.delord@gmail.com, frederic.jounay@orange.ch, huanglu@chinamobile.com, zhliu@gsta.com, manuel.paul@telekom.de Pages: 12 Characters: 22795 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-etree-reqt-05.txt URL: http://www.rfc-editor.org/rfc/rfc7152.txt This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN"). It is intended that potential solutions will use these requirements as guidelines. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Mar 31 14:03:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB91A6FFE for ; Mon, 31 Mar 2014 14:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 IJo0bESSttYe for ; Mon, 31 Mar 2014 14:03:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4C1A6FB2 for ; Mon, 31 Mar 2014 14:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12512; q=dns/txt; s=iport; t=1396299806; x=1397509406; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=jGzK8pxlskjYZ9oiGBkTrNlPs19ZYT/7zSyEUr+1YR0=; b=KoWKxnY2InaYYFpX6pmlbHYuSAInH+uApOvk1Da8sGcZAIaJkEOKfcAe JuvUgDzYuJUI2LDf367Ym42HKWepWV9ItO7YfvjM4KXAO53pDohjGbYJl V14U0KtPcTWqdGhMibCixdECjhkmEdwCBkuay17ycEtLqZ2le76HbKMg/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAJrXOVOtJV2a/2dsb2JhbABZgkIjITtXwy2BIhZ0giUBAgQtTBIBCBEDAQIoKBEUCQgBAQQBDQUbh0oDEQHJVA2GaReMY4ILEQeEOASWYYFtjGuFSoMwgis X-IronPort-AV: E=Sophos; i="4.97,767,1389744000"; d="scan'208,217"; a="31787837" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 31 Mar 2014 21:03:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VL3P05015939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 21:03:25 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 16:03:24 -0500 From: "Samer Salam (ssalam)" To: "Xialiang (Frank)" , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net" Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoA Date: Mon, 31 Mar 2014 21:03:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.113.19] Content-Type: multipart/alternative; boundary="_000_CF5F217727AC8ssalamciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/hXDn6-7Cev8uHY3GmBHOv9QvKXE Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:03:32 -0000 --_000_CF5F217727AC8ssalamciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort=85). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft =96 after al= l, this is the requirements and framework draft, it does not cover the solu= tion details for implementation. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_CF5F217727AC8ssalamciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0173DC5D5BB9C94288C652E02A3F4522@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Frank,

Thanks for your comments. Please find responses below:

1. In this draft, we cite RFC 6136 as reference, and hence we do not r= epeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-= band OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN h= as automatic discovery built-in via the Inclusive Multicast Route and the Ethernet A-D Route. Hence, no fu= rther mechanisms are required.

2. Per user flow means a traffic stream that maps to actual user data,= with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/D= est Port=85). The reason why this is different between Network & = Service OAM is because the Service OAM mechanisms may or may not be able to support per-flow OAM, depending on the ser= vice layer and its associated OAM capabilities. For instance, in the case w= here Ethernet CFM (IEEE 802.1ag) is the service OAM, it is not possible to = perform per-flow continuity check, as the destination MAC address is set by the protocol to a multicast address.=

3. Yes, a representative path maps to a test flow. This is a simple fu= nction, and is actually a degenerate case of the per user-flow OAM, because= test fields are specified for the N-Tuple. That's why it is mandatory. As = to the details of the mechanism, that is left to the solution draft =96 after all, this is the requirements= and framework draft, it does not cover the solution details for implementa= tion.

4. Test packets can be either unicast or multicast. The problem we are= describing here is that relying on normal packet counters in unreliable gi= ven that E-VPN offers many-to-many connectivity. For e.g., consider 3 endpo= ints A, B and C. Let's say we are interested in measuring the loss between A and C. A sends a packet to C, b= ut it gets dropped. Now B also sends to C and that packet is delivered. If = we were to examine the packet counter on C, we will find that the counter s= hows 1 packet received. But that doesn't mean that we have 100% packet delivery rate between A and C. The p= acket actually came from another source and hence the packet counter on C i= s ambiguous. Unless the implementation keeps packet counters per-flow (whic= h will be expensive and impractical), it is not reliable to use packet counters to measure loss in a technology = that supports multipoint-to-multipoint connectivity.

Regards,

Samer

From: "Xialiang (Frank)" = <frank.xialiang@huawei.com<= /a>>
Date: Tuesday, 18 March, 2014 12:07= AM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)&= quot; <sajassi@cisco.com>, &= quot;aldrin.ietf@gmail.com&quo= t; <aldrin.ietf@gmail.com>= , "jdrake@juniper.net" = <jdrake@juniper.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: comments on "draft-sa= lam-l2vpn-evpn-oam-req-frmwk-02":

Hi authors,

I have reviewed this important = draft, and have some comments as below:

1. By comparing with RFC6136 (L= 2VPN OAM req and frm), from the integrity point of view, I think there are = some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scala= bility, Transport/Application Independence;

2. In section 3.1.1.1, what is = the definition of per user flow? Why is it different to support it between = E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the= section of "a representative path" mean using test flow to detec= t the node failure? if yes, how to do? Is it a necessary requirement of pro= active fault detection?

4. In section 3.2.1, I do not q= uite understand the describing reason for the inaccuracy of Loss Measuremen= t. Do you mean that test packets of Loss Measurement are all BUM packets? C= an you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packets for Loss Measurement= ?

Hoping for your feedback~~=

B.R.

Frank

--_000_CF5F217727AC8ssalamciscocom_-- From nobody Mon Mar 31 19:01:00 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD51A6F6A for ; Mon, 31 Mar 2014 19:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BLqCnN-L8eKn for ; Mon, 31 Mar 2014 19:00:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1971A090A for ; Mon, 31 Mar 2014 19:00:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCP63051; Tue, 01 Apr 2014 02:00:51 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 03:00:10 +0100 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 03:00:50 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.203]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Tue, 1 Apr 2014 10:00:45 +0800 From: "Xialiang (Frank)" To: "Samer Salam (ssalam)" , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net" Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woA= Date: Tue, 1 Apr 2014 02:00:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1B66SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SHbJ2nTvwxCyj7-VhBo8x-JlGsE Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 02:00:59 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1B66SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@= juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort...). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think "a statistical means of approximating packet loss ra= te" you proposed in draft is not the suitable solution for this problem. Ac= tually, this is more an implementation issue, i.e., we can set the same val= ue of flow characteristics for a test flow to ensure all test flow packets = send/receive between 2 nodes exactly. Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1B66SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Same= r,

Please = see inline:

&n= bsp;

From: Samer Salam = (ssalam) [mailto:ssalam@cisco.com]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; = jdrake@juniper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

Hi Frank,=

&nbs= p;

Thanks fo= r your comments. Please find responses below:

&nbs= p;

1. In thi= s draft, we cite RFC 6136 as reference, and hence we do not repeat the defi= nition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM = layering etc.). Regarding Discovery, please note that E-VPN has automatic discovery built-in via the Inclusive Multica= st Route and the Ethernet A-D Route. Hence, no further mechanisms are requi= red.

&nbs= p;

2. Per us= er flow means a traffic stream that maps to actual user data, with a specif= ied N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…= ;). The reason why this is different between Network & Service OAM is because the Service OAM mechanisms may or may= not be able to support per-flow OAM, depending on the service layer = and its associated OAM capabilities. For instance, in the case where Ethern= et CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform per-flow continuity check, as the destinatio= n MAC address is set by the protocol to a multicast address.

&nbs= p;

3. Yes, a= representative path maps to a test flow. This is a simple function, and is= actually a degenerate case of the per user-flow OAM, because test fields a= re specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the s= olution draft – after all, this is the requirements and framework dra= ft, it does not cover the solution details for implementation.

[= Frank] : From my personal view, I don’t think the paragraph describin= g the requirement of a representative path is clear enough. For example, wh= y can it be used for node failure detection but not path failure detection?

&nbs= p;

4. Test p= ackets can be either unicast or multicast. The problem we are describing he= re is that relying on normal packet counters in unreliable given that E-VPN= offers many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped.= Now B also sends to C and that packet is delivered. If we were to examine = the packet counter on C, we will find that the counter shows 1 packet received. But that doesn't mean that = we have 100% packet delivery rate between A and C. The packet actually came= from another source and hence the packet counter on C is ambiguous. Unless= the implementation keeps packet counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports = multipoint-to-multipoint connectivity.

[= Frank] : Yes. This clarification is more clear than the current content of = draft~~ Also, I think “a statistical means of approximating packet lo= ss rate” you proposed in draft is not the suitable solution for this problem. Actually, this is more an implementation issue,= i.e., we can set the same value of flow characteristics for a test flow to= ensure all test flow packets send/receive between 2 nodes exactly.<= /i>

&nbs= p;

Regards,<= o:p>

Samer

&nbs= p;

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02&q= uot;:

&nbs= p;

Hi author= s,

I have re= viewed this important draft, and have some comments as below:

1. By com= paring with RFC6136 (L2VPN OAM req and frm), from the integrity point of vi= ew, I think there are some part missing: EVPN MEP and MIP, Discovery, Data = Path Forwarding, Scalability, Transport/Application Independence;

2. In sec= tion 3.1.1.1, what is the definition of per user flow? Why is it different = to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In sec= tion 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necess= ary requirement of proactive fault detection?

4. In sec= tion 3.2.1, I do not quite understand the describing reason for the inaccur= acy of Loss Measurement. Do you mean that test packets of Loss Measurement = are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packe= ts for Loss Measurement?

Hoping fo= r your feedback~~

B.R.=

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1B66SZXEMA502MBSchi_-- From nobody Mon Mar 31 19:11:45 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440671A6F8D for ; Mon, 31 Mar 2014 19:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 6CTU_Ix1-69z for ; Mon, 31 Mar 2014 19:11:38 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A77231A6FC0 for ; Mon, 31 Mar 2014 19:11:38 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so8997635pbc.6 for ; Mon, 31 Mar 2014 19:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GOkKTA5ftRyM3BA84v5nGSYix3omz4GEWuw+z7q6XHg=; b=tu9McpD/v2kP4J+IB2uL/9FzBQkXLJ99f6z6jgHXswVIffONJNTiYvo3MQY6fI/y0+ p5nNJbNg4+LU53Tw8YdfsrkVQf0OajGQdYr/lRQFgBUT5xHP54aPkuVD48wKXxwDJVvA mM0vbg/DdMGdsPgKpQfVnBLsVJGQ1azV5PnEF43Bx1N4ba3nwesx5XMeQpde7qpvF/N7 jqFDuVWNUmhQmXMWINwRW2Gk/Gx/p1PT6DuLFGpxtamZkTRE4HvqDD8TCJ7z05LDxvRN ozqzqyjPzngJlSI3FuXneAma0GCv552qMukAr28Oz8VVKm2AqVFLPL7oEiEvG/zdP3F3 DLiQ== X-Received: by 10.68.231.196 with SMTP id ti4mr28607529pbc.48.1396318295392; Mon, 31 Mar 2014 19:11:35 -0700 (PDT) Received: from [192.168.1.9] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id pi1sm48276760pac.14.2014.03.31.19.11.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 19:11:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8F7913AB-0925-4ACB-8C7B-A297FFB56E6F" Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": From: Sam Aldrin In-Reply-To: Date: Mon, 31 Mar 2014 19:11:31 -0700 Message-Id: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> References: To: "Xialiang (Frank)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ynmL2z9SZz6V7AiDno7q7EHfhMQ Cc: "l2vpn@ietf.org" , "Ali Sajassi $sajassi$" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 02:11:41 -0000 --Apple-Mail=_8F7913AB-0925-4ACB-8C7B-A297FFB56E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Frank, Comments inline. On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) = wrote: > Hi Samer, > Please see inline: > =20 > From: Samer Salam (ssalam) [mailto:ssalam@cisco.com]=20 > Sent: Tuesday, April 01, 2014 5:03 AM > To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; = jdrake@juniper.net > Cc: l2vpn@ietf.org > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi Frank, > =20 > Thanks for your comments. Please find responses below: > =20 > 1. In this draft, we cite RFC 6136 as reference, and hence we do not = repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, = In-band OAM, OAM layering etc.). Regarding Discovery, please note that = E-VPN has automatic discovery built-in via the Inclusive Multicast Route = and the Ethernet A-D Route. Hence, no further mechanisms are required. > =20 > 2. Per user flow means a traffic stream that maps to actual user data, = with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, = Src/Dest Port=85). The reason why this is different between Network & = Service OAM is because the Service OAM mechanisms may or may not be able = to support per-flow OAM, depending on the service layer and its = associated OAM capabilities. For instance, in the case where Ethernet = CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform = per-flow continuity check, as the destination MAC address is set by the = protocol to a multicast address. > =20 > 3. Yes, a representative path maps to a test flow. This is a simple = function, and is actually a degenerate case of the per user-flow OAM, = because test fields are specified for the N-Tuple. That's why it is = mandatory. As to the details of the mechanism, that is left to the = solution draft =96 after all, this is the requirements and framework = draft, it does not cover the solution details for implementation. > [Frank] : =46rom my personal view, I don=92t think the paragraph = describing the requirement of a representative path is clear enough. For = example, why can it be used for node failure detection but not path = failure detection? Whether one uses for node or path failure detection is for the solution = to decide. This is requirements draft. If you think better wording is = required, please do propose, will consider that. > =20 > 4. Test packets can be either unicast or multicast. The problem we are = describing here is that relying on normal packet counters in unreliable = given that E-VPN offers many-to-many connectivity. For e.g., consider 3 = endpoints A, B and C. Let's say we are interested in measuring the loss = between A and C. A sends a packet to C, but it gets dropped. Now B also = sends to C and that packet is delivered. If we were to examine the = packet counter on C, we will find that the counter shows 1 packet = received. But that doesn't mean that we have 100% packet delivery rate = between A and C. The packet actually came from another source and hence = the packet counter on C is ambiguous. Unless the implementation keeps = packet counters per-flow (which will be expensive and impractical), it = is not reliable to use packet counters to measure loss in a technology = that supports multipoint-to-multipoint connectivity. > [Frank] : Yes. This clarification is more clear than the current = content of draft~~ Also, I think =93a statistical means of approximating = packet loss rate=94 you proposed in draft is not the suitable solution = for this problem. Actually, this is more an implementation issue, i.e., = we can set the same value of flow characteristics for a test flow to = ensure all test flow packets send/receive between 2 nodes exactly. Again, this is requirement draft only. What you are eluding to is how = one should perform, which clearly falls in solution category. As Samer = clarified earlier, using actual data packet counters doesn=92t meet the = requirements, hence =91synthetic' measurement is required.=20 -sam > =20 > Regards, > Samer > =20 > From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM > To: Samer Salam , "Ali Sajassi (sajassi)" = , "aldrin.ietf@gmail.com" , = "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi authors, > I have reviewed this important draft, and have some comments as below: > 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the = integrity point of view, I think there are some part missing: EVPN MEP = and MIP, Discovery, Data Path Forwarding, Scalability, = Transport/Application Independence; > 2. In section 3.1.1.1, what is the definition of per user flow? Why is = it different to support it between E-VPN Network OAM and E-VPN Service = OAM? > 3. In section 3.1.1.1, does the section of "a representative path" = mean using test flow to detect the node failure? if yes, how to do? Is = it a necessary requirement of proactive fault detection? > 4. In section 3.2.1, I do not quite understand the describing reason = for the inaccuracy of Loss Measurement. Do you mean that test packets of = Loss Measurement are all BUM packets? Can you clarify why peer MEPs will = receive some unnecessary packets? Why not use unicast packets for Loss = Measurement? > =20 > Hoping for your feedback~~ > =20 > B.R. > Frank --Apple-Mail=_8F7913AB-0925-4ACB-8C7B-A297FFB56E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Frank,

Comments = inline.
On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) = <frank.xialiang@huawei.com>= ; wrote:

Hi = Samer,
Please see inline:

From: Samer Salam (ssalam) [mailto:ssalam@cisco.com]
Sent: Tuesday, April 01, 2014 = 5:03 AM
To: Xialiang (Frank); Ali = Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on = "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi = Frank,

Thanks for your comments. = Please find responses below:

1. In this draft, we cite = RFC 6136 as reference, and hence we do not repeat the definition of = common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM = layering etc.). Regarding Discovery, please note that E-VPN has = automatic discovery built-in via the Inclusive Multicast Route and the = Ethernet A-D Route. Hence, no further mechanisms are = required.

2. Per user flow means a = traffic stream that maps to actual user data, with a specified N-tuple = characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port=85). The = reason why this is different between Network & Service OAM is = because the Service OAM mechanisms may or may not be able to support = per-flow OAM, depending on the service layer and its associated = OAM capabilities. For instance, in the case where Ethernet CFM (IEEE = 802.1ag) is the service OAM, it is not possible to perform per-flow = continuity check, as the destination MAC address is set by the protocol = to a multicast address.

3. Yes, a representative = path maps to a test flow. This is a simple function, and is actually a = degenerate case of the per user-flow OAM, because test fields are = specified for the N-Tuple. That's why it is mandatory. As to the details = of the mechanism, that is left to the solution draft =96 after all, this = is the requirements and framework draft, it does not cover the solution = details for implementation.
[Frank] : =46rom my personal view, I don=92t think the paragraph = describing the requirement of a representative path is clear enough. For = example, why can it be used for node failure detection but not path = failure = detection?
Whethe= r one uses for node or path failure detection is for the solution to = decide. This is requirements draft. If you think better wording is = required, please do propose, will consider that.

4. Test packets can be = either unicast or multicast. The problem we are describing here is that = relying on normal packet counters in unreliable given that E-VPN offers = many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. = Let's say we are interested in measuring the loss between A and C. A = sends a packet to C, but it gets dropped. Now B also sends to C and that = packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't = mean that we have 100% packet delivery rate between A and C. The packet = actually came from another source and hence the packet counter on C is = ambiguous. Unless the implementation keeps packet counters per-flow = (which will be expensive and impractical), it is not reliable to use = packet counters to measure loss in a technology that supports = multipoint-to-multipoint connectivity.
[Frank] : Yes. This clarification is more clear than the current = content of draft~~ Also, I think =93a statistical means of approximating = packet loss rate=94 you proposed in draft is not the suitable solution = for this problem. Actually, this is more an implementation issue, i.e., = we can set the same value of flow characteristics for a test flow to = ensure all test flow packets send/receive between 2 nodes = exactly.
Again, = this is requirement draft only. What you are eluding to is how one = should perform, which clearly falls in solution category. As Samer = clarified earlier, using actual data packet counters doesn=92t meet the = requirements, hence =91synthetic' measurement is = required.

-sam

Regards,
Samer

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 = 12:07 AM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi = (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" <jdrake@juniper.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comments on = "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi = authors,
I have reviewed this = important draft, and have some comments as = below:
1. By comparing with = RFC6136 (L2VPN OAM req and frm), from the integrity point of view, I = think there are some part missing: EVPN MEP and MIP, Discovery, Data = Path Forwarding, Scalability, Transport/Application = Independence;
2. In section 3.1.1.1, what = is the definition of per user flow? Why is it different to support it = between E-VPN Network OAM and E-VPN Service = OAM?
3. In section 3.1.1.1, does = the section of "a representative path" mean using test flow to detect = the node failure? if yes, how to do? Is it a necessary requirement of = proactive fault detection?
4. In section = 3.2.1, I do not quite understand the describing reason for the = inaccuracy of Loss Measurement. Do you mean that test packets of Loss = Measurement are all BUM packets? Can you clarify why peer MEPs will = receive some unnecessary packets? Why not use unicast packets for Loss = Measurement?

Hoping for your = feedback~~

B.R.
Frank

IETF = repository.

Name: = draft-jain-nvo3-overlay-oam
Revision: 01
Title: Generic Overlay OAM = and Datapath Failure Detection
Document date: 2014-02-12
Group: Individual = Submission
Pages: 44
URL: http://www.ietf.org/interne= t-drafts/draft-jain-nvo3-overlay-oam-01.txt
Status: https://datatracker.ietf.or= g/doc/draft-jain-nvo3-overlay-oam/
Htmlized: http://tools.ietf.org/html/= draft-jain-nvo3-overlay-oam-01
Diff: = http://www.ietf.org/rfcdiff= ?url2=3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
This proposal describes a mechanism that can be = used to detect Data
Path Failures of various overlay technologies as = VXLAN, NVGRE,
MPLSoGRE and MPLSoUDP and verifying/sanity of = their Control and Data
Plane for given Overlay Segment. This = document defines the following
for each of the above Overlay = Technologies:

o Encapsulation of OAM Packet, such that it = has same Outer and
Overlay Header as any End-System's data = going over the same
Overlay Segment.

o The mechanism to trace the Underlay that = is exercised by any
Overlay Segment.

o Procedure to verify presence of any given = Tenant VM or End-System
within a given Overlay Segment at Overlay = End-Point.

Even though the present proposal addresses Overlay = OAM for VXLAN,
NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
generic enough to accommodate OAM for any other = Overlay Technology.

A new versi= on of I-D, draft-jain-nvo3-overlay-oam-has been su= ccessfully submitted by Kanwar Singh and posted to the
IETF repository.

Name: dra= ft-jain-nvo3-overlay-oam
Revision: 01
Title: = ; Generic Overlay OAM and Datapath Failure Detection
Document date: 2014-02-12
Group: Ind= ividual Submission
Pages: 44<= /span>
URL: &nbs= p; ht= tp://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt Status: https://datatracker.ietf.org/doc/draft-jain-nvo3-ov= erlay-oam/
Htmlized: http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
Diff: &nbs= p; http://www.ietf.org/rfcdiff?url2= =3Ddraft-jain-nvo3-overlay-oam-01

Abstract:
This proposal describes a mecha= nism that can be used to detect Data
Path Failures of various overla= y technologies as VXLAN, NVGRE,
MPLSoGRE and MPLSoUDP and verif= ying/sanity of their Control and Data
Plane for given Overlay Segment= . This document defines the following
for each of the above Overlay T= echnologies:

o = Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any E= nd-System's data going over the same
Overlay Segment.=

o = The mechanism to trace the Underlay that is exercised by any Overlay Segment.=

o = Procedure to verify presence of any given Tenant VM or End-System
within a given Overlay = Segment at Overlay End-Point.

Ev= en though the present proposal addresses Overlay OAM for VXLAN,
NVGRE, MPLSoGRE and MPLSoUDP, b= ut the procedures described are
generic enough to accommodate O= AM for any other Overlay Technology.