From amirh@orckit.com Mon Feb 15 08:52:34 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE1528C1EC; Mon, 15 Feb 2010 08:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz6D-wktKYMd; Mon, 15 Feb 2010 08:52:33 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 391073A7B67; Mon, 15 Feb 2010 08:52:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAAE5F.789EA830" Subject: Comments to draft-key-l2vpn-vpls-etree-02 Date: Mon, 15 Feb 2010 18:54:00 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813057FDA8C@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to draft-key-l2vpn-vpls-etree-02 Thread-Index: AcquX3iD9xMBzKAXSmuCqAfMGdG10Q== From: "Amir Halperin" To: X-Mailman-Approved-At: Tue, 16 Feb 2010 02:35:37 -0800 Cc: l2vpn@ietf.org, Rafi Ram , pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 16:52:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAAE5F.789EA830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raymond. =20 Regarding http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-5.3, it is possible, for backward compatibility, to configure per PW whether all traffic on that PW is either leaf or root. By setting such property, a PE that is not supporting the extension can participate in the E-tree with the following restrictions: 1. All ACs are leaf or 2. All ACs are root. =20 This suggested addition is not applicable for a PW that interconnects pair of PEs that supports this extension. =20 Regards, =20 Amir Halperin System Architect ORCKIT Corrigent Office: +972-3-694-5379 Fax: +972-3-695-3222 Mobile:+972-54-4323-815 mailto:amirh@orckit.com =20 ------_=_NextPart_001_01CAAE5F.789EA830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raymond.

Regarding http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-5.3= , it is possible, for backward compatibility, to configure per PW whether = all traffic on that PW is either leaf or root. By setting such property, a = PE that is not supporting the extension can participate in the E-tree with the following restrictions:

1. All ACs are leaf or

2. All ACs are root.

This suggested addition is not applicable for a PW = that interconnects pair of PEs that supports this = extension.

Regards,

Amir Halperin
System = Architect

ORCKIT = Corrigent

Office: +972-3-694-5379

Fax: +972-3-695-3222
Mobile:+972-54-4323-815
mailto:amirh@orckit.com

------_=_NextPart_001_01CAAE5F.789EA830-- From raymond.key@ieee.org Thu Feb 25 21:04:26 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B83528C215; Thu, 25 Feb 2010 21:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tBHqSRR67dG; Thu, 25 Feb 2010 21:04:25 -0800 (PST) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by core3.amsl.com (Postfix) with ESMTP id 1FF4228C199; Thu, 25 Feb 2010 21:04:24 -0800 (PST) Received: from localhost.localdomain (webmail01.syd.optusnet.com.au [211.29.132.235]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1Q56ZjA028519; Fri, 26 Feb 2010 16:06:35 +1100 Message-Id: <201002260506.o1Q56ZjA028519@mail10.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) Received: from bcbvo.tcif.telstra.com.au ([203.35.135.136]) by webmail01.syd.optusnet.com.au with http (user=rkey_ieee@optusnet.com.au); Fri, 26 Feb 2010 16:06:35 +1100 From: Raymond Key To: Amir Halperin Date: Fri, 26 Feb 2010 16:06:35 +1100 Subject: Re: Comments to draft-key-l2vpn-vpls-etree-02 Cc: l2vpn@ietf.org, Rafi Ram , pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raymond.key@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 05:04:26 -0000 Hi Amir, Thanks a lot for your comment. This is a very good suggestion and we will consider when prepare the next version. Raymond Key > Amir Halperin wrote: > > Hi Raymond. > > Regarding > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-5.3, it > is possible, for backward compatibility, to configure per PW whether all > traffic on that PW is either leaf or root. By setting such property, a > PE that is not supporting the extension can participate in the E-tree > with the following restrictions: > > 1. All ACs are leaf or > > 2. All ACs are root. > > This suggested addition is not applicable for a PW that interconnects > pair of PEs that supports this extension. > > Regards, > > Amir Halperin > System Architect > > ORCKIT Corrigent > > Office: +972-3-694-5379 > > Fax: +972-3-695-3222 > Mobile:+972-54-4323-815 > mailto:amirh@orckit.com From Alexander.Vainshtein@ecitele.com Sun Feb 28 21:55:03 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A984F3A860A; Sun, 28 Feb 2010 21:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTqFqDtYJSgL; Sun, 28 Feb 2010 21:55:01 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 89D573A63EB; Sun, 28 Feb 2010 21:55:00 -0800 (PST) X-AuditID: 93eaf2e7-b7b6cae0000051e6-a2-4b8b54f256eb Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 14.5D.20966.2F45B8B4; Mon, 1 Mar 2010 07:47:30 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 1 Mar 2010 07:54:59 +0200 From: Alexander Vainshtein To: Maarten Vissers Date: Mon, 1 Mar 2010 07:55:00 +0200 Subject: RE: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"] Thread-Topic: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: PHBs and "ordered aggregates"] Thread-Index: Acq2op0Jlsjlo//JSOW5t/qa+KffRwAT+JaAAHFz+gAAEjOwgA== Message-ID: References: <052C67B4ED558D41BBDEA7CA9FC6DCDC53B701D0E0@atl-srv-exgen.atl.advaoptical.com> <000b01cab8cd$136a71f0$fe06000a@china.huawei.com> In-Reply-To: <000b01cab8cd$136a71f0$fe06000a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "l2vpn@ietf.org" , 'Igor Bryskin' , "mpls-tp@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 05:55:03 -0000 Maarten (and all), I have added the L2VPN WG list since two of your comments deal with VPLS. I disagree with two of your comments dealing with VPLS: VPLS technology is Ethernet VLAN technology IMHO this incorrect: Ethernet/VLAN (as technology) does not use "split horizon", and VPLS does n= ot need any form of STP for loop elimination across a full mesh of PWs. PW label identifies the VPLS/VLAN instance IMHO this is also incorrect/inaccurate: Rx PW label identifies specific VPLS peer within the VPLS instance for MAC = learning purposes. As a consequence, a VSI with N peers requires N different Rx PW labels. Modeling of VPLS (that includes 802.1-compliant bridge modules and VPLS For= warders) is discussed in some detail in=20 http://www.watersprings.org/pub/id/draft-ietf-l2vpn-vpls-bridge-interop-04.= txt My 2c, Sasha -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Maarten Vissers Sent: Monday, March 01, 2010 1:20 AM To: 'Igor Bryskin' Cc: mpls-tp@ietf.org Subject: [mpls-tp] TP: 'transport paths' and 'SP: service paths' [was: RE: = PHBs and "ordered aggregates"] Igor, If I would put MPLS-SP and MPLS-TP in a layer stack figure, I get the following: ---------------------------------------------- | MPLS-SP (RFC5654 transport service layer) | | includes LDP-PWs, BGP-PWs, Service-LSPs | | VPLS, VPNs, etc | ---------------------------------------------- | MPLS-TP (RFC5654 transport path layer) | | includes edge-to-edge-LSPs, .. | ---------------------------------------------- | Transmission Media layer (includes | | section and physical media layers) | ---------------------------------------------- MPLS-SP can then be read as 'MPLS Service Path' layer, which supports 'service paths'. MPLS-TP can then be read as 'MPLS Transport Path' layer, which supports 'transport paths'. Note that the VPLS technology is Ethernet VLAN technology and that the PW label identifies the VPLS/VLAN instance. PW, Service-LSP and VPLS instances (the 'service path signals') are all carried by a 'MPLS transport path' (i.e. edge-to-edge LSP) as illustrated i= n the figure below. |<---- Pseudowire, Service LSP and VPLS/VLAN ---->| | encapsulated packet "service paths" | | | | | | |<---edge-to-edge LSP1--->| edge-to-edge | AC | | "transport path" | |<--LSP2-->| | AC | V V V V V V | | +----+ +-----+ +----+ +----+ | +---+ | |TPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ P /=3D=3D= =3D=3D=3D|SPE1|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|TPE2| | +---+ | |---|......PW1-Seg1.... | | ......X...PW1-Seg2......|---| | |CE | | | | | | | | | | | |CE | |11 |---|......PW2-Seg1.... | | ......X...PW2-Seg2......|---|21 | +---+ | | | | | | | | | | +---+ | |---|.....SLSP1-Seg1... | \ / | ......X..SLSP1-Seg2.....|---| | |CE | | | | | X | | | | | | |CE | |12 |---|.....SLSP2-Seg1... | / \ | ......X..SLSP2-Seg2.....|---|22 | +---+ | | | | | | | | | | +---+ | |---|......VPLS1-Seg1.. | | ......X..VPLS1-Seg2.....|---| | |CE | | | | | | | | | | | |CE | |13 |---|......VPLS2-Seg1.. | | ......X..VPLS2-Seg2.....|---|23 | +---+ | | |=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| | | +---+ +----+ ^ +-----+ +----+ ^ +----+ =20 | | =20 TE LSP TE LSP =20 Figure - MPLS-TP edge-to-edge LSP transporting PW, Service-LSP and VPLS/VLAN 'service paths' (=3D RFC5654 transport service layer transport path) signals Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: vrijdag 26 februari 2010 15:59 To: curtis@occnc.com; neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] PHBs and "ordered aggregates" Curtis, I believe that one of our serious problems is that we keep calling MPLS-TP MPLS transport profile, while in fact this is IMO nothing but MPLS traffic engineered (controlled by GMPLS or NMS) transport layer providing services to various clients and one of them is MPLS service layer (some people call it MPLS-SP) that includes LDP-PWs, BGP-PWs, VPLS, VPNs, etc.). The two layers (MPLS-TP and MPLS-SP) share the same data plane, but from the CP, say, point of view they have quite literally nothing in common. Cheers, Ogor -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Curtis Villamizar Sent: Friday, February 26, 2010 12:14 AM To: neil.2.harrison@bt.com Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] PHBs and "ordered aggregates" In message <2ECAA42C79676B42AEBAC11229CA7D0C05A90D41@E03MVB2-UKBR.domain1.systemhost.n= e t> neil.2.harrison@bt.com writes: > =20 > Hi Curtis....wow, long time no hear. I know what you are saying here=20 > but this is not what a transport network is supposed to be doing. You=20 > cannot apply what you say to any co-cs mode layer network controlled=20 > by GMPLS...just a fact of the physics. > =20 > If we do not provide true transparency in MPLS-TP then that's OK, but=20 > it also means that MPLS-TP should really stop claiming it is a=20 > transport network. In fact, I would argue that the mere fact MS PWs=20 > still appear in MPLS-TP alone is a fairly obvious indication that it=20 > has failed in its transport network aspirations. > =20 > This sort of technical accuracy seems not to matter any longer from=20 > what I am observing....so be it, but there are also practical=20 > implications of not grokking this anyway, I was merely pointing some=20 > of these. Caveat emptor now. > =20 > regards, Neil Neil. MPLS-TP is a "profile". A given provider can in effect enable or disable aspects of the profile if they prefer to do so for business reasons rather than for sake of some notion of transport purity. But lets not argue religion. The specs have a lot of SHOULD so that providers still have choices. Curtis > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com]=20 > > Sent: 25 February 2010 03:53 > > To: Harrison,N,Neil,DKQ7 R > > Cc: david.i.allan@ericsson.com; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] PHBs and "ordered aggregates"=20 > >=20 > >=20 > > Hi Neil. > >=20 > > AF service has more than one PHB per OA. That is on purpose.=20 > > The rule is one PSC per OA, not one PHB. The color marking=20 > > affect only the drop preference. > >=20 > > All other defined diffserv services have one PHB per OA. > >=20 > > If you don't like AF, don't use it. > >=20 > > Re: "the server layer resources must not be overbooked". In=20 > > the event of a fault, a disconnected IP network is worse than=20 > > a mildly congested one, particularly if diffserv is used and=20 > > the only thing slowed down is the BE service. To do that,=20 > > you need to allow overbooking. Hint: > > use MPLS holding-pri with the Russian Dolls model and only=20 > > overbook the priority containing BE. > >=20 > > MPLS doesn't need any changes to allow this. > >=20 > > Curtis > >=20 > >=20 > > In message=20 > > <2ECAA42C79676B42AEBAC11229CA7D0C05A400B4@E03MVB2-UKBR.domain1 > > .systemhost.net> > > neil.2.harrison@bt.com writes: > > > =20 > > > Hi Dave, > > > =20 > > > The deeper (G.800) architectural point you are getting at=20 > > here is one=20 > > > of transparency...which is THE key service that a server layer=20 > > > (transport) network needs to deliver to its clients. What=20 > > this means=20 > > > practically is > > > this: > > > - the server network must be based on single source connection > > > constructs > > > - the server layer resources must not be overbooked=20 > > > - the server network must not try and impart any meaning to client > > > layer symbols and for sure not change them.....in essence no=20 > > > snooping/DPI > > > - a (parent) connection must not re-order its (child) traffic > > > units...and the sting in the tail from this observation is that a=20 > > > connection must only have a single traffic class....QoS=20 > > class if you=20 > > > like, but noting that urgency and importance are orthogonal=20 > > metrics of=20 > > > a message/file/stream client application that is external=20 > > to the TOS=20 > > > layer network, and some lower server layer network must not try and=20 > > > infer dynamic meaning of these metrics from observing=20 > > client traffic=20 > > > unit flows. This point becomes very important in practical network=20 > > > interconnects that occur in a BOS network layer network. > > > =20 > > > We should also expand the problem statement below to take these=20 > > > factors into account: > > > - Net Perf metrics/objectives only relate to the available state. > > > - Net Perf metrics/objectives apply independently to each > > > direction of a bidirectional connection=20 > > > - For all bidirectional connections if one direction enters the > > > unavailable state then the Net Perf SLA process must be suspended in > > > *both* directions. > > > =20 > > > The above is important in order to prevent Net Perf SLAs being=20 > > > distorted by outage events.....though I would caution, from=20 > > practical=20 > > > measurements I did in transport networks when=20 > > mathematically modelling=20 > > > error/outage events, that a 10 second entry criteria for the=20 > > > unavailable state is too long and short-break events (ie=20 > > outage events=20 > > > that terminate before 10s is reached) will also distort Net=20 > > Perf objectives. > > > =20 > > > The above creates some rather serious challenges wrt to=20 > > synchronising=20 > > > the start/stopping of Net Perf processes if one wants a=20 > > good degree of=20 > > > accuracy.....which is not trivial even at trail termination points,=20 > > > let alone in any nested TCM sublayers, noting that on failures we=20 > > > often need to re-route connections and so only the trail=20 > > termination=20 > > > locations will remain invariant across such restoration event. > > > =20 > > > BTW - It should also be rather obvious from the above that=20 > > if one has=20 > > > multiple QoS (sic) classes in a connection then the handling of=20 > > > entry/exit of unavailable events will become practically=20 > > intractable=20 > > > anyway, even at true trail termination points. > > > =20 > > > regards, Neil > > > =20 > > > =20 > > > > -----Original Message----- > > > > From: mpls-tp-bounces@ietf.org > > > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of David Allan I > > > > Sent: 23 February 2010 21:41 > > > > To: mpls-tp@ietf.org > > > > Subject: [mpls-tp] PHBs and "ordered aggregates" > > > >=20 > > > > Hi TPers > > > >=20 > > > > A question relating to the LM transaction. > > > >=20 > > > > Ideally an LM transaction can measure an ordered=20 > > aggregate as the LM=20 > > > > transactions benefit from the ordering guarantees and the counts=20 > > > > therefore reflect packets in flight at the time the LM is issued. > > > >=20 > > > > The problem is having the OA correspond to something=20 > > useful that can=20 > > > > be identified in the LM such that it shares queing=20 > > discipline with=20 > > > > the OA (vs. simply microflow guarantees). A read of 3260 suggests=20 > > > > that a 1:1 correspondence between OA and PHB or PHB class=20 > > does not=20 > > > > necessarily exist but that the deltas in ordering=20 > > guarantees seems=20 > > > > to be at least partially on the basis (my inference) of arbitrary=20 > > > > ECMP next hop selection criteria. > > > >=20 > > > > It strikes me that for TP we need a stake in the ground=20 > > that a PHB=20 > > > > on a transport path is an ordered aggregate, or we post a huge=20 > > > > health warning on LM that "actual mileage may vary".... > > > >=20 > > > > WDYT? > > > > Dave > > > > _______________________________________________ > > > > mpls-tp mailing list > > > > mpls-tp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > >=20 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp