From owner-ccamp@ops.ietf.org Fri Aug 1 02:13:25 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749873A6AFD for ; Fri, 1 Aug 2008 02:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 0zltYRI-2mBj for ; Fri, 1 Aug 2008 02:13:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41BCC3A692C for ; Fri, 1 Aug 2008 02:13:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOqdJ-000K5f-Pr for ccamp-data@psg.com; Fri, 01 Aug 2008 09:09:09 +0000 Received: from [206.16.17.211] (helo=usaga01-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOqdF-000K4u-0D for ccamp@ops.ietf.org; Fri, 01 Aug 2008 09:09:07 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4X002XA032MT@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Aug 2008 02:09:02 -0700 (PDT) Received: from dan ([130.129.65.103]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4X00I5I0303H@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Aug 2008 02:09:02 -0700 (PDT) Date: Fri, 01 Aug 2008 17:09:57 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" , "Ccamp (E-mail)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: multipart/alternative; boundary="Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, Very good question! See my comments below. Thanks, Dan ----- Original Message ----- From: Bardalai, Snigdho To: Ccamp (E-mail) Sent: Friday, August 01, 2008 4:26 AM Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. Could you please let me know if the above is within the current scope? I believe that these are important. Thanks, Snigdho --Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,
 
Very good question! See my comments below.
 
Thanks,
 
Dan
----- Original Message -----
Sent: Friday, August 01, 2008 4:26 AM
Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:

1. IGP usage in the context of traditional distributed solutions for WSON

[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.


2. IGP usage in the context of PCE solutions for WSON

[Dan] It's a potential way for PCE to get the wavelength information.

 
3. Flooding and refresh of static and dynamic link state updates

[Dan] Try to figure out the impact to the performance of IGP.

 
4. Data base sync-up during node restarts

[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.

Could you please let me know if the above is within the current scope? I believe that these are important.

Thanks,
Snigdho





--Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)-- From owner-ccamp@ops.ietf.org Mon Aug 4 01:34:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FCF3A68AF for ; Mon, 4 Aug 2008 01:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 hWyCXwbrTBse for ; Mon, 4 Aug 2008 01:34:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6686F3A68DC for ; Mon, 4 Aug 2008 01:34:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvND-000NhV-Lk for ccamp-data@psg.com; Mon, 04 Aug 2008 08:24:59 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvN9-000Ngo-2h for ccamp@ops.ietf.org; Mon, 04 Aug 2008 08:24:57 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0D48220834; Mon, 4 Aug 2008 10:24:50 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-4c-4896bcd18d1f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD8652081E; Mon, 4 Aug 2008 10:24:49 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 10:24:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: MPLS over OTN Date: Mon, 4 Aug 2008 10:23:54 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1403BEB9C2@esealmw118.eemea.ericsson.se> In-Reply-To: <01be01c8f3b4$10a3eb20$91168182@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS over OTN Thread-Index: AcjztBjHyt6w6stjR36S7lGwsWPkiQCVYblw References: <56D2F550769FAA4CA70D5B2EB8419F1403BC85FF@esealmw118.eemea.ericsson.se> <01be01c8f3b4$10a3eb20$91168182@your029b8cecfe> From: "Howard Green" To: "Adrian Farrel" , Cc: X-OriginalArrivalTime: 04 Aug 2008 08:24:01.0199 (UTC) FILETIME=[72D983F0:01C8F60B] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian Thanks (for the homily as well!) My apologies for some lack of clarity. As you say, GMPLS control of OTN is what it is. The use of a G-PID describing an MPLS payload does, presumably, allow an OTN path to be advertised (with suitable policy constraints) as an MPLS forwarding adjacency. In the MPLS layer above this OTN, it is not so obvious how to carry IP "in band", and therefore the GMPLS mechanics seem to be required. As you say, the control plane could be "OOB but in fiber" (or here, in OTN path) or out of fibre. Thus there would seem to be utility in an optional associated channel mechanism for the control plane. I wonder whether there may be a requirement of the reverse kind (maximum diversity between data plane and control plane) in some circumstances. /Howard > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: 01 August 2008 10:53 > To: Howard Green; ccamp@ops.ietf.org > Cc: mpls-tp@ietf.org > Subject: Re: MPLS over OTN >=20 > Hi Howard, >=20 > [adding MPLS-TP mailing list] >=20 > Accurate representation of our conversation. > That is, in GMPLS we have label type, switching type,=20 > encoding type, and G-PID. > G-PID identifies the payload and re-uses the Ethertype=20 > codepoints. Thus we can carry MPLS. > If GFP is used for framing, it must also identify the payload=20 > and, as you point out, GFP has an MPLS codepoint. >=20 > That the GFP codepoint for MPLS is the same as that for=20 > "T-MPLS" is good for Option 1 (which is where we are) since=20 > there is no practical difference between MPLS and MPLS-TP. >=20 > Now, the operation of MPLS over OTN that you describe is=20 > actually the operation of an OTN. So the issues of control=20 > channels in OTN are exactly as you describe, but have nothing=20 > to do with the payload protocol. This is simply GMPLS control=20 > of OTN. Period. >=20 > GMPLS control of MPLS-TP is a different kettle of ball games.=20 > Here the switching type is PSC: the same switching type as=20 > for MPLS. A feature of GMPLS is that there is *logical*=20 > separation of control plane and data plane.=20 > This means that the control plane can be in-band (MPLS-TE),=20 > out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre. >=20 > MPLS-TP requirements say that it must be possible to operate=20 > the network "in the absence of IP." I have taken this to mean=20 > "in the absence of IP routing and forwarding" (but this is my=20 > opinion and there is no explicit evidence in the requirements=20 > I-D). With this view... > - We can use IP identifiers (addresses) in the data plane and=20 > the control plane > - We can use IP-based control protocols (GMPLS) > - We can use an IP-based control network if available, but we cannot > mandate it > - Control entities that need to communicate must be allowed to be > IP-adjacent so that there is no requirement for=20 > IP-forwarding in the > network >=20 > I believe we can do all of the above, and often do in GMPLS networks. > The crunch questions are: > 1. What is the physical technology for the data links in the=20 > control plane? > 2. How do we identify control plane traffic when it arrives at a node? > 3. How do we exchange control plane messages between nodes that > do not have a common data link in the control plane? >=20 > Answers are: > 1. We don't care :-) > But a possible answer in MPLS-TP is an LSP (e.g. a=20 > reserved label) 2. From the data link (since there is no need=20 > to disambiguate the control > plane traffic from any other traffic on the data link) 3.=20 > This is a more tricky question. However nearly all of the messages > are exchanged only between data-plane-adjacent nodes. This can be > the case in the IGP-TE protocols, and is true for all messages in > RSVP-TE with a couple of exceptions (below). It is also=20 > the case for > LMP. So IP forwarding is not required in the control plane. > The tricky cases are: > - echo response in LSP Ping (we are rebuilding the OAM) > - Notify message in RSVP-TE (we are considering OAM approaches > for the uses of Notify where IP forwarding is not available) > - "Targeted Path messages" used in hierarchical LSPs (and LSP > stitching). In these cases we are effectively building a virtual > data plane adjacency and should build a parallel virtual control > plane link between the end points (e.g. an LSP). >=20 > We should note that the output of the JWT *appears* to be=20 > that "GMPLS meets the requirements of a control plane for MPLS-TP." >=20 > We should also note that management plane operation of=20 > MPLS-TP is a requirement, and we must assume that management=20 > plane messages may need to be exchanged between management=20 > stations and network nodes using some protocol and connectivity. >=20 > >=20 > Adrian > ----- Original Message ----- > From: "Howard Green" > To: > Sent: Thursday, July 31, 2008 5:55 PM > Subject: MPLS over OTN >=20 >=20 > Just to record for the list a chat with Adrian and Lou Berger. I > discover from reading G.7041 Amendment 2 that there is a codepoint > defined to allow unicast MPLS frames to be carried over OTN (ODUx) > channels by way of GFP encoding. Reading RFC 4328, there is=20 > an encoding > type for ODUx, and the switching type is TDM. There is no=20 > specific G-PID > value defined for the MPLS codepoint (which was probably defined > concurrently with the writing of RFC 4328). Adrian and Lou=20 > took the view > that in this situation, the use of the unicast MPLS ethertype (#8847) > would define for signalling this bearer type (as described in=20 > RFC 3471). >=20 > This is relevant partly because G.7041 amendment 2 defines=20 > the codepoint > to be for "MPLS or T-MPLS". I assume that this usage carries over to > MPLS-TP. In this situation,interestingly, there is no=20 > prospect of inband > IP control, and so GMPLS is the only control plane option. > Is this correct? > Regards Howard >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Aug 4 01:48:00 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB473A68DC for ; Mon, 4 Aug 2008 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 vrIEMkFdv+UH for ; Mon, 4 Aug 2008 01:47:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D07283A680E for ; Mon, 4 Aug 2008 01:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvfZ-000PQh-4C for ccamp-data@psg.com; Mon, 04 Aug 2008 08:43:57 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPvel-000PLc-QU for ccamp@ops.ietf.org; Mon, 04 Aug 2008 08:43:27 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m748h1I8027887; Mon, 4 Aug 2008 09:43:01 +0100 Received: from your029b8cecfe ([83.70.179.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m748gwAs027867; Mon, 4 Aug 2008 09:43:00 +0100 Message-ID: <02c201c8f60e$196c4480$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Howard Green" , Cc: References: <56D2F550769FAA4CA70D5B2EB8419F1403BC85FF@esealmw118.eemea.ericsson.se> <01be01c8f3b4$10a3eb20$91168182@your029b8cecfe> <56D2F550769FAA4CA70D5B2EB8419F1403BEB9C2@esealmw118.eemea.ericsson.se> Subject: Re: MPLS over OTN Date: Mon, 4 Aug 2008 09:42:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi again Howard, So, to pick apart the control plane in an MPLS network ( I think I am agreeing with you fully)... In band This could only happen using the sort of mechanisms being proposed for ACH. That is, each control plane message is packaged as an MPLS packet and labelled as for the LSP that it is controlling. The TTL is set to one (or more to allow non-adjacent signalling). A secondary label on the stack might be used to identify the control plane when the top-level label expires. We already have the Router Alert label defined. However, such a mechanism would only work for existing LSPs meaning that we could never set up new ones! Out of band in fibre (Bear in mind that the nature of MPLS means that this is very similar to in band except within the switching fabric) To make this work we simply need a reserved label to identify control plane traffic. The Router Alert label already provides this. However, we lack a mechanism for non-adjacent signalling. There are two use cases in GMPLS... 1. Hierarchical and stitched LSPs In this case, we can use the hierarchical or stitched LSP to carry the control traffic. For hierarchical, it is simple since we can put the Router Alert label second on the stack where it will be discovered when the top label is popped. For stitching, we must also set the TTL to expire at the end of the stitching segment. 2. Notify messages These messages may be exchanged between non-adjacent nodes. Normally they rely on IP routing, but there is an option to get them forwarded hop-by-hop by the control planes of the nodes along the LSP - this is NOT IP-based forwarding, but relies on each node on the path of an LSP knowing the next control plane node in each direction (something that is required by RSVP-TE anyway). An alternative is to use the LSP that is being notified, and to set the TTL as necessary also using a Router Alert label just as for stitching. A further alternative (sufficient but not necessary) approach would be to set up a mesh of LSPs to support the control plane. Out of band out of fibre I am inclined to agree that there may often be good reasons to operate this way. Using an IP network as a DCN makes a lot of sense and it should be noted that this does not require that the NEs have IP forwarding capabilities. Cheers, Adrian ----- Original Message ----- From: "Howard Green" To: "Adrian Farrel" ; Cc: Sent: Monday, August 04, 2008 9:23 AM Subject: RE: MPLS over OTN Adrian Thanks (for the homily as well!) My apologies for some lack of clarity. As you say, GMPLS control of OTN is what it is. The use of a G-PID describing an MPLS payload does, presumably, allow an OTN path to be advertised (with suitable policy constraints) as an MPLS forwarding adjacency. In the MPLS layer above this OTN, it is not so obvious how to carry IP "in band", and therefore the GMPLS mechanics seem to be required. As you say, the control plane could be "OOB but in fiber" (or here, in OTN path) or out of fibre. Thus there would seem to be utility in an optional associated channel mechanism for the control plane. I wonder whether there may be a requirement of the reverse kind (maximum diversity between data plane and control plane) in some circumstances. /Howard > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 01 August 2008 10:53 > To: Howard Green; ccamp@ops.ietf.org > Cc: mpls-tp@ietf.org > Subject: Re: MPLS over OTN > > Hi Howard, > > [adding MPLS-TP mailing list] > > Accurate representation of our conversation. > That is, in GMPLS we have label type, switching type, > encoding type, and G-PID. > G-PID identifies the payload and re-uses the Ethertype > codepoints. Thus we can carry MPLS. > If GFP is used for framing, it must also identify the payload > and, as you point out, GFP has an MPLS codepoint. > > That the GFP codepoint for MPLS is the same as that for > "T-MPLS" is good for Option 1 (which is where we are) since > there is no practical difference between MPLS and MPLS-TP. > > Now, the operation of MPLS over OTN that you describe is > actually the operation of an OTN. So the issues of control > channels in OTN are exactly as you describe, but have nothing > to do with the payload protocol. This is simply GMPLS control > of OTN. Period. > > GMPLS control of MPLS-TP is a different kettle of ball games. > Here the switching type is PSC: the same switching type as > for MPLS. A feature of GMPLS is that there is *logical* > separation of control plane and data plane. > This means that the control plane can be in-band (MPLS-TE), > out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre. > > MPLS-TP requirements say that it must be possible to operate > the network "in the absence of IP." I have taken this to mean > "in the absence of IP routing and forwarding" (but this is my > opinion and there is no explicit evidence in the requirements > I-D). With this view... > - We can use IP identifiers (addresses) in the data plane and > the control plane > - We can use IP-based control protocols (GMPLS) > - We can use an IP-based control network if available, but we cannot > mandate it > - Control entities that need to communicate must be allowed to be > IP-adjacent so that there is no requirement for > IP-forwarding in the > network > > I believe we can do all of the above, and often do in GMPLS networks. > The crunch questions are: > 1. What is the physical technology for the data links in the > control plane? > 2. How do we identify control plane traffic when it arrives at a node? > 3. How do we exchange control plane messages between nodes that > do not have a common data link in the control plane? > > Answers are: > 1. We don't care :-) > But a possible answer in MPLS-TP is an LSP (e.g. a > reserved label) 2. From the data link (since there is no need > to disambiguate the control > plane traffic from any other traffic on the data link) 3. > This is a more tricky question. However nearly all of the messages > are exchanged only between data-plane-adjacent nodes. This can be > the case in the IGP-TE protocols, and is true for all messages in > RSVP-TE with a couple of exceptions (below). It is also > the case for > LMP. So IP forwarding is not required in the control plane. > The tricky cases are: > - echo response in LSP Ping (we are rebuilding the OAM) > - Notify message in RSVP-TE (we are considering OAM approaches > for the uses of Notify where IP forwarding is not available) > - "Targeted Path messages" used in hierarchical LSPs (and LSP > stitching). In these cases we are effectively building a virtual > data plane adjacency and should build a parallel virtual control > plane link between the end points (e.g. an LSP). > > We should note that the output of the JWT *appears* to be > that "GMPLS meets the requirements of a control plane for MPLS-TP." > > We should also note that management plane operation of > MPLS-TP is a requirement, and we must assume that management > plane messages may need to be exchanged between management > stations and network nodes using some protocol and connectivity. > > > > Adrian > ----- Original Message ----- > From: "Howard Green" > To: > Sent: Thursday, July 31, 2008 5:55 PM > Subject: MPLS over OTN > > > Just to record for the list a chat with Adrian and Lou Berger. I > discover from reading G.7041 Amendment 2 that there is a codepoint > defined to allow unicast MPLS frames to be carried over OTN (ODUx) > channels by way of GFP encoding. Reading RFC 4328, there is > an encoding > type for ODUx, and the switching type is TDM. There is no > specific G-PID > value defined for the MPLS codepoint (which was probably defined > concurrently with the writing of RFC 4328). Adrian and Lou > took the view > that in this situation, the use of the unicast MPLS ethertype (#8847) > would define for signalling this bearer type (as described in > RFC 3471). > > This is relevant partly because G.7041 amendment 2 defines > the codepoint > to be for "MPLS or T-MPLS". I assume that this usage carries over to > MPLS-TP. In this situation,interestingly, there is no > prospect of inband > IP control, and so GMPLS is the only control plane option. > Is this correct? > Regards Howard > > > > From owner-ccamp@ops.ietf.org Mon Aug 4 08:33:30 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8E428C2F4 for ; Mon, 4 Aug 2008 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 lEHK1ANAdlKj for ; Mon, 4 Aug 2008 08:33:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 990C328C2A7 for ; Mon, 4 Aug 2008 08:33:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1w1-000EUS-Q4 for ccamp-data@psg.com; Mon, 04 Aug 2008 15:25:21 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ1vx-000ETk-Om for ccamp@ops.ietf.org; Mon, 04 Aug 2008 15:25:19 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2CCB2207A0; Mon, 4 Aug 2008 17:25:15 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-d4-48971f5a367d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D6C8C20587; Mon, 4 Aug 2008 17:25:14 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 17:24:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:23:25 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D9179@esealmw110.eemea.ericsson.se> In-Reply-To: <006501c8f63e$56490390$8902a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2NMQrRuV74AIWRc2/REYySSC6WwACPVDgAAIIopA= From: "Diego Caviglia" To: "Maarten Vissers" , "Francesco Fondelli" Cc: , X-OriginalArrivalTime: 04 Aug 2008 15:24:07.0230 (UTC) FILETIME=[22D09DE0:01C8F646] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, I think that the Maarten interpretation is correct. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Maarten Vissers > Sent: luned=EC 4 agosto 2008 16.28 > To: 'Francesco Fondelli' > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > Francesco, >=20 > This requirement defines that the MPLS-TP data (transport) plane = operates > in > the absence of an IP data (transport) plane. This requirement does not = say > anything about the DCN, and the technologies deployed in this DCN. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] > Sent: 04 August 2008 15:00 > To: Maarten Vissers > Cc: Adrian Farrel; Howard Green; ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 2:50 PM, Maarten Vissers > > wrote: > > Adrian, Howard, > > > > The transport network has a DCN, and this DCN inlcudes today a mix = of > > OSI and IP technologies. >=20 > Hi, >=20 > --- draft-jenkins-mpls-mpls-tp-requirements-00 >=20 > o It MUST be possible to operate and configure the MPLS-TP data > (transport) plane without any IP functionality. >=20 > --- >=20 > So what do you think about this requirement? >=20 > Ciao > FF >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From owner-ccamp@ops.ietf.org Mon Aug 4 08:40:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B42D3A688F for ; Mon, 4 Aug 2008 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.28 X-Spam-Level: X-Spam-Status: No, score=-5.28 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 yfAZ4vqm+pG8 for ; Mon, 4 Aug 2008 08:40:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 444723A6836 for ; Mon, 4 Aug 2008 08:40:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ26i-000FmE-OO for ccamp-data@psg.com; Mon, 04 Aug 2008 15:36:24 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ26f-000FlR-3K for ccamp@ops.ietf.org; Mon, 04 Aug 2008 15:36:22 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50D63206A1; Mon, 4 Aug 2008 17:36:19 +0200 (CEST) X-AuditID: c1b4fb3e-ae198bb000004ec0-cf-489721f31b09 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31E362065C; Mon, 4 Aug 2008 17:36:19 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 17:36:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:35:37 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D9192@esealmw110.eemea.ericsson.se> In-Reply-To: <7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RziBN94FSrJJRDqmhVwarGF9HQAACsaQ From: "Diego Caviglia" To: "Francesco Fondelli" , "Maarten Vissers" Cc: , X-OriginalArrivalTime: 04 Aug 2008 15:36:18.0982 (UTC) FILETIME=[D6F91C60:01C8F647] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Opsss you are right! I've missed the term configure! I was focused on the fact that an = MPLS-TP equipment doesn't need to be able to perform IP forwarding at = the data plane. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Francesco Fondelli > Sent: luned=EC 4 agosto 2008 17.32 > To: Maarten Vissers > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers > wrote: > > Francesco, >=20 > Hi Maarten, >=20 > > This requirement defines that the MPLS-TP data (transport) plane > operates in > > the absence of an IP data (transport) plane. This requirement does = not > say > > anything about the DCN, and the technologies deployed in this DCN. >=20 > I agree with you, but I think that "and configure" should be removed. >=20 > How can you *configure* MPLS-TP data plane without IP (or OSI)? > Am I the only one that feel uncomfortable with this piece of text? >=20 > > Regards, > > Maarten >=20 > Ciao > FF > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From owner-ccamp@ops.ietf.org Mon Aug 4 08:54:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C6F28C2F6 for ; Mon, 4 Aug 2008 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 z-lsIXtfqyIp for ; Mon, 4 Aug 2008 08:54:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F17E3A6B6F for ; Mon, 4 Aug 2008 08:54:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2JF-000HMw-Mc for ccamp-data@psg.com; Mon, 04 Aug 2008 15:49:21 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2JB-000HMQ-Kk for ccamp@ops.ietf.org; Mon, 04 Aug 2008 15:49:19 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 17:48:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:48:57 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C591F9@ftrdmel2> In-Reply-To: <7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RzhHZYPvGZHKQvSW9uyhF8h+KQAAEiUw References: <7c923b5e0808040600j6b470e5bjbfd17b306533fcb6@mail.gmail.com><006501c8f63e$56490390$8902a8c0@china.huawei.com> <7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com> From: To: , Cc: , X-OriginalArrivalTime: 04 Aug 2008 15:48:57.0487 (UTC) FILETIME=[9B13C9F0:01C8F649] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Francesco. I guess I understand your concern. I believe the original intention was to say implicitely "It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality *in the data plane*." My interpretation of these requirements is indeed that they apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment, nor the MPLS-TP control plane... Anyway you're right, this could be confusing and it deserves a small rewording. Regards, Julien -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers wrote: > Francesco, Hi Maarten, > This requirement defines that the MPLS-TP data (transport) plane operates in > the absence of an IP data (transport) plane. This requirement does not say > anything about the DCN, and the technologies deployed in this DCN. I agree with you, but I think that "and configure" should be removed. How can you *configure* MPLS-TP data plane without IP (or OSI)? Am I the only one that feel uncomfortable with this piece of text? > Regards, > Maarten Ciao FF _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From owner-ccamp@ops.ietf.org Mon Aug 4 09:39:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0623A6CDE for ; Mon, 4 Aug 2008 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 BT4C9sxGxblD for ; Mon, 4 Aug 2008 09:39:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E2B93A6CB1 for ; Mon, 4 Aug 2008 09:39:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ30n-000Mr7-HQ for ccamp-data@psg.com; Mon, 04 Aug 2008 16:34:21 +0000 Received: from [64.233.182.191] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ30i-000MoO-El for ccamp@ops.ietf.org; Mon, 04 Aug 2008 16:34:19 +0000 Received: by nf-out-0910.google.com with SMTP id g13so2102812nfb.11 for ; Mon, 04 Aug 2008 09:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:reply-to:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:from; bh=s7XvcKbH/HbHVNbJr4zZ3p3OqlNpApJMzlC0NMrOL8s=; b=Jftj2usD2aePsVGoJDxkGouEEzDLkYnl751Pj+vxt4iFxQONxL3y6y60Wfjk8HF4nW KzR6BFu6tnNPTXqo35ooBpnJI/t/O8x9PfLDLRUzL/x4WqskUpCn+iSw6M1Obbc4z1zF ipOt1uOR1R8uaBiFeem4yE0/Vq2dAF/iCqHbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:reply-to:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:from; b=dpjYRhchio9bf2AvpC8OfhEqKV7+ewYfzdEdhaP4OONtuESpoc4vVYTP7xEQ6MMXPw mM6iAk/zwcg+A4a+3yTOXu1Qql7UaJ/u4A0FXahEvaeJ7/4elu5pzQnx45J/Rnti/spG ZFStraG68yUhSYIwuiw5IhXO4OdNLvdppW/W0= Received: by 10.210.16.20 with SMTP id 20mr17213123ebp.134.1217867637889; Mon, 04 Aug 2008 09:33:57 -0700 (PDT) Received: from ?10.42.3.6? ( [84.203.178.18]) by mx.google.com with ESMTPS id f13sm11329918gvd.2.2008.08.04.09.33.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Aug 2008 09:33:56 -0700 (PDT) Message-ID: <48972F70.6090503@chello.nl> Date: Mon, 04 Aug 2008 18:33:52 +0200 Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francesco Fondelli CC: ccamp@ops.ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] MPLS over OTN References: <7c923b5e0808040600j6b470e5bjbfd17b306533fcb6@mail.gmail.com> <006501c8f63e$56490390$8902a8c0@china.huawei.com> <7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com> In-Reply-To: <7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Huub van Helvoort Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Francesco, You replied: >> This requirement defines that the MPLS-TP data (transport) plane operates in >> the absence of an IP data (transport) plane. This requirement does not say >> anything about the DCN, and the technologies deployed in this DCN. > > I agree with you, but I think that "and configure" should be removed. > > How can you *configure* MPLS-TP data plane without IP (or OSI)? > Am I the only one that feel uncomfortable with this piece of text? By using the same NMS that is used to configure the OTN node. Ciao, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Mon Aug 4 11:15:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C171F3A6CAB for ; Mon, 4 Aug 2008 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 SbeiGSCNe4gJ for ; Mon, 4 Aug 2008 11:15:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D84FA3A6783 for ; Mon, 4 Aug 2008 11:15:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ4TB-0007aI-D7 for ccamp-data@psg.com; Mon, 04 Aug 2008 18:07:45 +0000 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ4T7-0007ZO-Ce for ccamp@ops.ietf.org; Mon, 04 Aug 2008 18:07:43 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-6.tower-203.messagelabs.com!1217873236!23726407!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 8946 invoked from network); 4 Aug 2008 18:07:17 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 4 Aug 2008 18:07:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m74I7c6G018150 for ; Mon, 4 Aug 2008 14:07:38 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m74I7WOi018046 for ; Mon, 4 Aug 2008 14:07:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: NomCom-volunteer Date: Mon, 4 Aug 2008 14:07:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NomCom-volunteer thread-index: Acj2TEKPEHtwOvNCSfG6nt/b+J+rWQAEFYaQ From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Volunteers needed...=20 -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Sunday, August 03, 2008 10:43 AM To: Working Group Chairs Subject: Please ask your WG...=20 To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: = https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: = https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org From owner-ccamp@ops.ietf.org Mon Aug 4 11:36:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5858E3A6BD6 for ; Mon, 4 Aug 2008 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 X09SCgwEnFaJ for ; Mon, 4 Aug 2008 11:36:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6127A3A6824 for ; Mon, 4 Aug 2008 11:36:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ4qH-000ADf-4K for ccamp-data@psg.com; Mon, 04 Aug 2008 18:31:37 +0000 Received: from [135.245.0.35] (helo=ihemail2.lucent.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ4qD-000AD2-9t for ccamp@ops.ietf.org; Mon, 04 Aug 2008 18:31:35 +0000 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m74IVOo9014890; Mon, 4 Aug 2008 13:31:25 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.11]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 13:31:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 13:31:24 -0500 Message-ID: In-Reply-To: <022e01c8f65d$cce76f90$63466297@vim.tlt.alcatel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2SyOUHLaTSfOxR92M5/JXYSVBKwAEb4AwAACvwtA= References: <7c923b5e0808040600j6b470e5bjbfd17b306533fcb6@mail.gmail.com><006501c8f63e$56490390$8902a8c0@china.huawei.com><7c923b5e0808040831w757b6a76xfed5fc18bf7a11f8@mail.gmail.com><7DBAFEC6A76F3E42817DF1EBE64CB02605C591F9@ftrdmel2><7c923b5e0808040859u58a0d2d0k31c30bd28a49e3a1@mail.gmail.com> <022e01c8f65d$cce76f90$63466297@vim.tlt.alcatel.it> From: "Lam, Hing-Kam \(Kam\)" To: "Italo Busi" , "Francesco Fondelli" , Cc: , X-OriginalArrivalTime: 04 Aug 2008 18:31:24.0674 (UTC) FILETIME=[4CDA7E20:01C8F660] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear all, Julien's proposed rephrase is good. By the way, DCN requirements (more specifically Management Communication Network (MCN) requirements) are already described in draft-gray-mpls-tp-nm-req-00.txt. Of course comments for improvement are always welcome. Regards, Kam -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Italo Busi Sent: Monday, August 04, 2008 2:14 PM To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] MPLS over OTN I think that Julien's proposed rephrase better describes the requirement so I support it. It is worth noticing that in case of static configuration and OSI based DCN, the MPLS-TP data (transport) plane is actually configured without any IP functionality. However I think that DCN requirements should be described in draft-gray-mpls-tp-nm-req-00.txt. For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I think that it is more appropriate to rephrase the requirement as proposed by Julien. Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > Sent: Monday, August 04, 2008 6:00 PM > To: julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 5:48 PM, =20 > wrote: > > Hi Francesco. >=20 > Hi Julien, >=20 > > I guess I understand your concern. I believe the original=20 > intention was > > to say implicitely "It MUST be possible to operate and configure the > > MPLS-TP data (transport) plane without any IP functionality=20 > *in the data > > plane*." My interpretation of these requirements is indeed that they > > apply to the MPLS-TP data plane only, not the=20 > MPLS-TP-capable equipment, > > nor the MPLS-TP control plane... > > > > Anyway you're right, this could be confusing and it deserves a small > > rewording. >=20 > Nice, thanks a lot. >=20 > > Regards, > > > > Julien >=20 > Ciao > FF > _______________________________________________ > 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 From owner-ccamp@ops.ietf.org Mon Aug 4 14:36:47 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59BC3A6A16 for ; Mon, 4 Aug 2008 14:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 NKc2QxieQGQT for ; Mon, 4 Aug 2008 14:36:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2ACF028C281 for ; Mon, 4 Aug 2008 14:34:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ7dT-0004M9-NM for ccamp-data@psg.com; Mon, 04 Aug 2008 21:30:35 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ7dP-0004LW-Dv for ccamp@ops.ietf.org; Mon, 04 Aug 2008 21:30:33 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3F2503A6A35; Mon, 4 Aug 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080804213001.3F2503A6A35@core3.amsl.com> Date: Mon, 4 Aug 2008 14:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-ted-mib-04.txt Pages : 26 Date : 2008-8-4 This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ted-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-4141916.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Aug 5 00:52:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E225A3A695A for ; Tue, 5 Aug 2008 00:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 SQom0SMc809P for ; Tue, 5 Aug 2008 00:52:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD75C3A6B81 for ; Tue, 5 Aug 2008 00:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQHAq-0005cd-UV for ccamp-data@psg.com; Tue, 05 Aug 2008 07:41:40 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQHAl-0005bd-H6 for ccamp@ops.ietf.org; Tue, 05 Aug 2008 07:41:38 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5CF3C20C39; Tue, 5 Aug 2008 09:41:32 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-ba-489803bed35a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 698C420BD0; Tue, 5 Aug 2008 09:39:42 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Aug 2008 09:38:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over OTN) Date: Tue, 5 Aug 2008 09:38:04 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D92D9@esealmw110.eemea.ericsson.se> In-Reply-To: <022e01c8f65d$cce76f90$63466297@vim.tlt.alcatel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over OTN) Thread-Index: Acj2SyOUHLaTSfOxR92M5/JXYSVBKwAEb4AwABvnXaA= From: "Diego Caviglia" To: "Italo Busi" , "Francesco Fondelli" , Cc: , X-OriginalArrivalTime: 05 Aug 2008 07:38:46.0952 (UTC) FILETIME=[4B720A80:01C8F6CE] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, So we are at the point where we agreed that Ip forwarding is not = needed in the data plane nevertheless Ip is needed for sure for GMPLS = protocols (if used). Now in this thread we mentioned several times the DCN, are there any = requirement about the protocol to be used for the DCN? Do we think that = the DCN should support both OSI and Ip? Given that we are in IETF I think the answer is that the DCN and = configuration protocol must be Ip based, but may be could be useful = state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is = the right place. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Italo Busi > Sent: luned=EC 4 agosto 2008 20.14 > To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > I think that Julien's proposed rephrase better describes the = requirement > so I > support it. >=20 > It is worth noticing that in case of static configuration and OSI = based > DCN, the > MPLS-TP data (transport) plane is actually configured without any IP > functionality. >=20 > However I think that DCN requirements should be described in > draft-gray-mpls-tp-nm-req-00.txt. >=20 > For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I = think > that it > is more appropriate to rephrase the requirement as proposed by Julien. >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > > Sent: Monday, August 04, 2008 6:00 PM > > To: julien.meuric@orange-ftgroup.com > > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] MPLS over OTN > > > > On Mon, Aug 4, 2008 at 5:48 PM, > > wrote: > > > Hi Francesco. > > > > Hi Julien, > > > > > I guess I understand your concern. I believe the original > > intention was > > > to say implicitely "It MUST be possible to operate and configure = the > > > MPLS-TP data (transport) plane without any IP functionality > > *in the data > > > plane*." My interpretation of these requirements is indeed that = they > > > apply to the MPLS-TP data plane only, not the > > MPLS-TP-capable equipment, > > > nor the MPLS-TP control plane... > > > > > > Anyway you're right, this could be confusing and it deserves a = small > > > rewording. > > > > Nice, thanks a lot. > > > > > Regards, > > > > > > Julien > > > > Ciao > > FF > > _______________________________________________ > > 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 From owner-ccamp@ops.ietf.org Tue Aug 5 02:21:32 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2CA3A68D2 for ; Tue, 5 Aug 2008 02:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-1.332, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 y5tb+jD7pl1t for ; Tue, 5 Aug 2008 02:21:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D63C43A6894 for ; Tue, 5 Aug 2008 02:21:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIel-000Dp9-Ca for ccamp-data@psg.com; Tue, 05 Aug 2008 09:16:39 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIeh-000DnD-IS for ccamp@ops.ietf.org; Tue, 05 Aug 2008 09:16:37 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m759G0u4007336; Tue, 5 Aug 2008 10:16:00 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m759Fs1m007136; Tue, 5 Aug 2008 10:15:58 +0100 Message-ID: <03a201c8f6db$df138bd0$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Maarten Vissers" , "'Howard Green'" , Cc: References: <004201c8f630$a197c380$8902a8c0@china.huawei.com> Subject: Nit in Maarten's definition of the DCN Date: Tue, 5 Aug 2008 10:15:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Maarten had... > A transport network element is connected to the DCN via two or more > interfaces. This needs to read "one or more". A From owner-ccamp@ops.ietf.org Tue Aug 5 02:39:45 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6B13A6ACC for ; Tue, 5 Aug 2008 02:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 OWWIQbyrUiO4 for ; Tue, 5 Aug 2008 02:39:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 766BA3A6894 for ; Tue, 5 Aug 2008 02:39:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIub-000F8G-Rh for ccamp-data@psg.com; Tue, 05 Aug 2008 09:33:01 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIuX-000F7d-78 for ccamp@ops.ietf.org; Tue, 05 Aug 2008 09:32:59 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m758xlbx027141; Tue, 5 Aug 2008 09:59:50 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m758xhZv026991; Tue, 5 Aug 2008 09:59:45 +0100 Message-ID: <035b01c8f6d9$9b054890$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Maarten Vissers" , "'Diego Caviglia'" , "'Italo Busi'" , "'Francesco Fondelli'" , Cc: , References: <003001c8f6d4$965d3690$8902a8c0@china.huawei.com> Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Date: Tue, 5 Aug 2008 09:54:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Maarten, I think you need to get off this OSI thing. Nothing the IETF does will require the use of IP in the DCN for an MPLS-TP stack. However, the IETF will only work on DCN protocols that are based on IP. It will remain possible to manage MPLS-TP functionality using a DCN based on OSI, SNA, PNNI, or bluetak. Since IP stacks are freely available and pretty small, and since it has already been established that IP forwarding is not necessarily required in the NEs, I don't know why this thread continues. A ----- Original Message ----- From: "Maarten Vissers" To: "'Diego Caviglia'" ; "'Italo Busi'" ; "'Francesco Fondelli'" ; Cc: ; Sent: Tuesday, August 05, 2008 9:23 AM Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Diego, The MPLS-TP functionality may be in equipment with e.g. SDH and OTN functions. If such equipment uses MS-DCC to connect to the DCN, then it is very likely that OSI is used. The MPLS-TP functions in this equipment should **not** require that this equipment has to be equipped with two more DCN connections supporting IP. I.e. it should be posible to manage MPLS-TP functionality in equipment also via an OSI type DCN connection. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Diego Caviglia Sent: 05 August 2008 09:38 To: Italo Busi; Francesco Fondelli; julien.meuric@orange-ftgroup.com Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Hi all, So we are at the point where we agreed that Ip forwarding is not needed in the data plane nevertheless Ip is needed for sure for GMPLS protocols (if used). Now in this thread we mentioned several times the DCN, are there any requirement about the protocol to be used for the DCN? Do we think that the DCN should support both OSI and Ip? Given that we are in IETF I think the answer is that the DCN and configuration protocol must be Ip based, but may be could be useful state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is the right place. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Italo Busi > Sent: luned́ 4 agosto 2008 20.14 > To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN > > I think that Julien's proposed rephrase better describes the > requirement so I support it. > > It is worth noticing that in case of static configuration and OSI > based DCN, the MPLS-TP data (transport) plane is actually configured > without any IP functionality. > > However I think that DCN requirements should be described in > draft-gray-mpls-tp-nm-req-00.txt. > > For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I > think that it is more appropriate to rephrase the requirement as > proposed by Julien. > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > > Sent: Monday, August 04, 2008 6:00 PM > > To: julien.meuric@orange-ftgroup.com > > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] MPLS over OTN > > > > On Mon, Aug 4, 2008 at 5:48 PM, > > wrote: > > > Hi Francesco. > > > > Hi Julien, > > > > > I guess I understand your concern. I believe the original > > intention was > > > to say implicitely "It MUST be possible to operate and configure > > > the MPLS-TP data (transport) plane without any IP functionality > > *in the data > > > plane*." My interpretation of these requirements is indeed that > > > they apply to the MPLS-TP data plane only, not the > > MPLS-TP-capable equipment, > > > nor the MPLS-TP control plane... > > > > > > Anyway you're right, this could be confusing and it deserves a > > > small rewording. > > > > Nice, thanks a lot. > > > > > Regards, > > > > > > Julien > > > > Ciao > > FF > > _______________________________________________ > > 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 From owner-ccamp@ops.ietf.org Tue Aug 5 09:33:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D503A67EE for ; Tue, 5 Aug 2008 09:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 NNbGSNAhcfGJ for ; Tue, 5 Aug 2008 09:33:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC84F3A6A14 for ; Tue, 5 Aug 2008 09:33:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQPOy-0002LP-TO for ccamp-data@psg.com; Tue, 05 Aug 2008 16:28:48 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQPOu-0002KH-OL for ccamp@ops.ietf.org; Tue, 05 Aug 2008 16:28:46 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m75GSfli015186 for ; Tue, 5 Aug 2008 17:28:41 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m75GSd2w015162 for ; Tue, 5 Aug 2008 17:28:40 +0100 Message-ID: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Poll for RWA Info model as WG I-D Date: Tue, 5 Aug 2008 17:24:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to be pretty mature. Note that despite the file name, the content of this document is consistent with its title: "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks." That is, the scope is limited to the information model for RWA. Can we have your opinion, please, on whether this document is ready to be adopted as a working group I-D. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Aug 5 09:51:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA223A6A48 for ; Tue, 5 Aug 2008 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 sHIeQt45V4Sm for ; Tue, 5 Aug 2008 09:51:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C6023A68B2 for ; Tue, 5 Aug 2008 09:51:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQPgA-0004KM-5m for ccamp-data@psg.com; Tue, 05 Aug 2008 16:46:34 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQPg6-0004JZ-8C for ccamp@ops.ietf.org; Tue, 05 Aug 2008 16:46:32 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id m75GkNFY069226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 09:46:26 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <489883E0.7020503@grotto-networking.com> Date: Tue, 05 Aug 2008 09:46:24 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes. (from one of the authors). Regards Greg B. Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Tue Aug 5 11:36:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2563C3A69C4 for ; Tue, 5 Aug 2008 11:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Voj2339fhfsS for ; Tue, 5 Aug 2008 11:36:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C15F63A683D for ; Tue, 5 Aug 2008 11:36:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRJi-000Fd5-TR for ccamp-data@psg.com; Tue, 05 Aug 2008 18:31:30 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRJc-000Fc3-DP for ccamp@ops.ietf.org; Tue, 05 Aug 2008 18:31:27 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K55000Q44SB8H@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 05 Aug 2008 13:31:23 -0500 (CDT) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5500G5T4S7OP@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 05 Aug 2008 13:31:23 -0500 (CDT) Date: Tue, 05 Aug 2008 13:31:13 -0500 From: Young Lee Subject: RE: Poll for RWA Info model as WG I-D In-reply-to: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> To: ccamp@ops.ietf.org Message-id: <001201c8f729$713c34b0$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acj3GKDaCQlkF3tuQJ6CuHJEqe89awAELqog References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: In favor of the draft to be WG draft. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 05, 2008 11:24 AM To: ccamp@ops.ietf.org Subject: Poll for RWA Info model as WG I-D Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to be pretty mature. Note that despite the file name, the content of this document is consistent with its title: "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks." That is, the scope is limited to the information model for RWA. Can we have your opinion, please, on whether this document is ready to be adopted as a working group I-D. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Aug 5 23:59:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC3F3A67E6 for ; Tue, 5 Aug 2008 23:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.183 X-Spam-Level: X-Spam-Status: No, score=-5.183 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 z0bmXZuP7GPv for ; Tue, 5 Aug 2008 23:59:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FFF73A67DD for ; Tue, 5 Aug 2008 23:59:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQcnZ-0003Yd-Hb for ccamp-data@psg.com; Wed, 06 Aug 2008 06:47:05 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQcnV-0003Xj-En for ccamp@ops.ietf.org; Wed, 06 Aug 2008 06:47:03 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71AA3211E9; Wed, 6 Aug 2008 08:46:59 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-a1-489948e383af Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 51D3E205CE; Wed, 6 Aug 2008 08:46:59 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 08:46:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Wed, 6 Aug 2008 08:46:16 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF68401A0C3F5@esealmw110.eemea.ericsson.se> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQRJe34KZVp2TAasG/Y59QRqeQAdw4pg From: "Diego Caviglia" To: "Adrian Farrel" , X-OriginalArrivalTime: 06 Aug 2008 06:46:59.0191 (UTC) FILETIME=[397D1870:01C8F790] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, Yes (from a contributor). BR Ciao Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: marted=EC 5 agosto 2008 18.24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D >=20 > Hi, >=20 > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed > to > be pretty mature. >=20 > Note that despite the file name, the content of this document is > consistent > with its title: "Routing and Wavelength Assignment Information Model = for > Wavelength Switched Optical Networks." That is, the scope is limited = to > the > information model for RWA. >=20 > Can we have your opinion, please, on whether this document is ready to = be > adopted as a working group I-D. >=20 > Thanks, > Adrian and Deborah >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 6 02:11:08 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437003A6A15 for ; Wed, 6 Aug 2008 02:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 MNgkWkfK+X8Y for ; Wed, 6 Aug 2008 02:11:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C2313A6900 for ; Wed, 6 Aug 2008 02:11:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQex5-000FX7-SU for ccamp-data@psg.com; Wed, 06 Aug 2008 09:05:03 +0000 Received: from [192.91.191.8] (helo=smtp2.dataconnection.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQex2-000FW6-9D for ccamp@ops.ietf.org; Wed, 06 Aug 2008 09:05:02 +0000 Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2008 10:04:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-rhodes-rsvp-recovery-signaling-00 Date: Wed, 6 Aug 2008 10:04:59 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB106094C41@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rhodes-rsvp-recovery-signaling-00 thread-index: Acj3o4DOGW3WZ0v5Q3eH38o4DzTYjw== From: "David McWalter" To: Cc: "Andrew Rhodes" , "Nic Neate" X-OriginalArrivalTime: 06 Aug 2008 09:04:58.0804 (UTC) FILETIME=[8085C740:01C8F7A3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear all, We would welcome comments on this draft. Andrew Rhodes, Nic Neate, David McWalter. http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling -00.txt Title: Problems observed with RSVP recovery signaling Abstract: Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. From owner-ccamp@ops.ietf.org Wed Aug 6 05:58:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D33C3A6BD7 for ; Wed, 6 Aug 2008 05:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.922 X-Spam-Level: X-Spam-Status: No, score=-4.922 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 XRmcEto3XXUu for ; Wed, 6 Aug 2008 05:58:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83DDD3A6B93 for ; Wed, 6 Aug 2008 05:58:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQiUH-000D55-Qk for ccamp-data@psg.com; Wed, 06 Aug 2008 12:51:33 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQiU4-000D1T-UW for ccamp@ops.ietf.org; Wed, 06 Aug 2008 12:51:23 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9EEE20B52; Wed, 6 Aug 2008 14:51:17 +0200 (CEST) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-eb-48999e4508c4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 90D6B207D5; Wed, 6 Aug 2008 14:51:17 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 14:51:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Wed, 6 Aug 2008 14:51:10 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1403C39271@esealmw118.eemea.ericsson.se> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQPt8l8Mwfb5R1moyhWZDGgskwAqgt/g References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> From: "Howard Green" To: "Adrian Farrel" , X-OriginalArrivalTime: 06 Aug 2008 12:51:17.0607 (UTC) FILETIME=[1E1EAF70:01C8F7C3] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: yes > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 05 August 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D >=20 > Hi, >=20 > draft-bernstein-ccamp-wson-info-03.txt was discussed in=20 > Dublin and seemed to be pretty mature. >=20 > Note that despite the file name, the content of this document=20 > is consistent with its title: "Routing and Wavelength=20 > Assignment Information Model for Wavelength Switched Optical=20 > Networks." That is, the scope is limited to the information=20 > model for RWA. >=20 > Can we have your opinion, please, on whether this document is=20 > ready to be adopted as a working group I-D. >=20 > Thanks, > Adrian and Deborah >=20 >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Aug 6 07:52:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3AE28C0FC for ; Wed, 6 Aug 2008 07:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 gchSXGmRE5yt for ; Wed, 6 Aug 2008 07:52:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50E523A6BD5 for ; Wed, 6 Aug 2008 07:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQkGo-0004Yy-0F for ccamp-data@psg.com; Wed, 06 Aug 2008 14:45:46 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQkGj-0004Xz-QR for ccamp@ops.ietf.org; Wed, 06 Aug 2008 14:45:44 +0000 X-IronPort-AV: E=Sophos;i="4.31,315,1215388800"; d="scan'208";a="16405767" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2008 14:45:38 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m76EjcbN015555; Wed, 6 Aug 2008 16:45:38 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m76Ejcl9002803; Wed, 6 Aug 2008 14:45:38 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 16:45:38 +0200 Received: from [10.55.224.245] ([10.55.224.245]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 16:45:37 +0200 From: Dirk Schroetter To: "Adrian Farrel" In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Subject: Re: Poll for RWA Info model as WG I-D X-Priority: 3 References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Message-Id: <347BCAC2-A789-4329-814C-C34A54DCFD49@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 16:45:36 +0200 Cc: X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 06 Aug 2008 14:45:37.0740 (UTC) FILETIME=[1713E8C0:01C8F7D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=701; t=1218033938; x=1218897938; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dschroet@cisco.com; z=From:=20Dirk=20Schroetter=20 |Subject:=20Re=3A=20Poll=20for=20RWA=20Info=20model=20as=20 WG=20I-D |Sender:=20; bh=TFtYPAqTcfNW7yWooQymkvssOFPwIm+G8FuZFC3ZDYA=; b=KVIgekcMKhCjImTY8k8vwYgYfDBrW/dg/0NMf2qXHNL9pRWdKCSWCM+XYF fngEv9lSLbeGo1uVqcidQPpLv7IXASB7DOMSDtiFgqdtUh1qtyL5ARfpgF+Q fwbEH+VmyS; Authentication-Results: ams-dkim-2; header.From=dschroet@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I am in favor of this document being adopted as a working group I-D. Best Regards, /Dirk Am 05.08.2008 um 18:24 schrieb Adrian Farrel: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That > is, the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready > to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 08:17:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F3F3A6AC8 for ; Wed, 6 Aug 2008 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] 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 1tDIxfNi0ucc for ; Wed, 6 Aug 2008 08:17:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70A4B3A6A3F for ; Wed, 6 Aug 2008 08:17:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQkhI-0008cC-1k for ccamp-data@psg.com; Wed, 06 Aug 2008 15:13:08 +0000 Received: from [129.60.39.147] (helo=tama50.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQkhE-0008bd-7A for ccamp@ops.ietf.org; Wed, 06 Aug 2008 15:13:06 +0000 Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m76FD2lf002496 for ; Thu, 7 Aug 2008 00:13:02 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6E62965FE for ; Thu, 7 Aug 2008 00:13:02 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 650B265FD for ; Thu, 7 Aug 2008 00:13:02 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m76FD121025773 for ; Thu, 7 Aug 2008 00:13:01 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m76FD1MH025761 for ; Thu, 7 Aug 2008 00:13:01 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m76FCpjF008507 for ; Thu, 7 Aug 2008 00:13:01 +0900 (JST) Message-ID: <4899BED1.3090800@lab.ntt.co.jp> Date: Thu, 07 Aug 2008 00:10:09 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes Tomonori Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 10:42:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5727C3A68F1 for ; Wed, 6 Aug 2008 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 1i2ka17j2xLm for ; Wed, 6 Aug 2008 10:42:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89B643A66B4 for ; Wed, 6 Aug 2008 10:42:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQmwW-0001CE-Tr for ccamp-data@psg.com; Wed, 06 Aug 2008 17:37:00 +0000 Received: from [213.150.41.59] (helo=dkcphmx22.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQmwS-0001BZ-Kl for ccamp@ops.ietf.org; Wed, 06 Aug 2008 17:36:58 +0000 Received: (qmail 19374 invoked by uid 74); 6 Aug 2008 17:36:53 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx22.softcom.dk (envelope-from ) with ESMTP. tag msg.1218044213.609137.8887 (Processed in 0.143052 secs); 06 Aug 2008 17:36:53 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx22.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx22.softcom.dk over TLS secured channel with ESMTP; Wed, 06 Aug 2008 19:36:53 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Wed, 6 Aug 2008 19:36:39 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Wed, 6 Aug 2008 19:36:33 +0200 Subject: RE: Poll for RWA Info model as WG I-D Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GcqVkyJoFlZ6SIeU+2nEtLqguQA0Qirw Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF4378721B6274C46@acreoexc01.ad.acreo.se> References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes. Regards, Jonas > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: den 5 augusti 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 16:59:04 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE7F3A6813 for ; Wed, 6 Aug 2008 16:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, 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 t4h619FgFs5r for ; Wed, 6 Aug 2008 16:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FC6F3A6808 for ; Wed, 6 Aug 2008 16:59:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQsoR-000HdV-S4 for ccamp-data@psg.com; Wed, 06 Aug 2008 23:53:03 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQsoN-000Hcn-HP for ccamp@ops.ietf.org; Wed, 06 Aug 2008 23:53:02 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0FB6BEC8B8; Thu, 7 Aug 2008 08:52:56 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id C0D76EC896; Thu, 7 Aug 2008 08:52:55 +0900 (JST) Received: from [127.0.0.1] (c013.vpn.kddilabs.jp [172.19.87.13]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 16375578111; Thu, 7 Aug 2008 08:52:47 +0900 (JST) Message-ID: <489A3937.9020101@kddilabs.jp> Date: Thu, 07 Aug 2008 08:52:23 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, I support this being adopted as a WG document. Regards, tomo Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81= =97=E3=81=9F: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and=20 > seemed to be pretty mature. > > Note that despite the file name, the content of this document is=20 > consistent with its title: "Routing and Wavelength Assignment=20 > Information Model for Wavelength Switched Optical Networks." That is,=20 > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to=20 > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 17:05:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E333A682C for ; Wed, 6 Aug 2008 17:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.355 X-Spam-Level: X-Spam-Status: No, score=-101.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, 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 lQccuenSM8US for ; Wed, 6 Aug 2008 17:05:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A8CC3A680B for ; Wed, 6 Aug 2008 17:05:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQsvL-000IID-WD for ccamp-data@psg.com; Thu, 07 Aug 2008 00:00:12 +0000 Received: from [2001:2f8:29::2] (helo=ns1.nict.go.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQsvH-000IHS-Mu for ccamp@ops.ietf.org; Thu, 07 Aug 2008 00:00:10 +0000 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id m77001dR001629; Thu, 7 Aug 2008 09:00:01 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id m77001sQ021323; Thu, 7 Aug 2008 09:00:01 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id m77001jk021320; Thu, 7 Aug 2008 09:00:01 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 645276E56; Thu, 7 Aug 2008 09:00:01 +0900 (JST) Received: from [127.0.0.1] (ssh2.nict.go.jp [133.243.3.50]) by mail2.nict.go.jp (Postfix) with ESMTP id 23E6B6E4D; Thu, 7 Aug 2008 09:00:01 +0900 (JST) Message-ID: <489A3B00.4050209@nict.go.jp> Date: Thu, 07 Aug 2008 09:00:00 +0900 From: Sugang XU User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, In favor of the draft to be a WG draft. Best Regards, Sugang Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 17:20:00 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17B93A6BAC for ; Wed, 6 Aug 2008 17:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Smz0OjO1Y+kG for ; Wed, 6 Aug 2008 17:20:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04F7B3A6989 for ; Wed, 6 Aug 2008 17:20:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtBG-000KHU-TX for ccamp-data@psg.com; Thu, 07 Aug 2008 00:16:38 +0000 Received: from [119.145.14.67] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtBD-000KGB-6e for ccamp@ops.ietf.org; Thu, 07 Aug 2008 00:16:37 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K57003KMFFMDU@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 07 Aug 2008 08:16:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5700BFDFFMVP@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 07 Aug 2008 08:16:34 +0800 (CST) Received: from l37133 ([10.70.77.57]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5700EJDFFMXJ@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Thu, 07 Aug 2008 08:16:34 +0800 (CST) Date: Thu, 07 Aug 2008 08:16:33 +0800 From: Dan Li Subject: Re: Poll for RWA Info model as WG I-D To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <035101c8f822$d920ef90$394d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes. Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, August 06, 2008 12:24 AM Subject: Poll for RWA Info model as WG I-D > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to > be pretty mature. > > Note that despite the file name, the content of this document is consistent > with its title: "Routing and Wavelength Assignment Information Model for > Wavelength Switched Optical Networks." That is, the scope is limited to the > information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 17:39:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7DF3A6BC6 for ; Wed, 6 Aug 2008 17:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.54 X-Spam-Level: ** X-Spam-Status: No, score=2.54 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] 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 zGAPdw7g9FUZ for ; Wed, 6 Aug 2008 17:39:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF9B93A6B0B for ; Wed, 6 Aug 2008 17:39:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtUX-000M4d-Uz for ccamp-data@psg.com; Thu, 07 Aug 2008 00:36:33 +0000 Received: from [202.32.8.193] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtUU-000M4I-EF for ccamp@ops.ietf.org; Thu, 07 Aug 2008 00:36:32 +0000 Received: from mailgate3.nec.co.jp (mailgate53E.nec.co.jp [10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m770aPOY010541; Thu, 7 Aug 2008 09:36:25 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m770aPg24485; Thu, 7 Aug 2008 09:36:25 +0900 (JST) Received: from togyo.jp.nec.com (togyo.jp.nec.com [10.26.220.4]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m770aPuD005182; Thu, 7 Aug 2008 09:36:25 +0900 (JST) Received: from C08AUG00201 ([10.56.131.165] [10.56.131.165]) by mail.jp.nec.com with ESMTP; Thu, 7 Aug 2008 09:36:25 +0900 Reply-To: From: "Itaru Nishioka" To: "'Adrian Farrel'" , References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:36:24 +0900 Organization: nec Message-Id: <09ECBCBC089143AE8B596DDA8919317C@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acj3GM4nPLSe0Jw1Ti6CKwthFX9ZOwBDJj7g X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes, good. Itaru > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 06, 2008 1:24 AM > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > From owner-ccamp@ops.ietf.org Wed Aug 6 18:46:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC8C3A6922 for ; Wed, 6 Aug 2008 18:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.312 X-Spam-Level: **** X-Spam-Status: No, score=4.312 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_SPAM=3.798, RDNS_NONE=0.1] 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 DGufB3cfk2OE for ; Wed, 6 Aug 2008 18:46:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 659CB3A6BDB for ; Wed, 6 Aug 2008 18:46:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQuWM-0002TS-84 for ccamp-data@psg.com; Thu, 07 Aug 2008 01:42:30 +0000 Received: from [202.103.147.144] (helo=mail.zte.com.cn) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQuWH-0002Sl-ET for ccamp@ops.ietf.org; Thu, 07 Aug 2008 01:42:28 +0000 Received: from [10.30.3.18] by 10.30.2.249 with StormMail ESMTP id 19627.2193680284; Thu, 7 Aug 2008 09:41:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id m771fnSg073572; Thu, 7 Aug 2008 09:41:49 +0800 (CST) (envelope-from gao.feng1@zte.com.cn) To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: gao.feng1@zte.com.cn Date: Thu, 7 Aug 2008 09:44:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2008-08-07 09:41:41, Serialize complete at 2008-08-07 09:41:41 Content-Type: multipart/related; boundary="=_related 00094E9C4825749E_=" X-MAIL: mse1.zte.com.cn m771fnSg073572 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_related 00094E9C4825749E_= Content-Type: multipart/alternative; boundary="=_alternative 00094E9C4825749E_=" --=_alternative 00094E9C4825749E_= Content-Type: text/plain; charset="US-ASCII" Yes, I support this draft to be a WG I-D. Best regard, Feng Gao > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 06, 2008 1:24 AM > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00094E9C4825749E_= Content-Type: text/html; charset="US-ASCII"
Yes, I support this draft to be a WG I-D.

Best regard,
Feng Gao


> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Wednesday, August 06, 2008 1:24 AM
> To: ccamp@ops.ietf.org
> Subject: Poll for RWA Info model as WG I-D
>
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in
> Dublin and seemed to be pretty mature.
>
> Note that despite the file name, the content of this document
> is consistent with its title: "Routing and Wavelength
> Assignment Information Model for Wavelength Switched Optical
> Networks." That is, the scope is limited to the information
> model for RWA.
>
> Can we have your opinion, please, on whether this document is
> ready to be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00094E9C4825749E_=-- --=_related 00094E9C4825749E_= Content-Type: image/gif Content-ID: <_1_07AA7B1007AA78E800094E9A4825749E> Content-Transfer-Encoding: base64 R0lGODdhXAIIAXcAACH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAAXAIIAYf///8A Wq0AAAAASqVjUkJKOinv7/cpGRBjUjq1zt5zWkJza0r37/dCOhkZGQhjjM6MjJwxIRne3u+Ec1qU nJxKUlIxMRClvd5SSjqEc0qlpa3e3tYxIQhKSjEZUuZavea1jBBava1rnM7F3uaErc7FrYRaSjGc hFqllGsxc7UQGXOU5uZSEErmELUIWq3FxcUQWrVa7+a1jEJa760QjOYZUjHmWjq1WhnmGTrmnDqE WhnmWhDmGRDmnBDmnGPmWmPmGWPm3q17lM6EjISUvd5ajMWU762MhFq1raWMrd61hKUQSoTmEObm nITW3ubm3jrmQrXmlLXm3hDma7Xm3mO1EBmEEBkZUlK9va0Zc61CKRlKOjExKSFKGXulrdbe7+8x jOYQWoQQCBm9zu/mWoS95q3mGYQQSghSe6Vzc3NSUhDmlObmQua1vTqEvTrma+a1vRCEvRC1EEqE EEpSEBC9UqW9GaWUUqWUGaW9Unu9GXuUUnuUGXu9Us5KUu9SpVq9Gc5KGe+UUs5KUsWUGc5KGcVS zlpShBBSzhAZhFoZzloZhBAZzhC1nGvm1oS1nHsQAEpjWnO1MRmEMRkQlK0pveYpva2MvXsIveYI va2MvVpSOimchGs6jK3mvcXmvaVKjMVKGZxrGXvmve8IIVJalKUQISkhY7WUc1q1WlJrUpy17zqE 7zpahO+17xCE7xBCUnNSe71KOkq1MUqEMUqMWkopKUq9hGu9Uu+95ntrUu9SpXsp7+YZKZy9Ge9r Ge8ZKe8p762M73uEjCmEjO+UUu9rUsWUGe9rGcUZKcW1hO9SzntShDFSzjEZhHsZznsZhDEZzjGU zr1Se1pS71pSpRBS7xAZpVoZ71oZpRAZ7xC95loI7+YZCJwZCO8I762M71qEjAgZCMW1hM6UzpxS e3spGQBjY0prGZzv/85CUpRKOhlS73u1pe9SpTFS7zEZpXsZ73sZpTEZ7zGEjErm/0K9tWPv//9a nOZjUkoxUghCOikZSqUZCAAAY60ACAAI/wABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnT p1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD Cx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hTq17NurXr17Bjy55N u7bt27hz697NG7EAAQ9/ExTeu7jxhMQZJgfwu/ny49DDOgeucXpzldazXze4nPjz6OC3av+vnv2n debeqYdfr7X794nvW45HON45+/tYv6tHv32g/YPxCdQfevztxx+BELmH3HkCGojfg1AFWGB/DBYU 4HT+ldcghglqCCCHHkIo4lISJpcedQNu+B+CCFKI4okiaXedhCPWGJSJK6rY4HAOeqihgiwGqZCM HPK4Io02JmmeekUyCCSP9Dm5X3pQNlRij0TmqOSWPun34os7Zsidg2FaOCWYYloJXH1YHkkml3Dy 5B6aLcJoZpRoArldigsGKZyXWSIZ56AvzTchjlqWOaaLVR765ph+ronlh4RW2lOROiL65pVnNnqg oASyuVCWlpYa15Ojbspnn6a2emqIQz7/Cqqirta6VoW25qrrrrz26itpR1L0KH1mrhrcScNaaaGy DiWbYaLDISfgr5ZNOS18ERlorbDIXqQts+COuiyx5FJbbbR7mhgpc8/6x26o47p74LvvUtjutN7V aSS+XxbrroLfsgvwtfXCKKm8BBNs74YMM5kvouYKRiaK8uZbsMJh0pmwwP92fC3FH1NMZb3/ghzw xSQLmWfIGDPJsssIf1wxxim7/HDMEfcV7LgwwxwtvT5vvObMINc8M74IFz20zOT2jLPSNNvMXcvF LpzyzyZ7zHHOhym959FAf03z0xMiXfbVUPv85Z9gPws10DyD/fbCUv9M79kOW5x2xbNy/w3XtnPL HXXS8ZqN7sZoUz243UUvnjjWgsMNOdwnSz650ZST7TdfgLMsudMtEm7345Zn7fnSn2vdOMqg3/14 66ibjvi2qbPO9Na4O7v5qzju+HaBYjauJaYDnqm2uhaXnrzG8Cr/3O9u2tn87PFazfb0Yhes++4P bj+V99yHHy5X4Itv/vnop6/++uy3775jCYhAwggIjSCEEPQf9EUSIiSQUPxEYEBCSJAEAyhkBEQo SAJGIAESkOACYyCCF0ZAwCQQQQIAGAH/HgCKIoigCB4EoQhBQUISGtAgDRTBGARCgiKAQgQiwB// LnCPgxiACCIo4PuUdMMYXuCEBLlHAv8eIAIifOEgFCwCCSQARIKMQQQP8B9CDBDDIyokigS5QArG MIIUBGAAYAyAGPH3wRSA8YxoPOMX0zgAEtTQIAa4AAwvQIQHFOECXzgiA+ynRCsWJIlCWOEOIWQ/ GATgFPkjyA2LgD+EfEEIRSBCExXZQik6MpILsR8J/liEMUQwAaAIgAtOMYBO0C8BKThFCvwxAFb6 wx8BgKUrY9nKL8IyBYk0SALul0uC7O8BjTSIED0YwEGu54kuaOUARGnJRQYTAAZIwAkNkARMJmQE SlyIAaypECEEIIZ2lCIJEiABIhDhfkTQ4gUM8gUEiiCZrmylK+e5Rhck4YCM7OVAopn/z/qRIId+ NGZvEhCLL9KSld8EAAPkSAIgRjMWA+jfExuqECJ0Upt3VAgqO1iEETAwnQCQwClWSE4AWDQFKSCB AOsHT3kq85XKJKELXjhJBSqxpgNJACMDOhA6WlSHAtUNKm35UpimQASxcEFHDWgAEpxCjAYNAEUH +ACcFkQI90yIAda4zFhcQAIjsGcCXJCFMcRifsk8ZApAIQSrxi8L8XwlPbMgBC+YtAgYTAgDSIDF gkhgDF9gABHO2kQDCMGrIhiAC4TA06DGRotRlWdczwjLQ4LiqcsU4zIVq8okfMEAEbygYUXAVAOY 9h4MMAAChUCEf+4Tmqc14COLsFYS/7hAjPwQpf3k54IFuqCya0xBAs4pgc/e44RjlWtRwZiF/hnQ C6Y0wHFNS13pAoCgDTUtBQ0aC5S6IAU/HOJRzVhLxU7Vsa8ZgxehOs/lytWgaJwsTL94imSCkawB 4KgIXYhSzS4zBZ1AKUpfKAJQCLiD321hWtlbXzGmIK3+cAFZb7tMpcJwv2FoL0znmwIQIvUUL9yv iD+oyhcuGKoofvBmxbhhMbrgvOhNzQhAEcbNbljDcZ0njmsZV6K2sYb3qCEJoApG4Ga2yJAEbooT wGQav7SWLAajCOwHgCH7Q5X9C7JqMavhAWThAiP4wnFr2MUEBPnMYz6tEGMhhN9uNv+M8IXlk1ss xlMkMManeSRRb+xSPu/Yzznusj3nZ9oL7DmetIwlQjVLVKgetQh9PmhM14nXKsPTi+sEwD0uq1xX poCnI4hffTe5kE0vE5bNpTGgO41oMAoXz6O5IYX/TGta9/nPLyYCeYvI5T67d84bVuYa/azMLJzT gBeYHyn9kYUG5hWaCSjyK4mwATh684yIXMgXIM3KiF73z8D2dQAqDWvPgNLGt/Y1sQGd7mCzsrcC aaoUddppya460O7tckevS79tljMLYDwFT28IUxdYNaTDZXIRDq5eRbMSFABILLjlumMXu7HcmjFs VFl9a3Z7XNrtVupBJCCCZUu2yO3/bre7NZwFUhMkrJFMQAuzbRAvFLkIb1yIRRNCcpS/0qMmv/HK Ux6AWFgS45RB5anDvW5bB5sSRQB4tz0d5sZWWcfKHAAl4qtyYPs5APqEJnkTGlKcOjCxYT8ICYTA 82CLkgQbEEEquzz0Fi8axkh3DBUPrW66gxvlXvafBAIQhrWKoBNEQIPVCSIB8royCwkQrPxsm++T 59ilWVipQbKg2cUmwB9F0Coons2QjMa7iWOdMqQDwHZoiiDDtsT3ujOLS8gU9gUbyDkANvCCxRtk A9VuyAl7bxEDvAALWBiB5h9ycM50cemr7nuXi92JcYoA8ntNgWgHQoI7L+StEZUm/ztJ0Amm27vL Aci0QYTw5M2SFiG7fMi283ePDyZyAwbE4TIzrWscexzrFlcTb2RADBRmBdhOYGVaCGiAYLWA2uVR EBiBI3BCDPBGFWh8wGeBGigQFQhN1daB0EQQIAiCWPAC+5QGafCBAkEBaaABCpVzIAhEFOCCmsaB OXdCG0CDGoAFr1WDL2iDQAhNFAABM5gGFGBAG/iDClWDJdiDNShAMJiEjZEEtxV7KSd0rZRhWegP HCUCutdUpHQKBSFHDtFU8KZRv8Vx8dRxrJQFRRAL3jcQquZSrZR225R2B3EBoScQNocGgiQQIxAA XkAEAwBxBnBbs+d0UDYAReB7Kf+xfAlwCjAwSpMoiWQFA0ZkiZaYApMIA1mAiV+AYqKYXwlxDmIg BkPQEC+wD7JAEBtQATyoVRRgggKxAUMAAbEITUMwBEjgEBSQiwqBBRQwEMsXEVgwBNM0BDToEBBA i6BBRZTldBUHU6fgPy/wfgPxBQX1XzknAeSWSeckAg3hBZfHanSHRh0FZvdwAVLHZ2flBbonEPH3 ECRgVzjkQv1DEKjEZP/kTX5nb1e4aANQjTYxAkqmZG30BVU4ipp1QVE1iilgVRXwG5GQEE1oAPvw G874Ar+RBgc3iwMhAcpIAW/0AhQwg/GmAUigAbTIeyZpABrgggyAfLWoAb9oQBL/QAHKCAAvQD8u GZPBx5NA6QXpUBBIAAGu+AIzGZRYUG05uIMG9AJDAJIAgAUrSYsG0JRXWZVQ2RjPp4bS2Ge9RWag wFMQ1UoEORBFcHQKYQAM8EwHBHJ1F2jBlkzz43O+1kqNWBD3sG9lCArPt0lEMG5mtke31V94qYYq 52615ALwSBMJQGRKJkbzAwNydpkoRgSByJBfBHHESBDn0JEiOBBYIAb7YECRIJor+But+JkEQZW7 14wQEHy/qJK7N5XCOAQm+AItqAHpYJtDiEEbAAE7eJIGMJxDgAUMQAG9qAG4qZMYdIwqOQRpQHq3 SQH4p3kouXvVaQDKKJ1VCQG6/wkAGoCLzmmCnlAOzOmcMemcwIgYY8V0YalhscBWF/VyX7RU+iiO D4FNDnEP2FSOKydf8TR65XdvYLSH+th6DrFLRMAPE4gGazSB63Vo9eYPGaaIAChlJxSPKLFSY8BV KKdZJKCQlLV0Z5QEg0dkaRSRCJGaApAGNsQFv5GKWPAbXHBCMCqjCQGbIpmDPOidEhCTIdWLK9iL UnlC7QkBJ/SLA+GkJnmkVYmMumiCzSgQUhl8mrcBOmmELUmlUZqkIRWLIGmLOIiMBpAG+bOT5DmM ijFkUfZ/txYGltdtyxSHApFYoDBJBhALjrh+bLkQ3CagXddp+eVFKddKaBAL8f+4TX9aECLwQwLR ThYEAA+Abox5oROnqd22pywxSdjkYS40S1JFRSAECq/0RW4IQh7FaKcgYqRmizo5lRSQkQIgCye5 izppQGnwG2KQe2IgAP9ggvdAowKwjK4JALBpixIQphSwnLGoWi/AnjzppuSJgtE6lTbpnMMYpeTJ g0SqUBDgCcN5QiJpnfuUg2lggt6pfLioi8rojFeKBUQ4gyx4nEOAQQxwpVVprYfhTXwnp/MFaC5Q fWqHpyyUVQ6xAQraEPdAAqBQCgDZdH1XYwSrfSEqfgTRWhDhjbrXQEIwn+6VoQF5ebVnE9EmZwHw hwCgkAjFnwKxoqzUsARxo4H/0hzsaqwyGpoCkIob0A/CGpQ++KTO+KMGAAFDCq4uKJJEeJQ8+AIQ sFI2CbXVdrQsWYK4V60r6IJYsIxDMAJmGm+zKYIaILRiupLMyoEmeYsGBJLleXwvELf4Spu0iAT+ Khg1BI2FWqgEqliQBBHY5KEK0X0R4QUkEKJZeFA6tqldlwXBd4ivWlgLBxEOtE/kxbfnV7GJGGwD iYct0QlElgK6Z5CaBbMZRGSmSxAacLM4KxBDgKP3AAGsqayzm6xEOxBpy5wUgEHMCQArORDEqbUC YZs2WaUDMQKj0K/Dq7QcOAT4N548ma8FQYQ1G7WxuZ28F7PjeaUvGW8mmLYM/wC94VoY27S3mjoA JEtxCBUGFhWo3aR+wje5D1F/yTawkaaFCOpxJ5tBWZBSVwW/DOFvIUkCUheQ8ll56gtsAcAP7ksS VhWId1cQJspKpgvBreSZBmGzrNuSzcGSvgoAE9mzCsEALBmSzsuTaWC9KOmcI+AJOumCUjkQROqd TwsBSLABWLCu0VttKCmMwLubukmvaVCUrqiMYMubzsiCJrhHaXDDWaqs2AkAtzgCJvmsaQsA7+q7 z0q+TlZrRYV1mZoFFKSwDeGfEJFsEUFliFpZk6VZl2djcdpjoOBJHKhaf5S6DIHGvgS6l/l4YWCF 0XeOixtXZxgTcGpLoCZL3v92vERGs6TZHCiYBra6DygIo/2QSCFMAF8QrGLwAgegkQehnc5oALsr hLTYhCQ8lXHLgzlImrQ4rVE5hFEshEyafDwZiyQcfCa5g0g7msgJARCQS8f4bCZJhME3nEGKBLeI BDi5xSScP8dHvgc6n4SXqWu4cF3kuQbxAGOQDljgCchXguF8fOFcghBADp7wAp+gzuGMBFZplZ4Q BOp8khQQCbBQDvcMC5FQDvtcDv6cz/gc0P3sz/iczwC9z2kAC2lQAkjQ0A1dAhTA0EhQDiVglQz9 CEjA0Bqd0RxNAeWA0RQA0kOgz3YKcCpUwHVneRPbt8w0tCYxSfdgRlDlyBL/4Gagx3gHtaeflUfD 56srtaMCkQ7BKgBJ/BtIuQ/7YJK/sQ+656GwKRHNF8oFsVJUXRBZaa5UGsoCtHzjO5peDRFRnRcG 0MXmO0sBaUoCEQtkzBD+iQKokAETUAsLsAC1ANd1XQtxPQFwPQETQA8ocAKA/dYZkAF1nQEn4NYZ QNcLcAScANiGfQQnwAmNzQmocAIZ8NaWbdkTcAKP8AiN4NaWDdeX3QglUAKPgAJ8/dZyrQALMAGo UNmf3QiNwAl8vdcnsNm4Pdd43dq1cA4I8NsLQA+woEREkA5JEFEBCsYqLVd/vJh06ALavBEHF5lu LEU5R7pfVMEoFmESNolS/7S6AnAAVsSzPDoCQCsAnoC7YuCm+SMLv3G3xaiszmgTy4mL9Gqk8f17 Rym0nZFzkIbAi7u3hLdEBrBtigVYxSUBCa7gDC4B+BdJG/DWE9DafF3hR4DbR2DXeT3Zga3Xrb0A t33hFI4KKPDXEz7hoo3iHz7Xc53ary3XCODbCnAOGUDZb70ACvDbOs7iC4AAra0AfN3jJuDjPU4A c+3bJtDaCDDkCDABCsDaBJABkVC2DNRAseCG2kenyn2hCHxrC5w/YQ0Sq+dgjVXTrtSwFoxQvyVG d8aRAvCrAgHUAOAJQz0CWHAOkZAPpkAAkYDn5xDCAsDnFZCKCFHCtisR+f+9hBQxkyeplA+Rk/Mt 1ZghcWApT1peqGFAQowESfQFQkQUQh50YaIeC6cgBENw4hO+CZugBk6O1Ei9CSbQAUue5Bbg6hZg AQ2wDyxuAg2A6xFw678eAfuAAATw2/sQAchuARHQAAugBSawCUs+AQ3AAQdwAOZQ7eag6yewABZw 7d5u7RZwACYQ1yYQ7uYQAdZ+AL/eAZvACZuA1OZw7bqOAMge7xYwAeeA4+fA12jQ72jASG/4YB1m 03NapyLbbCcxTZNaWWDkcoqO3YsMiNtdXgFwZzbrAFYUwuX9D7+xAb3KugKwBVbNgU+drIl+6DV0 8st38gyR6PFd1QiheTL/z4E0/9V9QQKJKbJPtrIKtFiPShDjBAAogNdwvQ/nzgUW8NtcYO+6fgTn sA8NkOy1juz7gNecYAJcoO4NgPRIbQGbwOL0bg69TvUEMO6bve/nvg9coA9d3+SPYALZ7uod4Opc 0NqPEO6vvg/vvglckOT4HvX7YOQI0O2/3vdGPteszdfMiXvpoHk431SlFD8gp2iaS2sOFuYfMZgs 5g9hZ+Z6yXiThUak5uZwDgByvgFDzaUgf6s9GukNwfIVAfMRAfsGQfuNQY6YW45hALFyNT9/BGIR sU0GkA5B3trv/uzlPuwLYAJ6PwGcgACvTuwLYOQEwOpN/u7Dfg5PLvgs/44KzG8CBFDsalD2ST7X JqAA+6AGJgD+S374E0AAHWACvq3j8z/90A/rMR7j6//966/jJhABAGEuwr59JhCYMEFAwQICCzhN GKIByYhRACwC+FKEBAAisUYY6DTAn8gBIkf6Q0kSZZiTLVUOKHLx3kWaNW3etGkAZ4oBAXrGrDlz hL8APkXQHFHUZxYSIpyKGGFRgwABphhYPEc1jcUN/ahuSENV7FiyVGXhBEDhxcWrFw2kawsgrkWd aC1eNVA3b925dnHOlGu3L87BftsC9ptY8WLGjR0/Rjsii0qXKS2jPFnki8UiAcLUpckzgWMiSQAg WTAh9cEM5wi8bjAwtf+JTZsObipIe98mE/kWLECA4Pfvc7QRItydHDfuCbkR7GO4bwvBfVwIcuFi ATuXBvsseLdgovgmAh2+W4hgoYF2C9/3NfR+wH1wBBYOvH/dcMKESLDUlRNCgw1oKkICACSYCSR/ UkCJwZcwGymAyygjSQjILrxoBBd6IooImWiSwAUJBzjqIgmU8gcom14Q65xIIuGCKi7SiKQCsUbY gAId0zhARx8pmNFHJNyqSS2cNoAANJuwWEuCDZ6EsiYsKNDJAAoGtImBBA34wpMRsMCisMICM0yw u9giDEM112SzTb8MSEHCCec8ySR/SNAIgAROCWCMDC8QAabHCgQAhf3/9tunHwuEI+A49GwzT772 2ksvAhMm4OScfQ4w54D0qNsngggkzW69fczhArhDEZjAvkojWK+7Bkqt9DwtDrj0nAU6/dQCLbjj wiDcOv2ON00tIFa8hho6IQ1TSCFFhTB6Gs0iIjaiyYABR0gAJDlNmtYyk+wcF6W13MQJLpoCTSmL muIayid/SrQoKZ8CUFHKsvYV61yLhhBAA5qmGkIxI+nyBMoRKPDkiydxpMnIKTXQgII0RojLAAjO TQeCwqb8UUeKaRrzprkKuycuxNBSEl2XX4Z5MRJKotAyliobaQAXihhNQxfy+kLDkgKIqjEJYjIA lQmUXmBW76BbwLVG/7NDoDiE8ltW1VPtO6DrTrszyLWqhRN7AQWgU20fTgpCgIDgXjPI7YPalrtR EzpACLfcjqPbBPu0K6g4BPQmqIPXGFJgghNkgQTaJR4X9CJC0UqgZsoqK3ckFwyMGafJIsT2phBH zNdeovKliUV+9/V3AzEEEONc12H3N0uLDgbgBR8hgGAIHSGgIKKBa8/xhbl0f4FiDSJSHssDX5AA iSHWYoBzuwDTMrGSyQzKppU7Bz/8Nokgl055Me9kMwDgPCWBPWNZChTUFSPhAgCw2O+EExCKevDn fmubCZ7GKgEepzbG6lTXuOa1rpkgA6uZgABxY7a88Y863YHO2QjyHf/rOC0C2QFhB0O4D8OFClXf Gdup9iGcg9jtHArQldJs0bho0WxeJEjAF64FgAtcoGUSAEXmypc5nEXue2yay0wuYJKiFO0m8RIJ vQBgr5LMjy6yWF1ZsGSAfYgFC1zxigDO4hfcrS9lAOiY9eKSPB0ZL3caaBkAfLeBF7xgCL2r4wta hgUBASBHAgtKW7ZnkTN2b3t8MRmaxLdIRiYmQZ8TorjMV631dYsIIiJCCo5CAi8MajOPUNx+8Ga2 Fe6DA5aawDnO8Zzu/IYA7ZFPdRAiH/k4QIF/45SlUnMqDnDBHAxhyGsmQACBoMcC5FnAqSqlBfc0 QFYEkRV6wGZAwJn/YAFqMGV6DoI3AXLhcDDcjynE4LglsIRmATjFCB5ggCCeoggiIIEQirChItaJ TkLcyCDbVISe+MSKJhLRSPJ1IjnNDzF1ZNILsCiACryASQ+ti42osg+ahIUqBCBkRiNWOz8yCQkQ ABOT4kLHNm5AAxB4mCfqggXh+bFicLwJBUCKhDa+K001ieMRSZaYODbSpz81GT/t2ZIwjGhOIvkM TmNBAicyoAg6tcsIjmIATJ3gIaKKgDksQICBNEA+E6jFKhmyn6oRQFfDMYECJaWdDmyQa1vdxCqD swCEcBM4K2zbXIGTEF3llW4tpE9C9hosu1XtNyYQFXVe2bXsWMA1/4jjxAIg8SxSQG5cPTmFO+lJ s5JI0iVZgORK6jmALKjvZYWcoguIIhKeJeACCSDCaAADxXkhpSg9AcUIRjAG9/kJJ5GgSsGyBFyx AJIrr6NKJNKhyIuUMS0QoBjzltcyDazlBb07qfQ2o7EpSYWPYBLdBmjqBQaYFKqJREtckkgT1ALV ve+N6uVcYlScEQVfNZEAJS1ygdAxxgse8oTijpBKDlDHILjSzf/M1pzYhKcWAoROGnDZtfsc527Z 4RR0xHo44MAtbxfMDjShCavzpAc9XAggpzzlWOFswlL7wOBuzpGe7sjmNTDMlCkatwQVLGGoJIkk SlzwucqkICPlCv+yQBdJvpMopScl+RlASWfbESnltinQyRGzIoCt2MSiVKmATSgwFln0NC0cra5c KICXJHEvzX5EAgOodCW65Gh9V0IplfA7JZDScXlDcN5j9DnI74Eme/BFdMwMcAok3/Oo/jhFf3FS BCcu5h6aAcAjjjBgVGxiUQg5Vl0HJ5C4IqBTBEmPABuQOFy2JzttJeF0KNypTVjVqpw4QSqJk5oB 05U2ouoOM6lDOLaZkD0FIYCnG2idTaiBNggYCHUQoIDX6AoFBIAEDcvZ2XpizgUJ4MmcKC2CcPmk sw8qiX7b1Jc4ieu2I0kBYmgrRSqu9skB6ARaiNvlmgBMRj2VqAD/9rGyuDg3zRqrEgWWOzCKGUBA JrUSvJRwD7XImQFTmssfseCFITDJpF8kk14+RBcMnexMiUZ5I5mMOUffjCQBMI1djvaYmd/DUIfS znEUMBC7gueUVbMwFwbCwrTahwueQjUHjdnqczziE58owSOsqrRDUX0CR8g1XQvCmwoGx9jWeQ+r XKUeaBeObVzAJm7oZjaHmGCyjhuAOelU3wHE4gshmdAAjJwApxQBFKB1gdzHheXwhbufVZZQlC0y OiWbKEJNVgrh2YsVrdzEADHiAkdlslCBFcbga7GSARjQMdBIgKVq4SMABCRn0HhCRxHBAgSQsDw6 p070a5aA5tPb/z2cntzMLEt58GH2BdUSsWb2LJcUcUIEDznGCxsJ8AQyMIH6XK04GAT1QAS41RWu Ujx+i8D/ji4p+TwHmn9rLODU8IgglCDqjUABCk4Qf/gbChVH4ATVzY9sAWYVcLZ5jvCQD7Crj8E5 DoKQoO4zKwJYGmwzBRWoLG6LpEYjidiSwJQIAB+CnxL5gg6UKgppvs4hgpzhLM5ylwwxNxLJlk5I wRLMN5yQKH6rCRjRvYvYAFngAqiSM08oEtAbAgYwgOsCjSnZAAOYkiAUGDvLELWgo4+qrugBDYej EtZDEpjaPdvhnuuZi98juZMTvi90jJl5tDEUF0nDiQcINJmJCv8kmD6yMqtUsptacCUTKDC2MbUC W5a7CQ++UiDs+I5kyyuhyzkBeo19mAAkKIH6i79FpL9HeAQUeAjVoL7i2BStQsCD8A7tu4/usA1l sRoENAFsKitqW4AjkIVxipYliLsgMz7M+BkSILJxOQVIIgHrsQghyII6OYWFc5OrkDcSYD5pYD4i EEbmi8JhZCqcCkZkZD77uYuVYSmQOpI0vIl74Ki5cC4s2IDRg4B0QJIwcQu8gJ7YIykKoAlPgACa aDOboKm8wII0WC45GxIAmInDaAwuVIy24EUw5EfHCJFuK6qWkKQqMoDz4op/sgsDwLRDmb7hSKaD UCUBCkC+eZr/U4KOZEPAfTiHv9kNFBKPhQjA91CaBxqOR8CCEpi/+EtJRoS/RjiB4aA+S8QrASKW 5Ggm3nAPCzCc7+iADtiCCFilx5Kht3ucojo+VjwJUDAAJkOyd9MZddOQJiMCfepH8GkvxcACNQIR CDCQQ8KCzWASJVHCO6PG9bGIdKiuQRoMdbmeLsxCJWHLv6jKuUSLETQJfpgQ+kK3O+GIsqSJ0qC5 o9gA6dsPukKPCNACTTEBgYiABbCO4ziH7FA1baKru3qPT+G/t0klCZoASOQETkABpTkCFPgELAhN VPjMlFxJ0Mw/1fiNUfIbSYGm5+iq3DiAUxKVBVig9OiwqAEl/y6goQg8SkdLiQFIp1jEDDsZCQvJ liLwB1CAN3xkDINsy2qEjEPSKHp0DKjSKapsSyXBx5IRT7QguMXYHkGiy/TMFkbLGX/Au3oySpSg tPURAuoUgkpbjATYCCyohUPZhFhqAIM4tX1QgwWIAN5oFK7am/hAgBLghA7YBLBLLMNKjel7G2vL NU4oAahDgSN4hBJAxPxDhRNABVSAxPnTH1xjGgaEtlgqCGlrD705lmEzUBgrlob4DVR4hAXQMXK6 wG5rtJFIgBFgzx87CdOiiQ0Yg5NQt5LzQvXsPe1hLsegSu9kjMLYx50ikyy9CC6VSyuF0i+snJOI tA3IRcsZgP+/SwEicJ688ItLk06bSAL7ubnp8w7dWIAIzQ23IawOKI4IwBu76YAFAKWHeKb2WKEF QIFHlDqDSA1UaATQLIEgSIcgeERInAD2QwKp+8wRxbWqGrDWBDr3WA61kybvOJtjCo6FSA0NBaVh YsBM5VFU7LG4qwyXG0OSOIovQM46SdPfO4WRiAXqTDlfTEgtvcKbitObErTrfNJjPRNizULfuwsv DdNrtYkg8ocwIAH1EaoJ6YRaTIEmTYwRYE7HEAEJSIdDUQ1Y2Y1LOabva47uS4g7lRoT0NDPtIcS 8I7YUDXhQIEg2AAHbRSHAM0PLQG4SAeocz8UQIIgKM2ok7///MO1UM21UAKg3XC25IC2YmGVTC0B LAiCIMAC+CuBAVmuT4gsh5AsGpqW+GyJ8yEizDmKMUUypvCLQBEJv8TWnvXZnwVaDJEAeKu0mXkQ ogEAUFC8DLHFm/gvyCiCIDyUu4KbqtlDt6nRvKnRADqHDV1UR3wEVKgVCLuUT4BY10yN+dvQdGDb 0RvZJnAEtsUCR3hYROzQFNWfq8s1pVmIwsEbNdBMk4RYknXESKQ2g8CUSX1VhhCDHZOWc/MskfCM yE1OPwkBCkmnxODVnjDDoPXczwXdzyUBFyCBliE+CCGJ0SCCB8ApFwhBnLjPx9iAo4gsSeSN3+AN e5UrcwBF/8Tiuqb7hEZ4BHuIP0esD6zCDWExARR4odTYDxRIWLgYvYU120/YAIUtTUcMUU6w2AHL tVxTCNtgQE7QXjB5hCGgxErsh2LKjk8Rj99IJVLQNludQMpFvufMC9U6ifTJz6JIgdAF4AAWYCh9 APy0CJt1iZjQz5og0qa1iclpDHOlqsJ8SOA4gFdCNrMyv7tBiKtVyeL92qiLTYHAm03JGladgEaw 3uWCC0p1YYWtVEvdD6zLOvhNDYe8upDFAk0LDjVAD3PgAAZiDwpzV0FkptylrG1LsuFUzpI4hQvg J52RPJnpiQG24ivG4veaXZz4AjFEMnjyrYsgAuXLCTJWjP8LIAJPqFDqkw3vmDFlaTGuC5bHxNcB W0ThRQF7eEROiM0M85tzcE1W1dG2VdgNoFRPqFS42ICn07Q2lERSXIjnxYJPQMTmYI+s4pS/cQ/o CJW/iQCzEqADCBYIs4XKUsXRSs7L8KycAQURYNPSdYyQkNYspuVatmXFSIBYuIAkKI3S2GXm8yz/ Bcb/IgIvmCdOKmZOej4v8IIkIAE0KOZrYWZp/i9lpmYieCcKwLoFOIFM7BSDsBT6WIA+dCze7YDC BE0UEF7hBVsHPRbG6gC6QeEjaIIgGL17ZltKvV57juGHcMjhyIeFeAQkKM1MiQ8GorAD6ICj60mJ 9A5gsQD/xFmlVEMIfeAxVQyXmRUiufuxAOAkEUiB+rnmZU7m/2rmjhgAcr3llWbplr4IERCCYr4A ky5mZuan0NKZWIjmaOYvEuDlYQRqbC4C5iPmnTbqovYCUBCCUNqPCKjDiKboej2PPbyP1DiHlfxQ R9xX9ysB5jWB7NCqhBCsG/6EtsVnT3BhQx69JniE4KDgSOYERByCPEUWczAHW2qPDlArXPk/guhY CNuEqHFIodNIEzDljN5WowoymY3cezFONCbqYURqmZ6ZznXpy8bsK36qqPIH9znTAMiCc3VLu+gh yBCCFyDRwhxEeOUr+NgbArjTCUic/FvURrDtqOPqht2l/1G5j4aIZBOoZ0RGIwYYWW8c2fbj0KiR 7Ud9xAjypbtmrA0iCAx+Gt1EQGcru9ooCMRhiLbmOQKAlloVPJvJVVWuk9t6XcWQn8xm7/YW4C9g XZlTSj0xCjSmiS9IAH3CIcgQAQpoyAjaG27iJuQIIMNJDxxNUXVe1NxmcFDaHwwrCN9InICVC4UV 2Er9hEdohFuIP9fcj+b+6u+INmtyXsR61wGHteToyXc1sOb9jUyxjx41ZVUsHyNNZZZzCVAQtKh1 7x73cZ81V7+Ip8XjGY4IQQbwofX5Ai8w4Fts8sQogsJUjQR9jaN7UQLwpYLoSUuRDVbBNeh1RAYX 8w6nxP9RsSZAPoKnS+RPaIINDd5auL8jkEOYbJTpRgjhsLVDIYADiDEuwJtRCY9Q8ZRgQcDwgKGA ThwehYTGdRwVoN8ftRwcR7L/fQwRUOkfx/RMTzn+8osi6IQsq4vYJZJ7EII4EW0CWdZsQYM2BCAL E+W7aSv5sBvqOFDV8NQ81nCubgT3c4TcznAUsGo9RTZFLWtPcIQFJ17ChN+l0SDhoDbhUJxPZerF hCY9/c94fZrvgDBZeqwFUwBbaFxUJIUwEAIvkAYROFNVlq/LiaT5DsNL1/R4l3dGWkpnRIuZsTua EHUDEIG6kIARSIEn53HH+II0YFdfM5y6+jCrEesAFI7/tC3eMN91MW9w+UslveHMXX/EqANNCv5M uQImt4n2i8U/kt+UQC+gAkpxCH3R3FUItrNq4DQFWIiEcoAuXjSABAiXoSIKju75o4Jpnr33Tpr3 ojf6RTLXJ+eI3fKJKeZxBhACvXMiB6aLIgDTxRuCEUUU+TDzooslBSA/x9K+HP1yijd73NbwyLrQ wSEI2/iN/gwraHdNVGCI4DiBR7Sqq7s/ptbNVNvr/hPxFzOxA18A3zD4YbIFW4iENIiIFxgBCRA9 yUHloxWip4KKx+D0o9f8zUeXpEeLC9gZPgkAStpsfiJd6XSqWU7SEz2BDEisfdCHyHSPUY42vy4w R83Q/9tG+wZPRDF/RLpy+6/NgNeoGtXYBB11P1DyG3MIbE692AzN+1SqFL3W5K/2FK2yFFjqmsY0 GwVInFSyhRkBHm1U17lICpZrReQTgZnYb8cIcs6H//h/jAQQAiR9YNLqDM7h9xcQqiyg+pwAiCIA BhIsaLAglhMnJnBCcGCfiYgEHkY0cW7fJhMING6ysG8fAgITTnBq9KhEoxIoVTZRWcKeS5X2Tqrk dK4BSE6PUCzYiODchCMoeJqIYE6MuQMHPCIYeWQC1BNHnmbYZ86Cx6X7uFggYGEpl30NimLFymVB vnMEFkyoZcJWhTQUNIzYIIFBQQMiBvjzx7cv4L98Bf8HFkGQxIWDig2OEbL4MeTIkidTrmz5MubM mjdz7uz5M2jQY0RIgDyCX4AUp0gM1Ftk8ABQBiQYgGygSO3LJU6ggrrPQkUCDk10iLiAw75zPc+F 3QRSJEmTKhulPAmzBE2X2V0uMGHBXASPXw+Y46A0qTkHSpWOT2phE1uo8icgAB8hbNgOW00ciIDz IwH3ffTRAgosQIACE5zTQQW2yPWCJwbgVdAIAQzWF2wY+qXhhgOksAFBSSSA2QiGhUaQAAYJsGJB Ka744mIvwlhZii3KeCOMOKooI4qe1djjZD8ONKONPNKoIpInWqZjZkIqeWICRXwRGQl+nTLCQPcU EQv/hlmMQEIAsYwIgIQAgDjQFyZatkFQUC2AkQkExGkBFxJFdAACPSGAgEdqdCDcSJygQJNJ0sVU QhPXIepSI91FsNR5SqlH3gEOcIFUpUupNx57+yQIVQZ8LuXfbx9tUqdWpvJZEUQEuKocKgTIcoUt FFDwAm0HSXAKYRv6yqFgndxTkBeJXTaCY0qyCCQAP7oomZNLPiYktZBV26yP10a27JDMdquZk+E+ eWSLTY775GhTUumXQAPFEoBfAVxgwClZjEmmASS4wBoAUWK2ASdubrTAAmqd41GcFnn3WwQgRRAR RgQL9Qh12EmXnSMlILEoFtc9IidXXGU6qVJnsFfp/3jqqfzVeMhp1MF6SuEUwX1Y7bMUTmOZwIWc ciaH4Fo2EQAXBBq8sEFuBn2Rha+9Xti0C1gWhBhmEqgJ2rOK1bg1tDFy2+yyRJY79rcxju1s2EaK 3a2zKH7NNtniav31jGLL3faQYfeIN9htv41t3NzanfW5oUWpLmRfuDBAJ62lMADkWQBwgYcHRemC AUS4sG/Skz0CVW8Qf2TCAg+rRTrNNAP3mwkYeGfgSEM1gsLs1D2ynUzalZBBRw1/BKmmnJ68KaQW TMqyVvwtNd5vSSkV1qjhZfRQBzSDFOda9FUgCyxDYDGCBMMqlsDTYcDbaxgdXj0QCfdWhuy40X7L 9f+2WgOJt/yAe5t/2YDTr7//vIUt/Amwf3zrH7P+9z8EKrBshHugA/PGwCT57X4SLFxokCU1KgUg AFIDBShS0AkXAEACLkhBESZEkCK4IAuQ6+C+zhQZA6BgIQvZCng4kBEuhCQi5ziACdTwEQREYAus 4gLohkI72t1uJibZzu1MgoLiiId0yFOZpFJmPJSBZUAY6cCekBce4HDhZB+xDwcioB/wfMUcGNlH cQhwAgQ0CBYQQMIL0sEAFRqkE4I5H7Ca5j72jYFEyVKW/ea3tiItcoEIfCS1brQjIkVLWwKkXwMP cq23Melsmpyk2grItUx6koGSjGApAYjBznypkJL/YQCYkiWCKRkAS/cQQQK8ID6CzIYI+opXAE4x SMV44ilBOQcHPPKRCeBkIwQ4x3BcZxEOVCQi72GLEgdFsds1cZtRLNSbBpQRkBWvnMiDY5yUEx+2 PMUhy+MK68CClZ1hJTxAvBnLgEOcjACFANuDBQWwMIa7PIYET/tL+g7aF34VRAQbrEwCGHoi+RGw fnMTnOA+qdFHki1wGXUbJ/eGyiS5TZX5M1LfLknBBNYtgA5s6QQNeD+YqnKVm5GAiCpDAsQkQAgX 4OMXOje+80EuapFBwhEWggoiXs8EE9DnOUjHn+JwpE4mkEVEqmcCVHBVULbb5hMptsShcMIEmzjr /4AU1gEuOGA8LAMQUKByhIAtRCiceJN7GiYeNcqMCw+zwBh/wyc6AZZnahHOOcraoEhQwAsbSAdk iNA0Df2labE5CGkw48v4bdSl1kpkTR1ZUwDyb7SZ1JbcBjjSjrKWoqKMqQXnZ8HTxtakcROpbDlq U8xkjgiWuUAKRACKAZzCt5WRgIX8UYQUeBAy90DBfCwwFjlB8wCuishTW/VMOilMItDcR1JRMZRb PGImFuPm7MQ6AVb9xyKu2kpYRvfM+QQFFZwQ1O1QsBGuANYjWrCAFn5XFuCAxTn78IoXN2EwtWRg Av68AmOPVqbFUG6yHZrsALLQudsIdTJUe1Jq9f9XWo5ujbas3d9nNVpimYKNpC0WMWhhfGL/mVil Ml7xSDFJShbDGMcH3O1mepoZImQhFi4Y0xe8MJAoybChLvDgPVLAjwR0eCAbgC5vFsBd40CkYBaZ wAH+hFiKSARk5gAPW8SrTeyopLzYieIjDkQcE4ilVT7ZiHLoO4EGM4QT5kVBBr6jRgJsQbq+e8/N aoYqiLyxKKPjpwJ+0hQHNygNRrMLZLxg4coGBjABcJ9eMiOEYX4mkjl6LSMxKmJVu6iTpl6bayXY 6rplzZFoO+kkNXnKFt+6pDbuG9pknDdWr9a2wy7prUUL5OOujzJfwldrStMvYx3ElwkoTb5SoGT/ xWAhAzaEJsEKRjDnPHMjD/NhRyByjqieh07hYcsJmPjEQ523FuuuZqvWHZ+kTkUq/haUSj5xAt71 4wBcSYpGftMALdTpNx5p2M4StjAL+EQiIQnJQvxpiyEYjaAFdVqHDsqXhwoZM1JaNspdnPKurbzl M3a5ymH+GC1VOTISaJdkviBtADy7IPfYwC4LUoIayqcW8imQczzSAATsxzgNiMC6YdYPOsHx4jcj HcUO1ZKXtPkIBHMV2Ak2kpGQRImCGspJHPGIsibluwMqI0QcDRzABnZhCOBCB4DzMComRyPZW0AF GsRxCUNmLxbedF9O0bngZgY3MgfyiGUe+ceD/5jy07J8ZDJ7GQYUIeiLIYEQTlGE0ty8X5K5MgpQ kdQBbSTSSflIAxbgxqx2BwGbMArVSdcdLrhHKVinN6Jo4qYJiH0C9kXBfdF+u4B/ImOc8EpSRHY9 U+njUYy2QPWU+UbyfAXiz/vKPg50DgUAZQEYgEWt6NJkxRgew4H0yyEBYFBQiBrz9r8//vOv/916 wbiXEcJDGYQBjMhrQE5xAcADSEAsBOBBeAJZoYKW1ZM5MB3ebUJInIM54J1GrBd7FMdPrNejuFFx /AZ5RAB8nADXcV156RlDKJF5lYAjNN8nfII9lBXvgQVV/QYXqIHt7cMW5J3vmdVDGBidGRxhFf9h f3XZ14nEgdgCQCHBKOgRH+VFJ7zfrwiGUZVQEVhI/FFGvuwfGIahGI4hGfZLF1LGBfgfZslL+w0A a5CA5qSAKy3GIygESRRFRYDRuXHZAajBM5mAA1xFvp3D7QViWAQHxHxHwdVJ0Jxdbxhf2eFOm92V EJ3HIV6XnEDMUkAMTgBWBuqHR2zC0pWKgV3E6ujHWgANWwBeBQAUFiANZBgUyIFcGGxQATYOZiQA A5YhL/aiL/4iaBgAKJCAF+xUMRKjMSYjMnqBCMQCMj5jMfIK5ASGEBDBlnRQChBjEigjMa4dVHCC fF2XPsnJAvDMgfgMHGUP09mMRqiT2BVMJpL/oFLUTKNpRIEQTC2co3c8ihFqoKStG0BGlVnBnehI X5yogXMcjDI5hwKE4hu5ioEEzdCQgi2UQylAgBBw4zGSwGu4H2XFSxH4Uv+5gD8Ek0gq4zGmpDEm QQpV3suF1mhBC0rhWszp1q4lkrJRxq51Uq6hGmaEC91glKkVCTAWjghU4wUkpVIu5VISQVISQQo4 5VImwHBV1oVADnMNQAeJQFMqJRbUYVKVTjWZopwUB/ENkXd9nXM4RzXtSc9cV1ZJRAfoB52ZiheN Tqk0QHxVE2KtBcEYCPkRjHLsiT32REYQh3bBB82IIkbwCaOdlToZCFtMZCSgAQQQ41MqpVSm/+GF AUYYWKU/tE8CJGVPbUixpGFmoqZqSqVTxgJnvWSMXYYlxWaKddbk+UgqQVICYQ1qRVBFedZtFuVl RFRmkAADtiGHXJiFSBRCIN9IEOJaXMRTMeK4nYxxLMAmcB+lBGKlpIfzOE/BqYdF9AN6nIdECNGe LEDMzN5cEkAHqAd6hCClJAU/dl9/dBdbhkeeAFYHIKQeQgQGqEGc3GN8nIMsbBwerZ9iDFenEQZf pIDSiIBfSA5mpMlrshTfsMgDZdTfiEuJfahqBVtK2SZIxdYoBRtN5tavydZHtVqJIklv9lhtVZJw PsltZEZjUEgSkOQsNqhyMSDtSAV9iJvtYf+gU3VH8tClez4PROjHXFLVWz7pgHQFncHMV/AXAfxM RdSHR8DTYZZj9BEWF+DHgPzHlBqFVR3Mesyec8zl9JSZRYSb8U1AHQ1ersTiVQaSG+bF40AOc1IG HF6oimKSrKGS3rSWauXWoRJqjJmYjsHNi5GosRXQBT1qoprWbcnooHZWjYLGqDVebdzG4iDeR2LI ALhmQTgg8nHCUhGf7ZHOWgDhgf1dVMUd+fXlBUanO9aeWrxjROSJWf3QmobfnyxAProK8SFWuC1r uF3gTywHYe6HAuTdR5QRxLHlwjRpBygAt2KTgxFNgtYcQYxAj05o5yjOX5DaDDkeiPGkouL/ViqF WIiqWG3Z5ClVFKNe6knN5E3apImuKIptaoZyUnB26vs0m4f5lhAolEdeGF+0D0EgQbwNRXfUpQnc 1T6kUUXER1HQJ/A8Sp5MQKL1R+rQzFWUbHiMaciABNVtBSHGl11mRNxlxGGiVWOeg729Klu+Uat0 xxf114DyB1fwR/gtQBp84wTIAimkwRAgwRjoUWQQAcN2CHMyAHO5AChM4WSUnEtiaL5u6KFOKqRS kqHWJGkN26IKLKViKomZzbsq0t+crdpuqtka7GY8wC7a3Oi9X684rKdp5YjcQx0qkWOm5+0hzJch KXiEhfZJV/g12D6ExxjppV6GzIDp1XgE/2uo9MQR3AwbjVF/xUykmKcJZIC4bQp6cIob/YRZYYRf WcCB1JPv3WM++oaDUAAS2IXWGoTU6qlfdEKHIYsI/Olk4O253M2/ju2MqhzhvK1n+Wu9vm0FQa+L 0Wi8zi3bli2kAien2m1nXMAZToYIaBrI+S1gOGwwGQCbkARJKNhCpBv2cGzKQoSkEQzrHhh2WkQ4 6purVCwGbERWEUjcvdEEZKCAImJbqpV+DAhQuIVV5Mdd0snrGYgfWlPDoGMDIMiyBowpwMKD1IVk LGyndZq6AoDmWcYI4FzXKurXulTYhtgoJa8LUy/3zrCmxm32Zm+Gzm3cxuj01vCPeW9nFP9B3ppG ERQB4nGa+QoGCSRE7NxVBhAATpAOUEBgT8jJnrhjKq7FrxKmc9xZpBlInqSiuAnHRhyBgJCggy0r 8blJXMWHm2RABkQVnm3ssj4rNNGZR4hEVPmMfvbEPmDAXxoIBEJCBQwBBGBBhOxuQQxXAKSPw6ZA zSUAwkoGLhVOamnoS2lyoQob2uIPsb0UsoHSUErvTD1vDpsW3cjwisXaix4bLMfyiAoxaFwA8UrG lkztEutpJwwd+9LHEIVsb3TEFjTFzhgFeZzZebTdU60Hp3wHefBhfzgPe6hnuBFH6cDsfcyvmCpd mX4EUDDdXWKEgeVJnpxKRlQscYCfcGj/cGB+ayQMwa3c6WMoTmcORhYgzkEQMYmoMC2vUsHS5uXF 5D8X9LLx83AWgR81zSOTaq8EE0PM1QmUma92X1MIhUOwzJi+XfZsBXcJUbU+hINBoD2B7gWnZ+mo xZmpDld8cdOpLnpMIFRA85nVdCCaQz/Ax1q0kcG5SnE4R3jMalrkAwGkwT7IQjxrABZIQDqIK5m4 0AjzRQmncGY8QAkbdGgEdN2CVBBjtVevUgI8QGaIABGcgu+Wr4PCgnw8xYAuQG9kKcTFnf5eYrkB 8M78BFu+yv364VxGRHjMJeyZG0hsQj+I7EPQ70bcTNxlqcHxLDrpHj7hHZmyTPm9CaS8/57P6PFz PBOCJG0FJDWuODUA2PNVZlgJc97OVcYFVPJXt7Zrv/ZmcGUuOtRnckhD+8UAQLKD9kUkNNgR9AYn sO99iVdwD4V8JJ8S/bIxQUU+wvHREd/4vWPRtTE0EWZTFEwGLLc6S1x6Et8SXif2/IQZF0xTFGmb VuseV8QXQ1P/siLTXppoewGDQs6DFnG/sPZj3IaCwjZ/97d/K8bNiTb7jUZy4XYn4NIGkEAVFrhV hoF8qJ6gRPgJzA5Z1RD7ZhNZsa+GC6mQygef9YZ9lZ1CcEJSycdCtElU3FeHz1VET0VwnzgL6ll8 HF/qefey8i+O52r2+FMaJHJdMPJASP8AKGxAC+0UWa9ragPqLf83kze5a4Ne1RSBQeF2AAAv7/ID bnOIOqzinsnViJsdSZD4xGK4cPMbiaf4iy8En82HQujZmhcfv8F4G48dqz7FcrfFnINKGzNrg725 ZN5jKpLfrYo3wVTAOTCW0RiAUwfqCOgzlSz5Y6QwkPNmv65tVgcl/wDlvpayLFMSphOlLDu5qK/Q VX+eCLCQP2TB6CnGF5CAhBJGOXT5NyrRTuwErdu6WBXKoJidiuOXdlQ48tVQhAe7oIR5cOtErd/O iwfK2WWTrSvEXIUXb9DXmruJ2AEmUZ8jGafixe0JVHy2XLxikhuEpB8Lu1bGbcyhTY3/mFZLC93u SKZm6m820Lz7pqWPun8LuaNPBhHPxr4fxJT/BSzgxFnpnl82a+tVt9/53Z6QH2FqRHruiTmzd08s R8U3PDSJsTvWgunKqdid+Fzd13A/RcCE/LC/OH7ZeoWfxE4EDKvK+XPHTtJGQrhHobj6FGZYNWZk JMppevRuhg9/VozG+/ISdI0VG747+QX489aKtRe6EF9YyPKYihnbiVlFhIAuMJ0VPKvUGcTIrIGt g1g0gDeLRQQkExudLAekUTKNShoBFtlnrHj0l80o3IAcMNgXfEYA8BYPphbfIwJEGmGW32fL8wuM wIRZDtNLBjPm4uJjUNBPlLxHqqTC/6Ru3hjl062LenLSizrPX8ZOoTtHMlcpUEAarBvYEQAGYIA/ yUkFyMpRzxkGPKl7vj5x9HUFFMeTnvcW+OBdqix8bUW1whd+NMzKUp0yraxf/UfLjmmh/f6A9P44 GxFeigUX5Aw8qQXN3wosKsZt2LdijIBsHEss/DvkTz6lC6WvpSjnh/qN+Ziv0Vilyn/n47uWlLpi FAH+K80CMsAGvABAUBgSqULBgrIOVpBlypZBhwoRyoqo0BTEgxExympIgNQ+hR8nJoxoSmLJkh0k VkBZ0hQkMS4hmWJIQJZHiSs7MDQhC2VPnj972sopa0uFSGmGaHghwQAAp0+dkiABlf9qVacGiiSw uvVqVq5fwYYVAFVA2bJOx4ZV+zQtWrZu3ZolOzfuWQBt28JFOzYtXqp4+ertG3htYcOHESdWvJhx 469fYo04LAGUhMNJUpQq8kJgmjSRQJ8LHWmaLVK2QBslOFp0JNGibdl67Zr27NkVSNV2/droa9FX ZOk+dw6W6IK7I9l6CYm5KdfFi1cgfs5ow+MGCRp16Dp2heJHKWBZms7qiCJNDQuZelhEEseJ8+bV +/4u3fr38f+1Lx9//K1937IvQL8EpM/AAxFMUEHGEijCMsMuKAKxWAbgBwsNKIBgCKQ825BDW65A zUMONyynxBMjuSKNclb0jEUXW/T/LA0VY3xRRhlZhAWWG3nkMUdSSDEFSFiO6lFG73o8SsnPmEwR tA4hUGoEAxioCiutDCNCBMTUW1Cs/eZLkEACq/IvzP4CTBPAuAZsk80zvYxTzjnpPCzCLw4jQYjD NkghgQ1GuJACDActlAIKllAHAnUO1YDQRg+NlFBFMXzUUEkPVSeNRy2NNNJITPQUggwFGtXUR8IA cshIhzA1Q1OXQGrUVoc4tNZbBaKAyFtr1UC8Daisyov1ChujFPQKI0HCOsv8y677+KNPLraebZas aq8FbNq7qt12W27je/ZbZskt19w4iTjPgHXZbdfde7Aiwt1559UT0Bde8AILLPTV/0DfF0pZohQs 0CjlBV+VQpjfC5Hw1QsK1LnQYSQurFhhgiGwWAMk+pV4YyTQyNjRkUkuGVEVwlgCjZJZ1mBRj1s2 mdFKHcUigRE2YMrdBED5ggF6gd4gljHgBZredM9NWumlmW7a6ae5IuKUIkSommoRrs66aiGKOCWW qh+oWuyxxy4ihRSKiCWWUtBYu+1SYkEjBX7aRoNuNNKuO2+8YykCDTQ6udvvuuNOW+244+ZHbb4H P3ztvtVJAfG/KYe7YMqzGGAJzcOg3HPPSwlD8s9J91ydLEhHvAiqWa/aha/JLttqq8+eXWuscb8a b2Sh7t3334EPXngA0gX2i3WPN/8geXaPv2cDUIj4+fjpla9eZwOEToCBnCXoXgLucw7fAC8c5L77 8L9HX4J0vz9fghHSDx/+EUpJoP0NwEc/ZxFIyBnn+d+3gVHg7HtF2NwABtA/Ai4QUBIgH/7mt4Ex AIqC/9uAF9CAswkOsH3YcxdkEsC8dTFlee2iTPSMRi8SgIJ3w3PhC2EYQxkeJl0tBIt5JFOsWNjw K15ZiwGOZZUqVUUIWKoSA+7hlCReBQAkwBIAhghFJEKRiilAoD+0ckQqahEAQvDCFrXIADGO8Wde ESMAkhjFqkiFPV/M0nlmGEc5zpGOwauhYcZQhByu5QIiUOMNi/DHrySBWGFJwJ7/uBJFElxgLSMI wAD8kYKwbGBZa2FjYSLEnkKqRVmCrOMnQRlKURooQntUSwJi8SBPrhGRltzkVwywwx/CMSxOXAsR 0HAKf6AhLEUsjHl4uJURxAJPhRFBK9cihC2NkpnNdOYzv4LKJ54SFKYEyz1EQASnrJIqPlQLEV5Z lSGKwJpbIQHR1FKEMUjgeIBcYliwMobCSCAyhTEA/wyDlXCeyyzYIte3xlWggO4lXAXNFrW0ZZd+ 8qWf0HQo08yjTR2Wkyvx+mURiglPYvJxn1RZpFpGsEy1CIGRrrQnKOS5FmwiMyzm6ai5olWuMaXp WmDSD1xmitO3kOlM8onpQ4FK/yesIPKdXxnmNMECwsIQgaVfAecsgwmVc6rFCxJt6QMK0yB7FsGq 8CzCS6vSIKQyLVrT8stPC2MmaH2FMIKxVn50Gler+PStcArqXeekrA3Mk6t8HStXurSWVK5FBCn9 Cgm6yhUHEfavVoHMg8JyjyK4US2UTCxYlEXRpfFnpmg9jFoB5E+a8tStN+0sZwsEV8/ilbUJugAo SqqWL3x1my2tp1qwotmwLpObTrkAWJtoWK6MAKunLG5YGOBNsDAAn2vJY2wn+QAhRFVpDbVWWxmz UIRSy66gnas/xzQYwdD1pjRt7XnjJIFjUhcqzJ1uI2/b0sqsRbkVpSVXbInZy/9uRY8mJSxwnxKh xkJliQ3ar9PK6q0DeRdNAAWTWc0brrWGSa0RRu+F5XSPzPZWqhiFr26p4gURFJUreUzmgKNy4Kdg hb1OYSofKwkWfSbLw7jlGojJ+tbQGojBpB2tedEEZLmSF66qxfCR49QgErTYKdKEL4ql2sreCkHF UEmASM0pXKtceSvAWnGNv8KAEcwXns0NyxfWuxYluxC13HqTmNxU5Pn4mExEXlN96lxXOSOZz44x QGYbSVuQFgG6XJFslZ8yWyaD2SrnJDFVfEkVVPbsKYFNany/QkkAA8DATvkCiL9w4xcmGM87FVO3 REvhVHvLuuA6KEFTS+Q+z5r/Pg0SQkZhqUzIfkUChMZtfbfy4lpStioaRjGLoWIAUAQABns0j1oY 8IBCb2W2095KKTldBBcMgKshpEqESPBoWo+b3OXO02Sn1JSoki8BX2Dn+tQjL3YB4J7E5orQcOyU /oKl14et8rCgMswiIutKZQaweQZcPQDMNgXKPMUjH4nAAbgAjiFdrLkxnnGNc0W9LjhFFs6WAhHo zCkWd0EAXJDyzCEQ5adwAQw6QeUULDksYyBzNO/LFREMeKpbkSyeRuCFEZBgACx9ai8BjMoLIO/d 7yOBCFLgAlB4wYr+kDgkIekPrQ8gFglQlrU3Hnaxk3uYLL+iC9AGim1j3R/8/7C61iEOyQBE3Opo W+SUttIgXJsTuIfELzqpUiW/S23ucx/AE3vd4qdb6Qtj8DrWtI32lE8e5Ve/+tu1nnm2+0NZJODw 2EEfevQmoBNst3zWUf/2rFsd4qqXeABOgTdQKPeOsNy3oS++Rq3w0JdWxHoA/LFHEYAdKkiDoteL AIqoR/z1hd+26reeeembPvoTv7XosZ99PjOACFVfffQxj/nNi7/6/mB+LEIsAvbmkcO/3UoSlCnS 6iWA4qDIQvVB8RRhf0XEno4F8wfgkcyP+lIP+qCvANkuDEhg7+JI1sorzhoDoFJNtVCtwlxtu2AN AzMQXLRF+0Kv+w4Q/FJvBP9FMPMEEIFEoIT+DKOqpwXnTSrcZQQc7wKIwAswIwHGYARGIAFoUEtA YeKm5AKi7uROzx9cQAhG4HiGaUq+wN3crQXXJwBK4ZgebvMKUPNKsPzID/pGLpTE5afA8D1ySs66 Jc7ES03cagzv7M5KywPHrvuuiPzG7/sQ0AClzmpWZ3XOJg/5kA9TIJLOJguqEAALr/IiDuVcwB9O 4RTO7hQ64Wwe8RHFZnXuMA+tJpcWce3ojvrkcAuv0BOtTgHzLYa+UAMZygzFha1sCq2wiy7OKj/U 0LR0rMhWyw0xzgBIzwDpUAtJUA596R6AERiT4DzgJRiB0TzizvB+z/y2DuL/Wq8XFTEFgimJ2Oid uO/hDBD4xg8U67ATxW8ATmEBmykwCCO84moN1aLH3Ow/2DHIYNEMZTEV6yIVJ9AWNa5BwkAAdZEX p68EE6jR1M+x0oUR9TEE2U4bsxDrXGDAiOsqqmS2AvAEDZAfww8UO/GKUkAamKwBSw0dg2xNfMxZ WA0wuqtMDOrHhoy79iIlzXHP7HHjJIAEVs4gL5ImwRHvqKL2HKsIQnAfCTAE5y4FZu+rkoAIaFDk lOVs1O6KupEpbfIpfxIUoOyTyHHCrBIkCaoeUfIqL7Ak3VEdKay0SMsjXxL7DCBd9vEpL9IF8Ibm 9C/nqMIAEpETrbAnCdDw/+Lu9U6PBH+yJvuyL2dur4CqKj0yp9gwHVdRyPaMLMHSyD7SwtyxLLNP B3ewMivzZiwTM29mM3VwM8fgAryNigAAZ3iNMzszMy/zNFPzNB2vNRPgNWXwZhxPNTmzNlFzNW9T M3NzBMTtmbDyI3+TLNMKHucqMdvwMd+sME0tJSWzOZ2zz36zK09xyORxLSQwDF9tAynwJLuyO0cy O58zPMVzPMmzPM3zPNEzPdVzPdmzPd3zPeEzPuVzPumzPu3zPvHToRaqFlXRJXmMP9vRJCcQQPOz QA00AhWEQOEjAjlLwvTsQCE0Qh3Ds6azAs+RK86iAzUwAxUM1TryAXdqP/8Hg9RMcR1Fix4VVEJV VPQo9AzR8TCvSznDEjjPcSxXUkZtlCtN9DBBEkZX9EdtcT9nsaesMkDbLEdj8StdcSWRM0fRUEkF SjGBdEpZVEDbMKGKtDjHS6EgU7uQMzLbKkm9FDJ11DGflErRNPso9Elf0T+/VDiz9E1/LM/MBDvZ 9Exn1E3TdE/LbU3F8kbtakB69Dh11DB5KkzlqkwvlDkdE0759FExTkjLq86qMk65iyQ19CqrE1NR UlK1S6E2lTvzrD9GFVJNNT9TNLswNEBPtVVdVVoG6tS00qdS9VVt9VbZrNVwdVd5tVd99VeBNViF dViJtViN9ViRNVmVdVm8mbVZnfVZoTVapXVaqbVarfVasTVbtXVbubVbvfVbwTVcxXVcybVczfVc 0TVd1XVd2bVd3fVd4TVe5XVe6bVe7fVe8TVf9XVf+bVf/fVfATZgBXZgCbZgDfZgETZhFXZhGbZh HfZhITZiJXZiKbZiLfZiMTZjNXZjObZjPfZjQTZkRXZkSbZkTfZkUTZlVXZlWbZlXfZlYTZmZXZm abZmbfZmcTZndXZnebZnffZngTZohXZoibZojRavAgIAOw== --=_related 00094E9C4825749E_=-- From owner-ccamp@ops.ietf.org Wed Aug 6 21:13:37 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E4F3A679F for ; Wed, 6 Aug 2008 21:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 7OnTVRQvHHLr for ; Wed, 6 Aug 2008 21:13:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 623123A682E for ; Wed, 6 Aug 2008 21:13:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQwnc-000EhR-QO for ccamp-data@psg.com; Thu, 07 Aug 2008 04:08:28 +0000 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQwnY-000Eh0-Rv for ccamp@ops.ietf.org; Thu, 07 Aug 2008 04:08:26 +0000 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp02.fnc.fujitsu.com with ESMTP; 06 Aug 2008 23:08:24 -0500 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_01C8F843.5BB78328" Subject: RE: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Date: Wed, 6 Aug 2008 23:09:16 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Thread-Index: Acjztl9VwpF8Jw4hQhGyKIB3iAEo2QEiVE8Q From: "Bardalai, Snigdho" To: "Dan Li" , "Ccamp (E-mail)" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F843.5BB78328 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan, =20 Please see my response below. =20 Thanks, Snigdho -----Original Message----- From: Dan Li [mailto:danli@huawei.com] Sent: Friday, August 01, 2008 4:10 AM To: Bardalai, Snigdho; Ccamp (E-mail) Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Snigdho, =20 Very good question! See my comments below. =20 Thanks, =20 Dan ----- Original Message -----=20 From: Bardalai, Snigdho =20 To: Ccamp (E-mail) =20 Sent: Friday, August 01, 2008 4:26 AM Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Adrian and Dan,=20 I have the following comments on this draft. I was wondering what were = the objectives for the IGP evaluation. IMHO the evaluation from WSON = perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for = WSON=20 [Dan] With the situation that TE information is already be carried by = IGP, it's nature to think that the wavelength information can also be = carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP = for this purpose ?=20 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation = takes place is it possible to limit LSA advertisements from PCC to PCE = neighbors, instead of to every PCC neighbor? 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? = Ex. using the OSPF "do not age" concept? 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount = of data will be sent to the restarting node. We may consider the point = to point data exchange instead of flooding the LSA updates. Or slice the = big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see = if there is a clean solution. Could you please let me know if the above is within the current scope? I = believe that these are important.=20 Thanks,=20 Snigdho=20 ------_=_NextPart_001_01C8F843.5BB78328 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi=20 Dan,
 
Please=20 see my response below.
 
Thanks,
Snigdho
-----Original Message-----
From: Dan Li=20 [mailto:danli@huawei.com]
Sent: Friday, August 01, 2008 4:10 = AM
To: Bardalai, Snigdho; Ccamp (E-mail)
Subject: = Re:=20 Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Snigdho,
 
Very good question! See my comments below.
 
Thanks,
 
Dan
----- Original Message -----
From:=20 Bardalai, = Snigdho
Sent: Friday, August 01, 2008 = 4:26=20 AM
Subject: Comments on=20 "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Adrian and Dan,

I have the following comments on this = draft. I=20 was wondering what were the objectives for the IGP evaluation. IMHO = the=20 evaluation from WSON perspective should address the = following:

1. IGP usage in the context of = traditional=20 distributed solutions for WSON

[Dan] With the situation = that TE=20 information is already be carried by IGP, it's nature to think that = the=20 wavelength information can also be carried by IGP. I am not saying = it should=20 be, but it's worth to look at.
[Bardalai, Snigdho] Do you see=20 any particular issues with using the IGP for this purpose=20 ? 


2. = IGP usage in the=20 context of PCE solutions for WSON

[Dan] = It's a potential=20 way for PCE to get the wavelength information.
[Bardalai, = Snigdho] Since=20 the PCE is the location where path-computation takes place is it = possible to=20 limit LSA advertisements from PCC to PCE neighbors, instead of to = every PCC=20 neighbor?


3. = Flooding and=20 refresh of static and dynamic link state updates

[Dan] Try to figure out the = impact to=20 the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit = refreshing of=20 static LSA? Ex. using the OSPF "do not age"=20 concept?


4. Data base sync-up during node = restarts

[Dan] Yes, this should be=20 considered. Especially the very large = amount of=20 data will be sent to the restarting node. We may consider the point = to point=20 data exchange instead of flooding the LSA updates. Or slice the big = data=20 packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I = would be=20 interested to see if there is a clean=20 solution.

Could you please let me know if the = above is=20 within the current scope? I believe that these are important. =

Thanks,
Snigdho=20





------_=_NextPart_001_01C8F843.5BB78328-- From owner-ccamp@ops.ietf.org Thu Aug 7 00:26:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD4E3A67A3 for ; Thu, 7 Aug 2008 00:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 JcdzzpwtH8ev for ; Thu, 7 Aug 2008 00:26:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C91243A683B for ; Thu, 7 Aug 2008 00:26:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQzo4-0006vU-GH for ccamp-data@psg.com; Thu, 07 Aug 2008 07:21:08 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQzo0-0006uy-TW for ccamp@ops.ietf.org; Thu, 07 Aug 2008 07:21:06 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F3C2F2024B for ; Thu, 7 Aug 2008 09:21:02 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-6d-489aa25e413e Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E6FEA20D18 for ; Thu, 7 Aug 2008 09:21:02 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:21:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:19:15 +0200 Message-ID: In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQQ2caLEhnPbRJGPPSMvKLLMfABRNrtQ From: "Daniele Ceccarelli" To: X-OriginalArrivalTime: 07 Aug 2008 07:21:02.0446 (UTC) FILETIME=[25C6D0E0:01C8F85E] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I am in favor of this document being adopted. Cheers, Daniele -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Sent: marted=EC 5 agosto 2008 18.24 To: ccamp@ops.ietf.org Subject: Poll for RWA Info model as WG I-D Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed to=20 be pretty mature. Note that despite the file name, the content of this document is = consistent=20 with its title: "Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks." That is, the scope is limited to = the=20 information model for RWA. Can we have your opinion, please, on whether this document is ready to = be=20 adopted as a working group I-D. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Thu Aug 7 00:40:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923D83A6942 for ; Thu, 7 Aug 2008 00:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 5ffFXuLtbW1K for ; Thu, 7 Aug 2008 00:40:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2FB73A6872 for ; Thu, 7 Aug 2008 00:40:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR01h-0008E6-JW for ccamp-data@psg.com; Thu, 07 Aug 2008 07:35:13 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR01d-0008DY-QI for ccamp@ops.ietf.org; Thu, 07 Aug 2008 07:35:11 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:35:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:35:04 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C595A5@ftrdmel2> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GSqnGDEdvJJ9Q+KhIJRfVyBxhwBRnHVQ References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> From: To: , X-OriginalArrivalTime: 07 Aug 2008 07:35:05.0379 (UTC) FILETIME=[1C342F30:01C8F860] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi. In favor of WG topic. Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed to=20 be pretty mature. Note that despite the file name, the content of this document is = consistent=20 with its title: "Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks." That is, the scope is limited to = the=20 information model for RWA. Can we have your opinion, please, on whether this document is ready to = be=20 adopted as a working group I-D. Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Thu Aug 7 04:13:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FF23A6900 for ; Thu, 7 Aug 2008 04:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] 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 qFdaJluYUA3m for ; Thu, 7 Aug 2008 04:13:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E0593A67ED for ; Thu, 7 Aug 2008 04:13:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR3LZ-0000gt-E0 for ccamp-data@psg.com; Thu, 07 Aug 2008 11:07:57 +0000 Received: from [129.60.39.148] (helo=tama500.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR3LV-0000gX-QH for ccamp@ops.ietf.org; Thu, 07 Aug 2008 11:07:55 +0000 Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m77B6umI008785; Thu, 7 Aug 2008 20:06:56 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 98D4465FE; Thu, 7 Aug 2008 20:06:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9106065FD; Thu, 7 Aug 2008 20:06:56 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m77B6uX1008087; Thu, 7 Aug 2008 20:06:56 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (ipc0.m.ecl.ntt.co.jp [129.60.5.156]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m77B6tTX008084; Thu, 7 Aug 2008 20:06:55 +0900 (JST) Received: from [127.0.0.1] (neba-hp-shiomoto.nslab.ecl.ntt.co.jp [129.60.80.23]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m77B6pI8011591; Thu, 7 Aug 2008 20:06:55 +0900 (JST) Message-ID: <489AD6A6.4070604@lab.ntt.co.jp> Date: Thu, 07 Aug 2008 20:04:06 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes. I agree that the draft is ready to be adopted as a working group I-D. Kohei Adrian Farrel ă•ă‚“ă¯æ›¸ăă¾ă—ăŸ: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > From owner-ccamp@ops.ietf.org Fri Aug 8 07:35:45 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C743A6CE2 for ; Fri, 8 Aug 2008 07:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 YLii-6IFIKhJ for ; Fri, 8 Aug 2008 07:35:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5029D3A6D64 for ; Fri, 8 Aug 2008 07:35:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSyv-000P89-Ax for ccamp-data@psg.com; Fri, 08 Aug 2008 14:30:17 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSyh-000P5g-FG for ccamp@ops.ietf.org; Fri, 08 Aug 2008 14:30:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id BF6EE28C195; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Aug 8 07:37:21 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920413A6802 for ; Fri, 8 Aug 2008 07:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sLGlo19IIv-O for ; Fri, 8 Aug 2008 07:37:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CC8728C1B2 for ; Fri, 8 Aug 2008 07:36:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSym-000P7K-C7 for ccamp-data@psg.com; Fri, 08 Aug 2008 14:30:08 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSyh-000P5h-FG for ccamp@ops.ietf.org; Fri, 08 Aug 2008 14:30:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C245D28C198; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.C245D28C198@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-01.txt Pages : 11 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072257.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Aug 8 07:38:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B7F28C1D5 for ; Fri, 8 Aug 2008 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 2KvKLbEC-OAH for ; Fri, 8 Aug 2008 07:38:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 929DA28C1AD for ; Fri, 8 Aug 2008 07:38:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRT2t-000PdM-EG for ccamp-data@psg.com; Fri, 08 Aug 2008 14:34:23 +0000 Received: from [216.82.245.3] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRT2p-000Pcf-R8 for ccamp@ops.ietf.org; Fri, 08 Aug 2008 14:34:21 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1218206057!3698052!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 653 invoked from network); 8 Aug 2008 14:34:17 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 8 Aug 2008 14:34:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m78EYHZU017818 for ; Fri, 8 Aug 2008 10:34:17 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m78EYEeG017783 for ; Fri, 8 Aug 2008 10:34:14 -0400 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_01C8F963.D441DBD9" Subject: IETF 72 Draft CCAMP Minutes Date: Fri, 8 Aug 2008 10:34:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 72 Draft CCAMP Minutes Thread-Index: Acj5Y9P1zDI7wLBFT1aYNi7bXeS4pQ== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F963.D441DBD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's the draft meeting minutes - please take a look and mail the chairs if there are changes (or additions/corrections on the names for folks at the mike): http://www.ietf.org/proceedings/08jul/minutes/ccamp.htm =20 Much thanks to our minute takers - Dan King, Dave Walters, and Wouter Tavernier! =20 Adrian and Deborah =20 ------_=_NextPart_001_01C8F963.D441DBD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here's = the draft=20 meeting minutes - please take a look and mail the chairs if there are = changes=20 (or additions/corrections on the names for folks at the=20 mike):
http://w= ww.ietf.org/proceedings/08jul/minutes/ccamp.htm
 
Much = thanks to our=20 minute takers - Dan King, Dave Walters, and Wouter=20 Tavernier!
 
Adrian = and=20 Deborah
 
------_=_NextPart_001_01C8F963.D441DBD9-- From owner-ccamp@ops.ietf.org Fri Aug 8 08:49:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040163A6B77 for ; Fri, 8 Aug 2008 08:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=1.469, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 scvSuDmVR0CJ for ; Fri, 8 Aug 2008 08:49:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DBF23A6ACF for ; Fri, 8 Aug 2008 08:49:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRU6D-0007ef-Ox for ccamp-data@psg.com; Fri, 08 Aug 2008 15:41:53 +0000 Received: from [138.163.0.42] (helo=gate2-sandiego.nmci.navy.mil) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRU5F-0007Xx-SF for ccamp@ops.ietf.org; Fri, 08 Aug 2008 15:41:15 +0000 Received: from nawesdnieg06.nadsuswe.nads.navy.mil ([10.0.0.163]) by gate2-sandiego.nmci.navy.mil with Microsoft SMTPSVC(5.0.2195.6872); Fri, 8 Aug 2008 08:35:11 -0700 Received: from nawesdnieb10.nadsuswe.nads.navy.mil ([10.0.10.123]) by nawesdnieg06.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 08:40:53 -0700 Received: from mail pickup service by nawesdnieb10.nadsuswe.nads.navy.mil with Microsoft SMTPSVC; Fri, 8 Aug 2008 08:40:51 -0700 Received: from nawesdnieg08.nadsuswe.nads.navy.mil ([10.0.10.59]) by nawesdnieb13v.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 07:36:34 -0700 Received: from navysdniio02.nmci.navy.mil ([10.0.0.43]) by nawesdnieg08.nadsuswe.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Aug 2008 07:36:01 -0700 X-Brightmail-Tracker: AAAAAA== X-BrightmailFiltered: true Received: from mx1.spawar.navy.mil ([198.253.50.6]) by navysdniii02.nmci.navy.mil with ESMTP; 08 Aug 2008 07:36:01 -0700 Received: from mail.ietf.org ([IPv6:2001:1890:1112:1::20]) by mx1.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id m78EZNJd020937; Fri, 8 Aug 2008 07:35:28 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB1D28C1D2; Fri, 8 Aug 2008 07:30:05 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF6EE28C195; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-3.0 (mx1.spawar.navy.mil [IPv6:2001:480:10:1050::6]); Fri, 08 Aug 2008 07:35:29 -0700 (PDT) X-SPAWAR-MailScanner-Information: Please contact the Help Desk for more information X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 3.5, autolearn=disabled, ALL_TRUSTED -1.44) X-SPAWAR-MailScanner-From: i-d-announce-bounces@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt X-OriginalArrivalTime: 08 Aug 2008 14:36:01.0701 (UTC) FILETIME=[148ED550:01C8F964] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ccamp@ops.ietf.org Fri Aug 8 10:35:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11BA3A6924 for ; Fri, 8 Aug 2008 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 9tbRpKN-Gs96 for ; Fri, 8 Aug 2008 10:35:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0DBE3A6CF7 for ; Fri, 8 Aug 2008 10:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRVnO-000KJM-Hn for ccamp-data@psg.com; Fri, 08 Aug 2008 17:30:34 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRVmt-000KFe-Fk for ccamp@ops.ietf.org; Fri, 08 Aug 2008 17:30:05 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id AC8423A6CD3; Fri, 8 Aug 2008 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808173001.AC8423A6CD3@core3.amsl.com> Date: Fri, 8 Aug 2008 10:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Pages : 11 Date : 2008-08-08 This document describes two technology independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08102841.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Aug 11 09:33:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9EF3A6C06 for ; Mon, 11 Aug 2008 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 PQFWvlukUtAj for ; Mon, 11 Aug 2008 09:33:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 852043A6C29 for ; Mon, 11 Aug 2008 09:33:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaBg-0000a0-N3 for ccamp-data@psg.com; Mon, 11 Aug 2008 16:24:04 +0000 Received: from [119.145.14.66] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaAZ-0000Lh-B2 for ccamp@ops.ietf.org; Mon, 11 Aug 2008 16:23:03 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5E007GSYDPZW@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5E000AQYDPJ6@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:01 +0800 (CST) Received: from l37133 ([10.70.77.57]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5E00ED8YDP8H@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:01 +0800 (CST) Date: Mon, 11 Aug 2008 09:48:59 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" , "Ccamp (E-mail)" Message-id: <003c01c8fb54$6c656c70$394d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, I copied the original text here for easy read. See my comments below. ===== Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. Could you please let me know if the above is within the current scope? I believe that these are important. Thanks, Snigdho --Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,

I copied the original text here for easy read. See my comments below.
=====
Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.

Could you please let me know if the above is within the current scope? I believe that these are important.
Thanks,
Snigdho
--Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)-- From owner-ccamp@ops.ietf.org Mon Aug 11 10:29:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4214B3A6D0B for ; Mon, 11 Aug 2008 10:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=-1.590, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_NONE=0.1] 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 OgtDhlhAW-IX for ; Mon, 11 Aug 2008 10:29:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F171F3A6CEB for ; Mon, 11 Aug 2008 10:29:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSb8h-000B1o-9C for ccamp-data@psg.com; Mon, 11 Aug 2008 17:25:03 +0000 Received: from [62.128.193.155] (helo=mta5.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSb8c-000B0c-W6 for ccamp@ops.ietf.org; Mon, 11 Aug 2008 17:25:01 +0000 Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7BHOo2q026375; Mon, 11 Aug 2008 18:24:50 +0100 Received: from webmail1.iomartmail.com (webmail1.iomartmail.com [10.12.10.215]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7BHOoX1026357; Mon, 11 Aug 2008 18:24:50 +0100 Message-Id: <200808111724.m7BHOoX1026357@mta5.iomartmail.com> Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org, danli@huawei.com Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Reply-To: adrian@olddog.co.uk X-Origin: 81.140.15.32 X-Account: adrian@olddog.co.uk Date: Mon, 11 Aug 2008 18:24:50 +0100 X-Uidl: 003c01c8fb54$6c656c70$394d460a@china.huawei.com X-Mailer: AtMail 4.11 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: =0D =0D
Hi,
=0D
=0D
I have the following comments on this draft. I was wondering what were= the objectives for the IGP evaluation. IMHO the evaluation from WSON persp= ective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON <= BR> [Dan] With the situation that TE information is alrea= dy be carried by IGP, it's nature to think that the wavelength information = can also be carried by IGP. I am not saying it should be, but it's worth to= look at.
[Bardalai, Snigdho] Do you see any particular = issues with using the IGP for this purpose ?
=0D
[Dan] From the result of the simulation, th= e OSPF convergency time takes a liitle bit longer when the entire netw= ork restarts. Because the WSON information is added in the OSPF LSA.&n= bsp;During the network running normally, the update of wavelength availabil= ity information doesn't impact the IGP performance obviously.
=0D
[Adrian] Certainly, from the point of view of so= meone coming at this without an implementation (I used to have one :-)= , the concern is that adding the RWA information to the IGP might mean that= there was simply too much information to be distributed. What Dan's draft = is trying to do is show the dimensions of the information and how dyna= mic it is. From this, we can quickly see how things will scale.=0D
I do not believe that ther= e is an issue with the interaction with IP routing, but I guess we should c= onsider that it is possible that the DCN will be a real IP network carrying= other traffic and that we need to not disrupt IGP convergence in that netw= ork. Mechanisms exist (or are being developed) to make that safe, and Dan's= I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelen= gth information.
[Bardalai, Snigdho] Since the PCE is the locat= ion where path-computation takes place is it possible to limit LSA advertis= ements from PCC to PCE neighbors, instead of to every PCC neighbor?<= /DIV>=0D
[Dan] You are right, PCC which doesn't do the pa= th-computation doesn't need this kind of information.
=0D
[Adrian] This is an import= ant point which you raised in conversation with me in Dublin: it is possibl= e to consider using link-local scope flooding of RWA information from PCC t= o PCE so that it goes no further. But there is a clear trade-off... with ho= w many PCCs will a PCE be required to maintain an IGP association? There is= also a quesiton to be answered about the function required for restoration= - how much information does the head-end LSR need to perform rapid, "best-= effort" path computation to restore LSPs after a network failure? This info= rmation *does* need to be flooded. The informaiton model I-D is intended to= help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance= of IGP.
[Bardalai, Snigdho] Is it possible to limit re= freshing of static LSA? Ex. using the OSPF "do not age" concept?=0D
[Dan] Yes, it's possible to take this way to red= uce the protocol traffic. But we should consider the scenario when a node g= ets restart or goes down, so the HELLO message may still need to be kept.
=0D
[Adrian] Yes. You are both= right. We should treat "static" as truely static and not needing refresh. = We can handle node-down and link-down events without the need to time out t= he LSAs containing the static data if we link the behavior to the time-out = of other node/link information. But we *do* need to consider the amount of = information that will be held in LSA DBs and need to be flooded at start of= day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the = very large amount of data will be sent to the restarting node. We may consi= der the point to point data exchange instead of flooding the LSA updates. O= r slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I w= ould be interested to see if there is a clean solution.
=0D
[Adrian] An important point to consider (in OSPF= ) is what happens in a lossy environment if the LSA gets very large. In thi= s case it will be fragmented into very many IP packets and there will be a = good statistical likelihood of at least one packet being lost. That means t= hat the LSA might never get delivered whiled the DCN will get hammered. One= solution (thanks, Igor) is to break the information down into smaller LSAs= . Since the information is essentially lists or matrices, this is quite eas= y to do.
=0D

Could you please let me know if the above is within the current scop= e? I believe that these are important.
[Adrian] Very much in scope!
=0D
 
=0D
Cheers,
=0D
Adrian
=0D =0D
From owner-ccamp@ops.ietf.org Mon Aug 11 10:42:16 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0741D3A6CCA for ; Mon, 11 Aug 2008 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 a-weyzfhDCUj for ; Mon, 11 Aug 2008 10:42:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B3233A6A12 for ; Mon, 11 Aug 2008 10:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbKL-000CVQ-Ru for ccamp-data@psg.com; Mon, 11 Aug 2008 17:37:05 +0000 Received: from [194.192.15.188] (helo=dkcphmx24.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbKH-000CUi-NT for ccamp@ops.ietf.org; Mon, 11 Aug 2008 17:37:04 +0000 Received: (qmail 30812 invoked by uid 74); 11 Aug 2008 12:10:19 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1218456619.544580.29564 (Processed in 0.155424 secs); 11 Aug 2008 12:10:19 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with ESMTP; Mon, 11 Aug 2008 14:10:19 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Mon, 11 Aug 2008 14:10:19 +0200 From: Anders Gavler To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Mon, 11 Aug 2008 14:10:18 +0200 Subject: RE: Poll for RWA Info model as WG I-D Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GcsKP1xvGVaFTj6vtGImL2XKXAEkWXsA Message-ID: <73B74934786FBB4F951B5F99724CEB601D43B6A3C1@acreoexc01.ad.acreo.se> References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> In-Reply-To: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes. Regards, Anders > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behal= f > Of Adrian Farrel > Sent: den 5 augusti 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed > to > be pretty mature. > > Note that despite the file name, the content of this document is > consistent > with its title: "Routing and Wavelength Assignment Information Model for > Wavelength Switched Optical Networks." That is, the scope is limited to > the > information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > From owner-ccamp@ops.ietf.org Mon Aug 11 10:47:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AAB3A6A43 for ; Mon, 11 Aug 2008 10:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 8c0s+B4Nx+dY for ; Mon, 11 Aug 2008 10:47:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C4EB3A67EF for ; Mon, 11 Aug 2008 10:47:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbPh-000DEC-HO for ccamp-data@psg.com; Mon, 11 Aug 2008 17:42:37 +0000 Received: from [119.145.14.64] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbPb-000DCh-Oy for ccamp@ops.ietf.org; Mon, 11 Aug 2008 17:42:35 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5F00LX5EB4NG@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 15:33:04 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5F004JAEB43K@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 15:33:04 +0800 (CST) Received: from l37133 ([10.70.77.57]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5F00BVHEB4MO@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 15:33:04 +0800 (CST) Date: Mon, 11 Aug 2008 15:33:01 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" Cc: "Ccamp (E-mail)" Message-id: <00d701c8fb84$7c2f2b20$394d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, I copied the original text here for easy read. See my comments below. ===== Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. ===== Thanks, Dan --Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,

I copied the original text here for easy read. See my comments below.
=====
Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
=====

Thanks,
 
Dan
--Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)-- From owner-ccamp@ops.ietf.org Mon Aug 11 13:32:40 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442C93A6CA2 for ; Mon, 11 Aug 2008 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 y6uRCwLqZv8O for ; Mon, 11 Aug 2008 13:32:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5858C3A68B1 for ; Mon, 11 Aug 2008 13:32:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdxZ-0004rD-4u for ccamp-data@psg.com; Mon, 11 Aug 2008 20:25:45 +0000 Received: from [209.191.85.54] (helo=web36803.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdxT-0004qR-Vx for ccamp@ops.ietf.org; Mon, 11 Aug 2008 20:25:42 +0000 Received: (qmail 83470 invoked by uid 60001); 11 Aug 2008 20:25:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=D1RtXxhE9YF7aoPoxjy/3xv2o0bcTJpjf2daOWEfxP5ofGiAIKCDSqMfz5RU/HaA1f9Xh7wnYqTopgQRwj3AwSqJZU0U72rlR59+bkKYGugxYQQKbw3C4m4f2bWW2/X4OLh0mTb8N4RCLw3kvdY7aBZAusZ9Q+bYVz8jovCBfFM=; Received: from [67.102.145.11] by web36803.mail.mud.yahoo.com via HTTP; Mon, 11 Aug 2008 13:25:39 PDT X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218 Date: Mon, 11 Aug 2008 13:25:39 -0700 (PDT) From: Igor Bryskin Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org, danli@huawei.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2020219236-1218486339=:64307" Message-ID: <226870.64307.qm@web36803.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-2020219236-1218486339=:64307 Content-Type: text/plain; charset=us-ascii Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --0-2020219236-1218486339=:64307 Content-Type: text/html; charset=us-ascii
Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian


--0-2020219236-1218486339=:64307-- From owner-ccamp@ops.ietf.org Tue Aug 12 01:45:21 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CA83A6924 for ; Tue, 12 Aug 2008 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.209 X-Spam-Level: X-Spam-Status: No, score=-100.209 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 MfAl012Qflgq for ; Tue, 12 Aug 2008 01:45:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0BA33A69C2 for ; Tue, 12 Aug 2008 01:45:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpOQ-000Ko9-GP for ccamp-data@psg.com; Tue, 12 Aug 2008 08:38:14 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpNi-000KWl-H5 for ccamp@ops.ietf.org; Tue, 12 Aug 2008 08:37:33 +0000 Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm448a17105; Tue, 12 Aug 2008 16:52:56 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm77489c9dcd; Fri, 08 Aug 2008 22:52:07 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 08 Aug 2008 22:52:07 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C2828C1DE; Fri, 8 Aug 2008 07:30:06 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C245D28C198; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.C245D28C198@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-01.txt Pages : 11 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072257.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ccamp@ops.ietf.org Tue Aug 12 02:01:50 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678983A69EA for ; Tue, 12 Aug 2008 02:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.137 tagged_above=-999 required=5 tests=[AWL=-1.785, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, 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 zNGvemWS4OUV for ; Tue, 12 Aug 2008 02:01:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B41A3A6937 for ; Tue, 12 Aug 2008 02:01:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpch-000NFg-Rt for ccamp-data@psg.com; Tue, 12 Aug 2008 08:52:59 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpcd-000NEz-NO for ccamp@ops.ietf.org; Tue, 12 Aug 2008 08:52:57 +0000 Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm048a159e1; Tue, 12 Aug 2008 17:08:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17489c9ee4; Fri, 08 Aug 2008 23:07:30 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 08 Aug 2008 23:07:30 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9891928C1D1; Fri, 8 Aug 2008 07:30:05 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF6EE28C195; Fri, 8 Aug 2008 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ccamp@ops.ietf.org Tue Aug 12 10:07:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350723A67FE for ; Tue, 12 Aug 2008 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] 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 NORXYdAiQi26 for ; Tue, 12 Aug 2008 10:07:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 613943A6818 for ; Tue, 12 Aug 2008 10:07:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxEL-000ML1-4B for ccamp-data@psg.com; Tue, 12 Aug 2008 17:00:21 +0000 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxED-000MJz-Fq for ccamp@ops.ietf.org; Tue, 12 Aug 2008 17:00:18 +0000 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 18:00:10 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Aug 2008 16:59:52 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 12 Aug 2008 17:59:47 +0100 Subject: Re: [mpls-tp] MPLS over OTN From: Ben Niven-Jenkins To: , , CC: , Message-ID: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RzhHZYPvGZHKQvSW9uyhF8h+KQAAEiUwAZVUm78= In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02605C591F9@ftrdmel2> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Aug 2008 17:00:10.0635 (UTC) FILETIME=[E1606DB0:01C8FC9C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Catching up on mails... On 04/08/2008 16:48, "julien.meuric@orange-ftgroup.com" wrote: > Hi Francesco. > > I guess I understand your concern. I believe the original intention was > to say implicitely "It MUST be possible to operate and configure the > MPLS-TP data (transport) plane without any IP functionality *in the data > plane*." My interpretation of these requirements is indeed that they > apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment, > nor the MPLS-TP control plane... Correct. > Anyway you're right, this could be confusing and it deserves a small > rewording. I have reworded to: "It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality in the MPLS-TP data plane." Ben From owner-ccamp@ops.ietf.org Wed Aug 13 02:10:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E49D3A6B89 for ; Wed, 13 Aug 2008 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 4-es9NAlfjeM for ; Wed, 13 Aug 2008 02:10:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFEA33A6B7F for ; Wed, 13 Aug 2008 02:10:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTCGL-0002Ve-4d for ccamp-data@psg.com; Wed, 13 Aug 2008 09:03:25 +0000 Received: from [62.128.193.154] (helo=mta4.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTCGH-0002VB-Dm for ccamp@ops.ietf.org; Wed, 13 Aug 2008 09:03:23 +0000 Received: from mta4.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta4.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7D92IxJ030308; Wed, 13 Aug 2008 10:02:20 +0100 Received: from webmail1.iomartmail.com (webmail1.iomartmail.com [10.12.10.215]) (authenticated bits=0) by mta4.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7D929Xi030025; Wed, 13 Aug 2008 10:02:16 +0100 Message-Id: <200808130902.m7D929Xi030025@mta4.iomartmail.com> Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: Adrian Farrel To: ccamp@ops.ietf.org Subject: BGP TE attr last call by softwires WG Reply-To: adrian@olddog.co.uk X-Origin: 81.140.15.32 X-Account: adrian@olddog.co.uk Date: Wed, 13 Aug 2008 10:02:08 +0100 Cc: dward@cisco.com, alain_durand@cable.comcast.com, softwires@ietf.org X-Uidl: 1218618128106401484 X-Mailer: AtMail 4.11 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: [Forwarding to the correct CCAMP mailing address]=0D =0D From: David Ward =0D To: David Ward , =0D Alain Durand , softwires@ietf.org =0D Sent: Tue Aug 12 23:48 =0D Subject: BGP TE attr last call by softwires WG =0D =0D The softwire WG has LC'ed =0D =0D http://www.ietf.org/internet-drafts/draft-ietf-softwire-bgp-te- =0D attribute-01.txt =0D =0D We will keep open an additional two-week period for wider review =0D before moving forward in the publication process. Please have any =0D comments to the authors and softwires WG by Aug 26, 2008. =0D =0D -DWard, Alain Durand =0D =0D bcc: l1vpn@ietf.org, ccamp@ietf.org, mpls@ietf.org, idr@ietf.org, =0D isis-wg@ietf.org, l3vpn@ietf.org, ospf@ietf.org =0D From owner-ccamp@ops.ietf.org Thu Aug 14 23:06:30 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F67B3A6BB7 for ; Thu, 14 Aug 2008 23:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 PKH+4686uAo7 for ; Thu, 14 Aug 2008 23:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B26B3A6359 for ; Thu, 14 Aug 2008 23:06:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTsHM-0008bX-Do for ccamp-data@psg.com; Fri, 15 Aug 2008 05:55:16 +0000 Received: from [119.145.14.64] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTsHG-0008b5-Mg for ccamp@ops.ietf.org; Fri, 15 Aug 2008 05:55:14 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5M00C1SOFW5G@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 15 Aug 2008 13:55:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5M00C0POFW66@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 15 Aug 2008 13:55:08 +0800 (CST) Received: from l37133 ([10.70.77.57]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5M001G6OFWZZ@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Fri, 15 Aug 2008 13:55:08 +0800 (CST) Date: Fri, 15 Aug 2008 13:55:04 +0800 From: Dan Li Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: Igor Bryskin , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <00d601c8fe9b$77003f30$394d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)" X-Priority: 3 X-MSMail-priority: Normal References: <226870.64307.qm@web36803.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian


--Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)-- From asamblea06082008@gmail.com Fri Aug 15 01:57:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F923A69DF for ; Fri, 15 Aug 2008 01:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.578 X-Spam-Level: **** X-Spam-Status: No, score=4.578 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] 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 vZH7MQzC9glQ for ; Fri, 15 Aug 2008 01:57:54 -0700 (PDT) Received: from avas-mr16.fibertel.com.ar (avas-mr16.fibertel.com.ar [24.232.0.248]) by core3.amsl.com (Postfix) with ESMTP id A09163A67DF for ; Fri, 15 Aug 2008 01:57:53 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:3346 "EHLO coloso" smtp-auth: "asamblea06082008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr16.fibertel.com.ar with ESMTPA id S833063AbYHOI5E convert rfc822-to-8bit; Fri, 15 Aug 2008 05:57:04 -0300 Message-ID: <3822-22008851585554603@coloso> To: "notebooks" Errors-to: asamblea06082008_@gmail.com From: "asamblea06082008@gmail.com" Subject: NOTEBOOKS EN TODOS LOS PRECIOS Date: Fri, 15 Aug 2008 05:55:54 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 244049e8fb984d0004dbfd89ecca793d X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea06082008@gmail.com NOTEBOOKS con GARANTIA, ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B CEL: 15-3197-5821 EMail: asamblea060872008@gmail.com ASUS ASUS EEE PC 701 ASUS EEE PC 701 Pesa 900 gramos 7" ideal $ 1.419,00 BANGHO CS1406CC BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO CS1406CC-S BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO DS1406CB BanghóMov DS1406CB Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.499,00 BANGHO DS1406CB-H BanghóMov DS1406CB-H Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.599,00 BANGHO CS1501CB BanghóMov BQ1501CB Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.599,00 BANGHO CS1501CB-H BanghóMov BQ1501CB-H Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.699,00 HEWLETT PACKARD 530 T2600 DOS Procesador Core Duo T2600 HDD 120GB 1GB DDR2 667 15,4'' WI-FI $ 2.799,00 BANGHO DS1501CF BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.499,00 BANGHO CS1202CF-H BanghóMov CS1221C Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.599,00 BANGHO CS1202CF-H BanghóMov CS1202CF-H Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.799,00 BANGHO DS1501CF-P BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.799,00 BANGHO DS1205CF-P BanghóMov DS1205C-P Intel Core 2 Duo T5450 2GB DDR2 667 HDD 120GB $ 4.499,00 From owner-ccamp@ops.ietf.org Fri Aug 15 06:51:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B820A3A6ADA for ; Fri, 15 Aug 2008 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 ujZNo1l83vJb for ; Fri, 15 Aug 2008 06:51:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B58813A6DC9 for ; Fri, 15 Aug 2008 06:51:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTzay-000JUl-D5 for ccamp-data@psg.com; Fri, 15 Aug 2008 13:44:00 +0000 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTzau-000JU5-2F for ccamp@ops.ietf.org; Fri, 15 Aug 2008 13:43:58 +0000 Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Aug 2008 14:43:54 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Aug 2008 13:43:23 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 15 Aug 2008 14:43:22 +0100 Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) From: Ben Niven-Jenkins To: Maarten Vissers , , 'Adrian Farrel' CC: , , 'Italo Busi' Message-ID: Thread-Topic: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Thread-Index: Acj7qj3OFgdIw17KRmq76189Mj92hACuhA3QAB4lB9g= In-Reply-To: <007701c8fe65$4e226c90$fd4c2f0a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Aug 2008 13:43:54.0368 (UTC) FILETIME=[F569F000:01C8FEDC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Maarten, I agree that OSI is still present in many transport network elements and therefore DCN support for OSI will be required for some DCNs. However, does this lead to a requirement that MPLS-TP equipment *must* support OSI? Modern transport gear also supports IP for DCN and this is the direction many operators are choosing to move. So it would appear to me that the requirements placed on DCN design in general are different to the requirements placed on the transport equipment itself (which will be controlled via the DCN). Let me use BT's transmission DCN as an example - we have a significant sized DCN consisting of several thousand routers/switches (just for the transmission DCN itself). It supports both OSI and IP. Therefore we are able to accommodate new transport equipment control via IP while maintaining control of old transport equipment via OSI. Ben On 15/08/2008 00:27, "Maarten Vissers" wrote: > Do routers today only support IPv6, or are there still many of the older > protocols supported? I assume it is the latter case, as it is difficult to > switch off support for older protocols as long as its original equipment is > still present at some places in the network. I.e. wouldn't it be in the long > term economic interest of the customer to migrate to IPv6 only? When do you > think you can switch of support for IPv4 and older protocols in the routers? > > With OSI in the DCN we have a similar situation. It is still present in many > network elements and must as such be supported within the existing and > future DCN. > > Regards, > Maarten > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 11 August 2008 13:52 > To: Adrian Farrel > Cc: Maarten Vissers; 'Diego Caviglia'; 'Italo Busi'; 'Francesco Fondelli'; > julien.meuric@orange-ftgroup.com; ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) > > These control channels are the last vestige of OSI in modern networks (apart > from ISIS which is alive and well). Surely it is in the long term economic > interests of the customer (infrastructure equipment costs, training, > commonality etc) to migrate to IP? > > Stewart >> > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From owner-ccamp@ops.ietf.org Fri Aug 15 08:23:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4621F3A6B4E for ; Fri, 15 Aug 2008 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 EVXZW6JusQPz for ; Fri, 15 Aug 2008 08:23:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7306C3A6B39 for ; Fri, 15 Aug 2008 08:23:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU128-000CkS-Sm for ccamp-data@psg.com; Fri, 15 Aug 2008 15:16:08 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KU121-000CjY-OU for ccamp@ops.ietf.org; Fri, 15 Aug 2008 15:16:03 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3876320379; Fri, 15 Aug 2008 17:15:59 +0200 (CEST) X-AuditID: c1b4fb3e-aa688bb000007a96-10-48a59dafd1b6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 121782001D; Fri, 15 Aug 2008 17:15:59 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Aug 2008 17:15:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Date: Fri, 15 Aug 2008 17:15:58 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684EEAF81@esealmw110.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Thread-Index: Acj+6dISuH7s3gxgSGqiSexIJF2/QQ== From: "Diego Caviglia" To: Cc: , , "Diego Caviglia" , , , , , X-OriginalArrivalTime: 15 Aug 2008 15:15:58.0789 (UTC) FILETIME=[D239AF50:01C8FEE9] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Stewart, I think i agree here. Even if i'm coming from sdh i don'e see the need to hane osi capability in brand new mpls-tp boxes. Br Diego From owner-ccamp@ops.ietf.org Mon Aug 18 08:24:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300AA3A69AC for ; Mon, 18 Aug 2008 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 Gn+FeoPMIhLx for ; Mon, 18 Aug 2008 08:24:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E418D3A67AB for ; Mon, 18 Aug 2008 08:24:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6SC-000OeE-S0 for ccamp-data@psg.com; Mon, 18 Aug 2008 15:15:32 +0000 Received: from [209.191.85.52] (helo=web36801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6S7-000Od6-58 for ccamp@ops.ietf.org; Mon, 18 Aug 2008 15:15:29 +0000 Received: (qmail 52109 invoked by uid 60001); 18 Aug 2008 15:15:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=k5A9ruuiDkj8x3xSvbXZ3MdcpOww0MIBYrmp56+RjtvdfOQh2i1mFpXOa5P2ikuWRZ4FHppxATRqCBNYEEi2k2C4RvYEUm9WRYdYhyP3V4mzHGo3QzdrZV67O6QsqlBl5NHaCQLXMGZJwrtszuaiO4IgyCVtXAFeTxqNaiQmXI0=; Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Mon, 18 Aug 2008 08:15:26 PDT X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218 Date: Mon, 18 Aug 2008 08:15:26 -0700 (PDT) From: Igor Bryskin Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: Dan Li , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-391644484-1219072526=:51910" Message-ID: <563325.51910.qm@web36801.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-391644484-1219072526=:51910 Content-Type: text/plain; charset=us-ascii Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --0-391644484-1219072526=:51910 Content-Type: text/html; charset=us-ascii
Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <danli@huawei.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian



--0-391644484-1219072526=:51910-- From owner-ccamp@ops.ietf.org Mon Aug 18 12:51:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C28B28C1E4 for ; Mon, 18 Aug 2008 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.728 X-Spam-Level: X-Spam-Status: No, score=0.728 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 EFZN4ITfZVHP for ; Mon, 18 Aug 2008 12:51:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E4503A6780 for ; Mon, 18 Aug 2008 12:51:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVAeY-0001L6-Ow for ccamp-data@psg.com; Mon, 18 Aug 2008 19:44:34 +0000 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVAeT-0001Il-9z for ccamp@ops.ietf.org; Mon, 18 Aug 2008 19:44:31 +0000 Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 3ma11a0050lTkoCA2vkVMB; Mon, 18 Aug 2008 19:44:29 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id 3vk21a00i570qEr8Qvk4yg; Mon, 18 Aug 2008 19:44:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=Jdb67BthqH4A:10 a=8EpbRKizWpwA:10 a=b3zSeh86TFB0RtjP7BcA:9 a=Mj6O7zPJfNYMzsmjGekA:7 a=jJaz-D8VqI466NoNZIjTMaD79ukA:4 a=hPjdaMEvmhQA:10 a=rC2wZJ5BpNYA:10 a=gJcimI5xSWUA:10 a=EKcX6hdYUGDZGNDdPCIA:9 a=pbH5aUb6coFkC0WPU6IA:7 a=zgirlFMnjf_r5OR75pFK8gS06iIA:4 a=TcTp64cstOAA:10 a=AfD3MYMu9mQA:10 Reply-To: From: "Tony Li" To: "'Igor Bryskin'" , "'Dan Li'" , , , References: <563325.51910.qm@web36801.mail.mud.yahoo.com> Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Mon, 18 Aug 2008 12:43:27 -0700 Message-ID: <30CDDADB3BE248069E16208195D56458@ad.redback.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0126_01C90130.10DE6C80" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <563325.51910.qm@web36801.mail.mud.yahoo.com> Thread-Index: AckBSK952Mj6IUCkSguZjw/s3lCgxAAIS1ag Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C90130.10DE6C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Igor, Dan, Perhaps there's an important distinction to be made here. Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure. Debouncing techniques should be used to prevent any connectivity oscillations. However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time. Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale. This of course won't match many folks' requirements for 'real-time'. Tony _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin Sent: Monday, August 18, 2008 8:15 AM To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian ------=_NextPart_000_0126_01C90130.10DE6C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Igor, Dan,
 
Perhaps there's an=20 important distinction to be made here.  Typically, having an IGP = carry=20 lambda connectivity status isn't a significant issue, as that = should=20 only change when there is a significant failure.  Debouncing = techniques=20 should be used to prevent any connectivity=20 oscillations.
 
However, carrying lambda utilization status = in the IGP=20 is not going to prove practical, as the continued series of updates = would easily=20 lead to IGP thrash if done at anything approaching real-time.  Note = that=20 carrying utlization on a low-frequency basis (e.g., cycle time of 1 = minute) is=20 probably not an issue for networks of reasonable scale.  This of = course=20 won't match many folks' requirements for = 'real-time'.
 
Tony
 

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor=20 Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: = Dan Li;=20 adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com;=20 ccamp@ops.ietf.org
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Dan,

That's the point. How does PCE maintain the lambda=20 availability status? PCE architecture shyly puts this problem out of = its=20 scope, but the only known way today for the PCE is to participate in = one or=20 more IGP-TEor BGP-TE routing protocols. So, in this respect it does = not matter=20 whether paths are computed locally or via PCE = service.

Igor

-----=20 Original Message ----
From: Dan Li <danli@huawei.com>
To: = Igor=20 Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk;=20 Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, = August=20 15, 2008 1:55:04 AM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE = link lambda=20 available status should be precise and real time updated. If we do the = path=20 computation in distribute way, this would be a big problem because of = the TE=20 link lambda available status may not be updated right away. But we can = do it=20 in centralized way to minimized this problem. For example, using PCE = and if=20 the PCE can maintain the TE link lambda available status, this may not = be a=20 problem because all the path computation requests are in the queue of = PCE, and=20 PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
From:=20 Igor = Bryskin
To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fu= jitsu.com=20 ; ccamp@ops.ietf.org ; danli@huawei.com
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for=20 IB>>

Cheers,
Igor

-----=20 Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To:= Snigdho.Bardalai@us.fu= jitsu.com;=20 ccamp@ops.ietf.org; danli@huawei.com
Sent: = Monday,=20 August 11, 2008 1:24:50 PM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering = what=20 were the objectives for the IGP evaluation. IMHO the evaluation = from WSON=20 perspective should address the following:
1. IGP usage in the = context=20 of traditional distributed solutions for WSON
[Dan] With the situation that TE information is = already be=20 carried by IGP, it's nature to think that the wavelength = information can=20 also be carried by IGP. I am not saying it should be, but it's = worth to=20 look at.

IB>> There is an important difference in=20 requirements for advertising of TE link information vs. = advertising TE=20 link lambda availability. When OSPF TE speaker advertises TE link = info it,=20 apart from link statical information, is pretty much saying : "I = have 70%=20 of bandwdith availbale on priority p". For the path computer (say, = PCE) it=20 is almost always not important if the link has actually 75%, 70% = or 60% of=20 available bandwidth. However, lambda availability (like pregnancy) = is=20 boolen: either it is there ot it is not. PCE which perfoms path=20 computation in terms of lambdas, unfortunately. must have almost=20 momentarily lambda availability states. With the speed of TE info = flooding=20 current IGP-TE protocols have to offer, such mechanism will not = work on=20 dynamic networks. And in any case one can never rely on PCE during = recovery path computations. These limitations. I think, should be = clearly=20 stated in the document.

[Bardalai,=20 Snigdho] Do you see any particular issues with using the IGP for = this=20 purpose ?
[Dan] From the result of the = simulation, the=20 OSPF convergency time takes a liitle bit longer when the = entire=20 network restarts. Because the WSON information is added in = the OSPF=20 LSA. During the network running normally, the update of = wavelength=20 availability information doesn't impact the IGP = performance=20 obviously.
[Adrian] Certainly, from the point of = view of=20 someone coming at this without an implementation (I used to = have one=20 :-), the concern is that adding the RWA information to the IGP = might mean=20 that there was simply too much information to be distributed. What = Dan's=20 draft is trying to do is show the dimensions of the information=20 and how dynamic it is. From this, we can quickly see how = things will=20 scale.
I do not believe = that there=20 is an issue with the interaction with IP routing, but I guess we = should=20 consider that it is possible that the DCN will be a real IP = network=20 carrying other traffic and that we need to not disrupt IGP = convergence in=20 that network. Mechanisms exist (or are being developed) to make = that safe,=20 and Dan's I-D should be able to tell us how important it is to use = them.
 
2. IGP usage in the context of = PCE=20 solutions for WSON
[Dan] It's a potential = way for=20 PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location = where=20 path-computation takes place is it possible to limit LSA = advertisements=20 from PCC to PCE neighbors, instead of to every PCC = neighbor?
[Dan] You are right, PCC which doesn't = do the=20 path-computation doesn't need this kind of = information.
[Adrian] This is = an important=20 point which you raised in conversation with me in Dublin: it is = possible=20 to consider using link-local scope flooding of RWA information = from PCC to=20 PCE so that it goes no further. But there is a clear trade-off... = with how=20 many PCCs will a PCE be required to maintain an IGP association? = There is=20 also a quesiton to be answered about the function required for = restoration=20 - how much information does the head-end LSR need to perform = rapid,=20 "best-effort" path computation to restore LSPs after a network = failure?=20 This information *does* need to be flooded. The informaiton model = I-D is=20 intended to help with this question.

3. = Flooding and=20 refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the = performance of=20 IGP.
[Bardalai, Snigdho] Is it = possible to=20 limit refreshing of static LSA? Ex. using the OSPF "do not age"=20 concept?
[Dan] Yes, it's possible to take this = way to=20 reduce the protocol traffic. But we should consider the scenario = when a=20 node gets restart or goes down, so the HELLO message may still = need to be=20 kept.
[Adrian] Yes. You = are both=20 right. We should treat "static" as truely static and not needing = refresh.=20 We can handle node-down and link-down events without the need to = time out=20 the LSAs containing the static data if we link the behavior to the = time-out of other node/link information. But we *do* need to = consider the=20 amount of information that will be held in LSA DBs and need to be = flooded=20 at start of day and in node restart as = below.

4. Data=20 base sync-up during node restarts
[Dan] = Yes, this=20 should be considered. Especially the very large amount of data = will be=20 sent to the restarting node. We may consider the point to point = data=20 exchange instead of flooding the LSA updates. Or slice the big = data packet=20 into small pieces.
[Bardalai, = Snigdho] This=20 is little tricky, I would be interested to see if there is a clean = solution.
[Adrian] An important point to consider = (in OSPF)=20 is what happens in a lossy environment if the LSA gets very large. = In this=20 case it will be fragmented into very many IP packets and there = will be a=20 good statistical likelihood of at least one packet being lost. = That means=20 that the LSA might never get delivered whiled the DCN will get = hammered.=20 One solution (thanks, Igor) is to break the information down into = smaller=20 LSAs. Since the information is essentially lists or matrices, this = is=20 quite easy to do.

Could you please let me know = if the=20 above is within the current scope? I believe that these are = important.=20
[Adrian] Very much in = scope!
 
Cheers,
Adrian


------=_NextPart_000_0126_01C90130.10DE6C80-- From asamblea18082008@gmail.com Tue Aug 19 04:36:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11013A69E4 for ; Tue, 19 Aug 2008 04:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.578 X-Spam-Level: **** X-Spam-Status: No, score=4.578 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] 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 Qoj7L4c+X-B3 for ; Tue, 19 Aug 2008 04:36:49 -0700 (PDT) Received: from avas-mr18.fibertel.com.ar (avas-mr18.fibertel.com.ar [24.232.0.121]) by core3.amsl.com (Postfix) with ESMTP id 5174B3A69EA for ; Tue, 19 Aug 2008 04:36:49 -0700 (PDT) Received: from 200-122-92-50.cab.prima.net.ar ([200.122.92.50]:1875 "EHLO coloso" smtp-auth: "asamblea18082008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr18.fibertel.com.ar with ESMTPA id S751524AbYHSLXV convert rfc822-to-8bit; Tue, 19 Aug 2008 08:23:21 -0300 Message-ID: <3817-220088219112550887@coloso> To: "note" Errors-to: asamblea18082008_@gmail.com From: "asamblea18082008@gmail.com" Subject: NOTEBOOKS EN TODOS LOS PRECIOS Date: Tue, 19 Aug 2008 08:25:50 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 30442640dac1e73092c8c5c940cf9a5f X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea18082008@gmail.com NOTEBOOKS con GARANTIA, ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: asamblea18082008@gmail.com ASUS ASUS EEE PC 701 ASUS EEE PC 701 Pesa 900 gramos 7" ideal $ 1.419,00 BANGHO CS1406CC BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO CS1406CC-S BanghóMov CS1406CC Celeron 550 1GB DDR2 667Mhz HDD 120GB $ 2.150,00 BANGHO DS1406CB BanghóMov DS1406CB Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.499,00 BANGHO DS1406CB-H BanghóMov DS1406CB-H Intel Dual Core T2370 2GB DDR2 667 HDD 120GB $ 2.599,00 BANGHO CS1501CB BanghóMov BQ1501CB Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.599,00 BANGHO CS1501CB-H BanghóMov BQ1501CB-H Intel Pentium Dual T2390 1GB DDR2 667Mhz 120Gb $ 2.699,00 HEWLETT PACKARD 530 T2600 DOS Procesador Core Duo T2600 HDD 120GB 1GB DDR2 667 15,4'' WI-FI $ 2.799,00 BANGHO DS1501CF BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.499,00 BANGHO CS1202CF-H BanghóMov CS1221C Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.599,00 BANGHO CS1202CF-H BanghóMov CS1202CF-H Intel Core 2 Duo T5450 1Gb DDR2 667Mhz HDD 120GB $ 3.799,00 BANGHO DS1501CF-P BanghóMov BQ1501CB Intel Core 2 Duo T5450 2GB DDR2 667Mhz 120Gb $ 3.799,00 BANGHO DS1205CF-P BanghóMov DS1205C-P Intel Core 2 Duo T5450 2GB DDR2 667 HDD 120GB $ 4.499,00 From owner-ccamp@ops.ietf.org Tue Aug 19 20:25:11 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15873A68E1 for ; Tue, 19 Aug 2008 20:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 T2JF4iuioa65 for ; Tue, 19 Aug 2008 20:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1220B3A6817 for ; Tue, 19 Aug 2008 20:25:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVeB5-0003HY-2q for ccamp-data@psg.com; Wed, 20 Aug 2008 03:16:07 +0000 Received: from [119.145.14.65] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVeAy-0003H0-QZ for ccamp@ops.ietf.org; Wed, 20 Aug 2008 03:16:04 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5V008CLQEMDM@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Wed, 20 Aug 2008 11:15:58 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5V0090RQEMB8@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Wed, 20 Aug 2008 11:15:58 +0800 (CST) Received: from l37133 ([10.70.77.57]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5V009O9QELLX@szxml05-in.huawei.com> for ccamp@ops.ietf.org; Wed, 20 Aug 2008 11:15:58 +0800 (CST) Date: Wed, 20 Aug 2008 11:15:53 +0800 From: Dan Li Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: tony.li@tony.li, 'Igor Bryskin' , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <03e101c90273$0dd3aac0$394d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)" X-Priority: 3 X-MSMail-priority: Normal References: <563325.51910.qm@web36801.mail.mud.yahoo.com> <30CDDADB3BE248069E16208195D56458@ad.redback.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Tony, Igor, I think we should separate two points for this discussion. 1) The amount of information advertised The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links. In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement. In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances. Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern. 2) Speed of convergence of wavelength availability In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high. So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it). But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback" information about the failed link, but also assuming that the IGP may have converged in the mean time). As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation. We can look at a couple of things: - What is the arrival rate of lambda LSPs? - What is the required setup time of lambda LSPs? With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience. Regards, Dan ----- Original Message ----- From: Tony Li To: 'Igor Bryskin' ; 'Dan Li' ; adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org Sent: Tuesday, August 19, 2008 3:43 AM Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Igor, Dan, Perhaps there's an important distinction to be made here. Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure. Debouncing techniques should be used to prevent any connectivity oscillations. However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time. Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale. This of course won't match many folks' requirements for 'real-time'. Tony ---------------------------------------------------------------------------- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin Sent: Monday, August 18, 2008 8:15 AM To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Tony, Igor,
 
I think we should separate two points for this discussion.

1) The amount of information advertised
The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links.

In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement.

In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances.

Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern.

2) Speed of convergence of wavelength availability
In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high.

So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it).

But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback"  information about the failed link, but also assuming that the IGP may have converged in the mean time).

As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation.

We can look at a couple of things:
- What is the arrival rate of lambda LSPs?
- What is the required setup time of lambda LSPs?

With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience.
Regards,
 
Dan
 
----- Original Message -----
From: Tony Li
Sent: Tuesday, August 19, 2008 3:43 AM
Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

 
Igor, Dan,
 
Perhaps there's an important distinction to be made here.  Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure.  Debouncing techniques should be used to prevent any connectivity oscillations.
 
However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time.  Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale.  This of course won't match many folks' requirements for 'real-time'.
 
Tony
 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <danli@huawei.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian



--Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)-- From owner-ccamp@ops.ietf.org Tue Aug 19 22:30:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28F33A68CA for ; Tue, 19 Aug 2008 22:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.218 X-Spam-Level: ** X-Spam-Status: No, score=2.218 tagged_above=-999 required=5 tests=[AWL=-1.906, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] 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 fjViIZtehpR8 for ; Tue, 19 Aug 2008 22:30:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60E9E3A6969 for ; Tue, 19 Aug 2008 22:30:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVgAh-000DoD-W3 for ccamp-data@psg.com; Wed, 20 Aug 2008 05:23:51 +0000 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVgAd-000Dnj-PK for ccamp@ops.ietf.org; Wed, 20 Aug 2008 05:23:49 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id 4UbR1a00216AWCUA3VPnYr; Wed, 20 Aug 2008 05:23:47 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 4VP61a0045Up7oj8SVPB8y; Wed, 20 Aug 2008 05:23:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=Jdb67BthqH4A:10 a=8EpbRKizWpwA:10 a=CnpV7B26hXGe8LNVvqYA:9 a=Yw2MnwNxYkZrfOr-CsUA:7 a=cLl-cSY28GmjdiHoxIi--DUksZ4A:4 a=gJcimI5xSWUA:10 a=qUQ14n5kYGCLXLRizdcA:9 a=bfycVigkNmiHrAC0rVoA:7 a=Q8wR4ElTs5wz-XNgkxqv7VH3Ug8A:4 a=AfD3MYMu9mQA:10 Reply-To: From: "Tony Li" To: "'Dan Li'" , "'Igor Bryskin'" , , , References: <563325.51910.qm@web36801.mail.mud.yahoo.com> <30CDDADB3BE248069E16208195D56458@ad.redback.com> <03e101c90273$0dd3aac0$394d460a@china.huawei.com> Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Tue, 19 Aug 2008 22:22:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C9024A.32CE8300" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckCcxcrmx2RXyoLSCGen5w+2Vk+6gAD5r3A In-Reply-To: <03e101c90273$0dd3aac0$394d460a@china.huawei.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C9024A.32CE8300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dan, 1) The amount of information advertised The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links. True. However, typically the number of TE LSPs that are established is a static number. Even in extreme cases, folks typically use O(n^2) LSPs to form a complete mesh of their nodes. In the applications that I think that you're contemplating, there are many more links, with the ability of end users to set up their own links throughout the network. Please correct me if I'm misunderstanding. In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement. Effectively rate limiting the link state database flooding, which is the goal. In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances. The former is more difficult in IS-IS, as TE information is typically distributed as part of the same LSP that carries the physical link information. Separate protocol instances is of course possible, but it would seem like it would become more of a manageability issue (do you need identical topologies?) and would not obviate the need for CPU cycles. 2) Speed of convergence of wavelength availability In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high. So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it). I'm not sure that I would characterize it as 'crucial'. It would seem like there is always going to be *some* window where remote nodes have imperfect information, just due to speed of light delays. Ergo, the head end must always be prepared for its path to be rejected during setup and then recompute the path based on new information. But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback" information about the failed link, but also assuming that the IGP may have converged in the mean time). Note that crankback (recomputing the path DURING setup) is not always necessary. Sometimes recomputation at the head end will suffice. We can look at a couple of things: - What is the arrival rate of lambda LSPs? - What is the required setup time of lambda LSPs? With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience. In my experience nearly static LSPs are perfectly acceptable, and setup time is not an issue. ;-) My concern however is simpler: limiting the rate of link state database flooding. This is vital to ensure the stability of the IGP. Regards, Tony ------=_NextPart_000_0021_01C9024A.32CE8300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Dan,
 
1) The amount of information advertised
The amount of=20 information carried and the stability of that information is similar = to that=20 used in TE networks today. In those networks, when a TE LSP is = set up or=20 torn down, there is a change in the bandwidth availability on all = links=20 traversed. This causes an update to the TE information advertised in = the IGP=20 for those links. 
 
True.  However, typically the number of TE LSPs = that are=20 established is a static number.  Even in extreme cases, folks = typically use=20 O(n^2) LSPs to form a complete mesh of their nodes.
 
In=20 the applications that I think that you're contemplating, there are many = more=20 links, with the ability of end users to set up their own links = throughout the=20 network.  Please correct me if I'm = misunderstanding.
 
In general, this is not seen as a critical issue. There are = several=20 possibilities to reduce the impact of TE advertisements if they become = a=20 problem. For example, as implemented in some of our current IP = network, each=20 router can impose a threshold (time and/or bandwidth delta) before = which it=20 will not re-issue an advertisement. 
 
Effectively rate limiting the link state database = flooding, which=20 is the goal.
 
 In networks that = require IGP=20 convergence (for IP data traffic) and TE advertisement (for MPLS-TE = traffic)=20 there is some concern that the distribution of TE information might = impact the=20 IGP convergence time. In these cases, implementations may prioritise = normal=20 LSAs ahead of opaque LSAs, or may use separate protocol = instances. 
 
The=20 former is more difficult in IS-IS, as TE information is typically = distributed as=20 part of the same LSP that carries the physical link information.  = Separate=20 protocol instances is of course possible, but it would seem like it = would become=20 more of a manageability issue (do you need identical topologies?) and = would not=20 obviate the need for CPU cycles.
 
 2) Speed of convergence of = wavelength=20 availability
In a TE network, the need for an up-to-date TED = depends to=20 a good degree on the relative size of LSPs and residual bandwidth, and = on the=20 rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite = large,=20 but in general, the rate of arrival of large LSPs is quite low, and = the=20 holding times are quite high.

So, the bottom line in a TE = network is=20 that when an LSP needs more bandwidth than is actually available, it = is=20 crucial that the TED is up-to-date (or "real-time" like some folks may = call=20 it). 
 
I'm=20 not sure that I would characterize it as 'crucial'.  It would seem = like=20 there is always going to be *some* window where remote nodes have = imperfect=20 information, just due to speed of light delays.  Ergo, the head end = must=20 always be prepared for its path to be rejected during setup and then = recompute=20 the path based on new information.
 
 But as Igor has = pointed out,=20 this is impossible to achieve in a distributed system. Indeed, it is=20 impossible to achieve even in a centralised system since network = failures may=20 occur. That means that there is always a possibility that a computed = path will=20 be signaled and will fail to be established. We should be familiar = with this=20 situation in scenarios such as contention during restoration after = network=20 failure, and the signaling protocols are designed to fail and try = again=20 (usually using "crankback"  information about the failed link, = but also=20 assuming that the IGP may have converged in the mean time). 
 
Note=20 that crankback (recomputing the path DURING setup) is not always=20 necessary.  Sometimes recomputation at the head end will=20 suffice.
 
 We can look at a = couple of=20 things:
- What is the arrival rate of lambda LSPs?
- What is the = required setup time of lambda LSPs?

With the exception of = restoration=20 LSPs, I think we may say that a 5-10 second delay in LSP = setup time=20 for 1 in 50 LSPs would be acceptable, but you may have a different=20 experience. 
 
 
In my=20 experience nearly static LSPs are perfectly acceptable, and setup time = is not an=20 issue.  ;-)
 
My=20 concern however is simpler: limiting the rate of link state database=20 flooding.  This is vital to ensure the stability of the=20 IGP.
 
Regards,
Tony
  
------=_NextPart_000_0021_01C9024A.32CE8300-- From owner-ccamp@ops.ietf.org Wed Aug 20 03:10:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100393A6BD6 for ; Wed, 20 Aug 2008 03:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.869 X-Spam-Level: X-Spam-Status: No, score=0.869 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 0N7oeM5cfwOk for ; Wed, 20 Aug 2008 03:10:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A4943A6B81 for ; Wed, 20 Aug 2008 03:10:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVkW6-000FtV-7Z for ccamp-data@psg.com; Wed, 20 Aug 2008 10:02:14 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVkW1-000Fr0-Jc for ccamp@ops.ietf.org; Wed, 20 Aug 2008 10:02:11 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7KA236n030979; Wed, 20 Aug 2008 11:02:03 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7KA22iV030958; Wed, 20 Aug 2008 11:02:02 +0100 Message-ID: <039501c902ab$cae9c170$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Dan Li'" , "'Igor Bryskin'" , , References: <563325.51910.qm@web36801.mail.mud.yahoo.com> <30CDDADB3BE248069E16208195D56458@ad.redback.com> <03e101c90273$0dd3aac0$394d460a@china.huawei.com> Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Wed, 20 Aug 2008 11:01:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Tony, (and by the way, welcome to CCAMP) >> 1) The amount of information advertised >> The amount of information carried and the stability of that information >> is >> similar to that used in TE networks today. In those networks, when a TE >> LSP >> is set up or torn down, there is a change in the bandwidth availability >> on >> all links traversed. This causes an update to the TE information >> advertised >> in the IGP for those links. > > True. However, typically the number of TE LSPs that are established is a > static number. Even in extreme cases, folks typically use O(n^2) LSPs to > form a complete mesh of their nodes. > > In the applications that I think that you're contemplating, there are many > more links, with the ability of end users to set up their own links > throughout the network. Please correct me if I'm misunderstanding. I think there is some misunderstanding here. It is true that in a private lambda model, the end-user may request the establishment of the LSP (where the end-user might be a packet network), but I don't think we should assume that the connectivity is worse than that in a TE network. Indeed, it is likely to be much less. This is in part due to the expense of equipment, the topology of the network, and the constraint of the number of lambdas supported on any link. That means that a single PE will only connect to a realtively small number of other PEs. Of course, this may vary in time as technology improves and as networks get larger and have greater use. >> In general, this is not seen as a critical issue. There are several >> possibilities to reduce the impact of TE advertisements if they become a >> problem. For example, as implemented in some of our current IP network, >> each >> router can impose a threshold (time and/or bandwidth delta) before which >> it >> will not re-issue an advertisement. > > Effectively rate limiting the link state database flooding, which is the > goal. > >> In networks that require IGP convergence (for IP data traffic) and TE >> advertisement (for MPLS-TE traffic) there is some concern that the >> distribution of TE information might impact the IGP convergence time. In >> these cases, implementations may prioritise normal LSAs ahead of opaque >> LSAs, or may use separate protocol instances. > > The former is more difficult in IS-IS, as TE information is typically > distributed as part of the same LSP that carries the physical link > information. Separate protocol instances is of course possible, but it > would seem like it would become more of a manageability issue (do you need > identical topologies?) and would not obviate the need for CPU cycles. Yes. The Gen-App work in IS-IS is specifically to address this issue, I believe. CPU cycles will remain an issue for everyone. But if you build a box for a specific environment, you had better buiold a big enough box! >> 2) Speed of convergence of wavelength availability >> In a TE network, the need for an up-to-date TED depends to a good degree >> on >> the relative size of LSPs and residual bandwidth, and on the rate of >> arrival >> of new LSPs. Increasingly, core TE LSPs may be quite large, but in >> general, >> the rate of arrival of large LSPs is quite low, and the holding times are >> quite high. >> >> So, the bottom line in a TE network is that when an LSP needs more >> bandwidth >> than is actually available, it is crucial that the TED is up-to-date (or >> "real-time" like some folks may call it). > > I'm not sure that I would characterize it as 'crucial'. It would seem > like > there is always going to be *some* window where remote nodes have > imperfect > information, just due to speed of light delays. Ergo, the head end must > always be prepared for its path to be rejected during setup and then > recompute the path based on new information. Absolutely. And the signaling protocols are specifically designed to handle this case. Nevertheless, for customer experience (TM) we would hope to make this window relatively small. And, indeed, the debate lower down the email is really about how likely we are to fall through the window. If it happens for every LSP setup attempt, something clearly needs to be done in the protocols. If it happens less than 1% and only in really busy networks, this may be acceptable. >> But as Igor has pointed out, this is impossible to achieve in a >> distributed >> system. Indeed, it is impossible to achieve even in a centralised system >> since network failures may occur. That means that there is always a >> possibility that a computed path will be signaled and will fail to be >> established. We should be familiar with this situation in scenarios such >> as >> contention during restoration after network failure, and the signaling >> protocols are designed to fail and try again (usually using "crankback" >> information about the failed link, but also assuming that the IGP may >> have >> converged in the mean time). > > Note that crankback (recomputing the path DURING setup) is not always > necessary. Sometimes recomputation at the head end will suffice. Yes. It all depends on whether the TED has converged in the mean time. If so, then reporting the failure and triggering recomputation is needed. If not (or if you can't be sure) it is best to recompute with the knowledge of which link caused the failure in the original setup. That's crankback (RFC 4920). >> We can look at a couple of things: >> - What is the arrival rate of lambda LSPs? >> - What is the required setup time of lambda LSPs? >> >> With the exception of restoration LSPs, I think we may say that a 5-10 >> second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but >> you >> may have a different experience. > > In my experience nearly static LSPs are perfectly acceptable, and setup > time > is not an issue. ;-) Exactly. What we find at the moment, however, is that there is a lot of discussion about moving the transport network from a "nearly static" animal to something that is semi-dynamic, or even "on-demand". This changes the boundaries, but it is still not clear to me that "on-demand" means sub-second as I would expect all lambda LSPs to go through a testing phase before being put in service (even if this is an automatic phase). And I would expect such a phase to take a number of seconds. That said, restoration is a different question. > My concern however is simpler: limiting the rate of link state database > flooding. This is vital to ensure the stability of the IGP. Agreed, but let's be careful to understand the size of the network, the amount of information, and the rate of change of that information. This is really what Dan's I-D is starting to look at, so contributions to helping with that understanding are welcome. If, as you say, most of these LSPs are nearly static, we obviously don't have to worry about the amount of flooding. It is only when LSPs come and go (or when nodes/links come and go) that we will see a change in flooding. I think that what Dan said in this email points out that the amount of flooding (but not necessarily the amount of information flooded) is similar to what we already see in TE networks. We should certainly look to see what the stability experience is with those networks - my understanding is that they are deployed and functional. Cheers, Adrian From owner-ccamp@ops.ietf.org Thu Aug 21 03:07:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079953A6850 for ; Thu, 21 Aug 2008 03:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 5zMdjbns44iQ for ; Thu, 21 Aug 2008 03:07:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DED943A6820 for ; Thu, 21 Aug 2008 03:07:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW6vO-000Mx7-Bn for ccamp-data@psg.com; Thu, 21 Aug 2008 09:57:50 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW6vK-000MwH-21 for ccamp@ops.ietf.org; Thu, 21 Aug 2008 09:57:48 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7L9s9gT024922; Thu, 21 Aug 2008 10:54:09 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7L9s4ID024841; Thu, 21 Aug 2008 10:54:08 +0100 Message-ID: <001f01c90373$da047f60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , , , "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> Subject: Re: BGP TE attr last call by softwires WG Date: Thu, 21 Aug 2008 10:53:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, > From: David Ward > Sent: Tue Aug 12 23:48 > Subject: BGP TE attr last call by softwires WG > > The softwire WG has LC'ed > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > bgp-te-attribute-01.txt > > We will keep open an additional two-week period for wider > review before moving forward in the publication process. > Please have any comments to the authors and softwires WG > by Aug 26, 2008. I have no objection to the basic idea of distributing TE information about CE-PE links especially for use in VPNs. But I am worried by one aspect of the document. Hopefully this is just an editorial issue. The last call in Softwires appears to have generated some discussion about aggregation, and this led to the addition of section 4. | 4. Implication on aggregation | | Routes that carry the Traffic Engineering Attribute | have additional semantics that could affect traffic | forwarding behavior. Therefore, such routes SHALL NOT | be aggregated unless they share identical Traffic | Engineering Attributes. As far as it goes, this paragraph is great. It says "do not perform route aggregation unless it is sensible to do so." But it says nothing about TE aggregation. Notwithstanding the TE attribute is non-transitive, there is the potential for an implementation to believe that it should provide some form of TE aggregation. Consider two cases: 1. A CE is attached by parallel links to a single PE Suppose the links have the same switching types, but different bandwidths. Link-a has plenty of bandwidth available with an MTU size of x. Link-b has not much bandwidth available with an MTU size of y > x. Normally, we would expect the PE to advertise a single piece of reachability information for the CE leaving the actual choice of links to be made by the PE. What would the PE advertise in this case? - It cannot aggregate the TE information because that would imply that there was lots of bandwidth at the larger MTU size. - It could include duplicate Switching Capability Descriptors, but that would need some clarification as duplicate descriptors are intended for different switching caps in the IGP RFCs. - It could advertise two pieces of reachability information, but that would be a change to how the implementation currently works. 2. There is more than one AS Consider CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 PE2 advertises reachability to CE2 and includes TE information. The TE attribute is non-transitive so it is not just passed on, but ASBR2 wants to announce reachability to CE2 (in the VPN case, we may want to support a multi-AS VPN). So ASBR2 can advertise reachability to CE2, but what TE parameters does it advertise? The parameters for the link PE2-CE2 are not so helpful because the TE reachability across AS2 may be different. Yet any attempt to perform a computation of the TE reachability across AS2 (i.e. TE aggregation) is complex and potentially unstable. (Of course, if a tunnel is pre-established between ASBR2 and PE2 this is a different matter.) I think that these two different scenarios need attention in the I-D. For the first one, it may just be a matter of indicating which approach is to be used. For the second one, I hope the answer is to recommend against any form of TE aggregation. This could easily be added to section 4, and I would be happy to provide text. BUT, it will still leave open the question about if and how TE information is propagated beyond the AS. Thanks for any clarifications. Adrian From owner-ccamp@ops.ietf.org Thu Aug 21 11:59:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B401A3A6AF5 for ; Thu, 21 Aug 2008 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 DZH7WVf0qpta for ; Thu, 21 Aug 2008 11:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F4FB3A6B35 for ; Thu, 21 Aug 2008 11:58:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWFD4-000FIY-87 for ccamp-data@psg.com; Thu, 21 Aug 2008 18:48:38 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWFCz-000FHX-V1 for ccamp@ops.ietf.org; Thu, 21 Aug 2008 18:48:36 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id 4B63214FC3B; Thu, 21 Aug 2008 11:48:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5298 on Analysis of Inter-Domain Label Switched Path (LSP) Recovery From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20080821184833.4B63214FC3B@bosco.isi.edu> Date: Thu, 21 Aug 2008 11:48:33 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: A new Request for Comments is now available in online RFC libraries. RFC 5298 Title: Analysis of Inter-Domain Label Switched Path (LSP) Recovery Author: T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur Status: Informational Date: August 2008 Mailbox: takeda.tomonori@lab.ntt.co.jp, y.ikejiri@ntt.com, adrian@olddog.co.uk, jpv@cisco.com Pages: 26 Characters: 59894 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt URL: http://www.rfc-editor.org/rfc/rfc5298.txt Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering". This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane 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/rfcsearch.html. 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 USC/Information Sciences Institute From owner-ccamp@ops.ietf.org Thu Aug 21 16:13:45 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2143A688B for ; Thu, 21 Aug 2008 16:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 2lcL55siMMAs for ; Thu, 21 Aug 2008 16:13:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA2123A6804 for ; Thu, 21 Aug 2008 16:13:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJEj-000OHd-EG for ccamp-data@psg.com; Thu, 21 Aug 2008 23:06:37 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJEe-000OGe-P2 for ccamp@ops.ietf.org; Thu, 21 Aug 2008 23:06:35 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m7LN4l914153; Thu, 21 Aug 2008 23:04:48 GMT X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BGP TE attr last call by softwires WG Date: Thu, 21 Aug 2008 19:04:46 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> In-Reply-To: <001f01c90373$da047f60$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP TE attr last call by softwires WG Thread-Index: AckDdFwlKr2PTql+SjuqzSiskbBx0wAYmanQ References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> From: "Don Fedyk" To: "Adrian Farrel" , Cc: , , , "Yakov Rekhter" , "Hamid Ould-Brahim" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian I should talk this over with my Co-authors so for now I won't answer all your points but I will ask for clarification. See Inline: > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 >=20 > Hi, >=20 > > From: David Ward =20 > > Sent: Tue Aug 12 23:48=20 > > Subject: BGP TE attr last call by softwires WG=20 > > > > The softwire WG has LC'ed=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > > bgp-te-attribute-01.txt=20 > > > > We will keep open an additional two-week period for wider > > review before moving forward in the publication process.=20 > > Please have any comments to the authors and softwires WG=20 > > by Aug 26, 2008.=20 >=20 > I have no objection to the basic idea of distributing TE > information about CE-PE links especially for use in VPNs.=20 > But I am worried by one aspect of the document. Hopefully > this is just an editorial issue. >=20 > The last call in Softwires appears to have generated some > discussion about aggregation, and this led to the addition=20 > of section 4. >=20 > | 4. Implication on aggregation > | > | Routes that carry the Traffic Engineering Attribute=20 > | have additional semantics that could affect traffic=20 > | forwarding behavior. Therefore, such routes SHALL NOT=20 > | be aggregated unless they share identical Traffic > | Engineering Attributes. >=20 > As far as it goes, this paragraph is great. It says "do not > perform route aggregation unless it is sensible to do so." >=20 > But it says nothing about TE aggregation. >=20 > Notwithstanding the TE attribute is non-transitive, there=20 > is the potential for an implementation to believe that it > should provide some form of TE aggregation. >=20 > Consider two cases: >=20 > 1. A CE is attached by parallel links to a single PE >=20 > Suppose the links have the same switching types, but=20 > different bandwidths. Link-a has plenty of bandwidth > available with an MTU size of x. Link-b has not much > bandwidth available with an MTU size of y > x. Interface MTU is part of the PSC TE attributes in the our spec. If the MTUs are different they should not be aggregated.=20 Also In L1VPN (LSC and TDM) networks the Switching type covers Switching granularity (which is like an MTU). =20 I'm trying to understand if you are saying the following text would fix the problem or you see a larger issue:=20 "Therefore, such routes and the corresponding TE information SHALL NOT be aggregated unless they share identical Traffic Engineering Attributes". >=20 > Normally, we would expect the PE to advertise a single > piece of reachability information for the CE leaving > the actual choice of links to be made by the PE. >=20 > What would the PE advertise in this case? > - It cannot aggregate the TE information because that > would imply that there was lots of bandwidth at the=20 > larger MTU size. > - It could include duplicate Switching Capability > Descriptors, but that would need some clarification as > duplicate descriptors are intended for different=20 > switching caps in the IGP RFCs. > - It could advertise two pieces of reachability > information, but that would be a change to how the > implementation currently works. >=20 > 2. There is more than one AS >=20 > Consider >=20 > CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 >=20 > PE2 advertises reachability to CE2 and includes TE=20 > information. The TE attribute is non-transitive so it is > not just passed on, but ASBR2 wants to announce > reachability to CE2 (in the VPN case, we may want to=20 > support a multi-AS VPN). >=20 > So ASBR2 can advertise reachability to CE2, but what TE > parameters does it advertise? The parameters for the=20 > link PE2-CE2 are not so helpful because the TE=20 > reachability across AS2 may be different. Yet any attempt > to perform a computation of the TE reachability across > AS2 (i.e. TE aggregation) is complex and potentially > unstable. (Of course, if a tunnel is pre-established > between ASBR2 and PE2 this is a different matter.) I remember we discussed this aspect originally in the context of L1VPNs and limited it to a single AS since L1VPNs Basic Mode are limited to a single AS. I don't recall if we thought this was applicable to a multi AS solution. We should clarify this point either way. =20 We will get back to you shortly on this point.=20 Thanks, Don=20 >=20 >=20 > I think that these two different scenarios need attention > in the I-D.=20 >=20 > For the first one, it may just be a matter of indicating=20 > which approach is to be used. >=20 > For the second one, I hope the answer is to recommend=20 > against any form of TE aggregation. This could easily be > added to section 4, and I would be happy to provide text. > BUT, it will still leave open the question about if and how > TE information is propagated beyond the AS. >=20 > Thanks for any clarifications. >=20 > Adrian >=20 From owner-ccamp@ops.ietf.org Thu Aug 21 16:24:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDD53A67BD for ; Thu, 21 Aug 2008 16:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 1R3i9hc+vhjV for ; Thu, 21 Aug 2008 16:24:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAFA23A67A1 for ; Thu, 21 Aug 2008 16:24:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJQf-0000iW-C5 for ccamp-data@psg.com; Thu, 21 Aug 2008 23:18:57 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJQb-0000hr-16 for ccamp@ops.ietf.org; Thu, 21 Aug 2008 23:18:55 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7LNI7cV021628; Fri, 22 Aug 2008 00:18:07 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7LNI6tM021616; Fri, 22 Aug 2008 00:18:07 +0100 Message-ID: <010601c903e4$2a081790$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Don Fedyk" , Cc: , , , "Yakov Rekhter" , "Hamid Ould-Brahim" References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> Subject: Re: BGP TE attr last call by softwires WG Date: Fri, 22 Aug 2008 00:18:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hello Don, Thanks for the response. >> 1. A CE is attached by parallel links to a single PE >> >> Suppose the links have the same switching types, but >> different bandwidths. Link-a has plenty of bandwidth >> available with an MTU size of x. Link-b has not much >> bandwidth available with an MTU size of y > x. > > Interface MTU is part of the PSC TE attributes in the our spec. If the > MTUs are different they should not be aggregated. Right. Aggregation in this case is hard to make representative of reality. > Also In L1VPN (LSC and TDM) networks the Switching type > covers Switching granularity (which is like an MTU). Sure. But I wanted to keep in PSC, because that problem represents a single layer network. > I'm trying to understand if you are saying the following text would > fix the problem or you see a larger issue: > "Therefore, such routes and the corresponding TE information > SHALL NOT be aggregated unless they share identical Traffic > Engineering Attributes". The question I am asking is - is the solution to this problem to advertise two routes? (Clearly two is a special case of many.) I don't believe that in the general (non-TE case) we would consider the case of two parallel links between CE and PE as route aggregation. The PE would simply advertise reachability (through itself) to the CE. Hence my question below. >> Normally, we would expect the PE to advertise a single >> piece of reachability information for the CE leaving >> the actual choice of links to be made by the PE. >> >> What would the PE advertise in this case? >> - It cannot aggregate the TE information because that >> would imply that there was lots of bandwidth at the >> larger MTU size. >> - It could include duplicate Switching Capability >> Descriptors, but that would need some clarification as >> duplicate descriptors are intended for different >> switching caps in the IGP RFCs. >> - It could advertise two pieces of reachability >> information, but that would be a change to how the >> implementation currently works. >> 2. There is more than one AS [SNIP] >I remember we discussed this aspect originally in the context of >L1VPNs and limited it to a single AS since L1VPNs Basic Mode >are limited to a single AS. I don't recall if we thought this was >applicable to a multi-AS solution. > >We should clarify this point either way. Thanks. I guess: - if applicable, how? - if not applicable, how prevent? Cheers, Adrian From owner-ccamp@ops.ietf.org Fri Aug 22 00:56:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67493A677E for ; Fri, 22 Aug 2008 00:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, 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 zC646Fkc80wE for ; Fri, 22 Aug 2008 00:56:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 011BE3A6872 for ; Fri, 22 Aug 2008 00:56:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRKf-000DeS-Na for ccamp-data@psg.com; Fri, 22 Aug 2008 07:45:17 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRKb-000Dds-2s for ccamp@ops.ietf.org; Fri, 22 Aug 2008 07:45:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0738528C102; Fri, 22 Aug 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080822074502.0738528C102@core3.amsl.com> Date: Fri, 22 Aug 2008 00:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Pages : 11 Date : 2008-08-22 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-22004208.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Aug 22 06:55:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E77A28C108 for ; Fri, 22 Aug 2008 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, 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 kWk7voLeWz3h for ; Fri, 22 Aug 2008 06:55:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7873F3A6A19 for ; Fri, 22 Aug 2008 06:55:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWWzE-000CHu-0q for ccamp-data@psg.com; Fri, 22 Aug 2008 13:47:32 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWWz9-000CF3-QI for ccamp@ops.ietf.org; Fri, 22 Aug 2008 13:47:29 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1219412845!39988712!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 10065 invoked from network); 22 Aug 2008 13:47:25 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 22 Aug 2008 13:47:25 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m7MDlOLg023315 for ; Fri, 22 Aug 2008 09:47:24 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m7MDlHRf023245 for ; Fri, 22 Aug 2008 09:47:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Date: Fri, 22 Aug 2008 09:47:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Thread-Index: AckEK1xostfKZrU/SRa9RapZDI/EcAAMfPig From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: In preparing the proto for publishing, I had several editorial comments which this updated draft reflects. Thanks Authors- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, August 22, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Pages : 11 Date : 2008-08-22 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ccamp@ops.ietf.org Fri Aug 22 08:57:02 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3252428C24E for ; Fri, 22 Aug 2008 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 uVrPXu2TQquP for ; Fri, 22 Aug 2008 08:57:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0ED603A67E2 for ; Fri, 22 Aug 2008 08:57:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWYrt-000Ab6-G6 for ccamp-data@psg.com; Fri, 22 Aug 2008 15:48:05 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWYrp-000AVs-HJ for ccamp@ops.ietf.org; Fri, 22 Aug 2008 15:48:03 +0000 X-IronPort-AV: E=Sophos;i="4.32,252,1217808000"; d="scan'208";a="144530483" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2008 15:48:00 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7MFjATU004983; Fri, 22 Aug 2008 08:47:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7MFgO6R000047; Fri, 22 Aug 2008 15:42:25 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Aug 2008 11:42:20 -0400 Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Aug 2008 15:42:19 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 22 Aug 2008 17:42:18 +0200 Subject: Re: BGP TE attr last call by softwires WG From: JP Vasseur To: Adrian Farrel , Don Fedyk , CC: , , , Yakov Rekhter , Hamid Ould-Brahim Message-ID: Thread-Topic: BGP TE attr last call by softwires WG Thread-Index: AckEbahm2i50H6DSZkGNaiR5Sc3eJQ== In-Reply-To: <010601c903e4$2a081790$0300a8c0@your029b8cecfe> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Aug 2008 15:42:20.0242 (UTC) FILETIME=[A9BC8320:01C9046D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2992; t=1219420078; x=1220284078; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20BGP=20TE=20attr=20last=20call=20by=20so ftwires=20WG |Sender:=20; bh=xY2Z4B5XuQ6sC1pYhm6vi+VcgoDyLYT4GyFXblvsoR0=; b=rbv0pq1rQTcB8QLwAXY+RKfFqb3otPII+Sp+/PblbLXTYpQ4tG0HUJzeUi tp/JVLN1X2ry3aJpqui9M9xtOh2SIkRVMY/hhyhDdZxwUoCmxcc/fqKM4Os1 f2+HP7sosYKV+mOV3RKcXhDvQw/i6YFEOlzlavIBqrGYrRZru/x3I=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, I'd like to second Adrian's point here - see below. On 8/22/08 1:18 AM, "Adrian Farrel" wrote: > Hello Don, > > Thanks for the response. > >>> 1. A CE is attached by parallel links to a single PE >>> >>> Suppose the links have the same switching types, but >>> different bandwidths. Link-a has plenty of bandwidth >>> available with an MTU size of x. Link-b has not much >>> bandwidth available with an MTU size of y > x. >> >> Interface MTU is part of the PSC TE attributes in the our spec. If the >> MTUs are different they should not be aggregated. > > Right. > Aggregation in this case is hard to make representative of reality. That is also my concern ... It would be really nice to clarify that TE aggregation must be avoided. > >> Also In L1VPN (LSC and TDM) networks the Switching type >> covers Switching granularity (which is like an MTU). > > Sure. But I wanted to keep in PSC, because that problem represents a single > layer network. > >> I'm trying to understand if you are saying the following text would >> fix the problem or you see a larger issue: >> "Therefore, such routes and the corresponding TE information >> SHALL NOT be aggregated unless they share identical Traffic >> Engineering Attributes". > > The question I am asking is - is the solution to this problem to advertise > two routes? > (Clearly two is a special case of many.) > > I don't believe that in the general (non-TE case) we would consider the case > of two parallel links between CE and PE as route aggregation. The PE would > simply advertise reachability (through itself) to the CE. > > Hence my question below. > >>> Normally, we would expect the PE to advertise a single >>> piece of reachability information for the CE leaving >>> the actual choice of links to be made by the PE. >>> >>> What would the PE advertise in this case? >>> - It cannot aggregate the TE information because that >>> would imply that there was lots of bandwidth at the >>> larger MTU size. >>> - It could include duplicate Switching Capability >>> Descriptors, but that would need some clarification as >>> duplicate descriptors are intended for different >>> switching caps in the IGP RFCs. >>> - It could advertise two pieces of reachability >>> information, but that would be a change to how the >>> implementation currently works. > >>> 2. There is more than one AS > [SNIP] >> I remember we discussed this aspect originally in the context of >> L1VPNs and limited it to a single AS since L1VPNs Basic Mode >> are limited to a single AS. I don't recall if we thought this was >> applicable to a multi-AS solution. >> >> We should clarify this point either way. > > Thanks. > I guess: > - if applicable, how? > - if not applicable, how prevent? > Same question. Thanks Don. JP. > Cheers, > Adrian > > From owner-ccamp@ops.ietf.org Sun Aug 24 20:37:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59E63A6807 for ; Sun, 24 Aug 2008 20:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 dNEBnP8UNevd for ; Sun, 24 Aug 2008 20:37:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC07F3A63D3 for ; Sun, 24 Aug 2008 20:37:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXSmP-000Jdg-Pc for ccamp-data@psg.com; Mon, 25 Aug 2008 03:30:09 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXSmJ-000Jbi-E1 for ccamp@ops.ietf.org; Mon, 25 Aug 2008 03:30:07 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 8F16A3A682B; Sun, 24 Aug 2008 20:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080825033001.8F16A3A682B@core3.amsl.com> Date: Sun, 24 Aug 2008 20:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-isis-interas-te-extension-03.txt Pages : 20 Date : 2008-08-24 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-isis-interas-te-extension-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-24202349.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Aug 25 11:23:14 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6585D3A67B5 for ; Mon, 25 Aug 2008 11:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 krYhNtsOVjgV for ; Mon, 25 Aug 2008 11:23:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 703203A6768 for ; Mon, 25 Aug 2008 11:23:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXgcX-000960-3T for ccamp-data@psg.com; Mon, 25 Aug 2008 18:16:53 +0000 Received: from [64.18.2.169] (helo=exprod7og108.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXgcQ-00094g-Rl for ccamp@ops.ietf.org; Mon, 25 Aug 2008 18:16:49 +0000 Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 11:16:45 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 11:14:22 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 11:14:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Aug 2008 11:14:20 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7PIEFu54645; Mon, 25 Aug 2008 11:14:16 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808251814.m7PIEFu54645@magenta.juniper.net> To: "Adrian Farrel" cc: "Don Fedyk" , softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG In-reply-to: <010601c903e4$2a081790$0300a8c0@your029b8cecfe> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> <010601c903e4$2a081790$0300a8c0@your029b8cecfe> X-MH-In-Reply-To: "Adrian Farrel" message dated "Fri, 22 Aug 2008 00:18:02 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17410.1219688055.1@juniper.net> Date: Mon, 25 Aug 2008 11:14:15 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 25 Aug 2008 18:14:20.0896 (UTC) FILETIME=[654F1E00:01C906DE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian, > Hello Don, > > Thanks for the response. > > >> 1. A CE is attached by parallel links to a single PE > >> > >> Suppose the links have the same switching types, but > >> different bandwidths. Link-a has plenty of bandwidth > >> available with an MTU size of x. Link-b has not much > >> bandwidth available with an MTU size of y > x. > > > > Interface MTU is part of the PSC TE attributes in the our spec. If the > > MTUs are different they should not be aggregated. > > Right. Aggregation in this case is hard to make representative of reality. > > > Also In L1VPN (LSC and TDM) networks the Switching type > > covers Switching granularity (which is like an MTU). > > Sure. But I wanted to keep in PSC, because that problem represents a single > layer network. > > > I'm trying to understand if you are saying the following text would > > fix the problem or you see a larger issue: > > "Therefore, such routes and the corresponding TE information > > SHALL NOT be aggregated unless they share identical Traffic > > Engineering Attributes". > > The question I am asking is - is the solution to this problem to advertise > two routes? (Clearly two is a special case of many.) > > I don't believe that in the general (non-TE case) we would consider the case > of two parallel links between CE and PE as route aggregation. The PE would > simply advertise reachability (through itself) to the CE. Let's put the general (non-TE) case aside, and focus on the L1VPN scenario. According to the bgp-auto-discovery and l1vpn-basic-mode drafts in the context of L1VPN what is advertised in the BGP auto-discovery information is the information about *ports*. Therefore, in the context of L1VPN TE information advertisements are associated with individual *ports*, not with a particular CE. Which means that if a CE is connected to a PE by N ports, then the BGP auto-discovery information has to advertise all these N ports, and associated with each such advertisement may be the TE information. > Hence my question below. > > >> Normally, we would expect the PE to advertise a single > >> piece of reachability information for the CE leaving > >> the actual choice of links to be made by the PE. > >> > >> What would the PE advertise in this case? > >> - It cannot aggregate the TE information because that > >> would imply that there was lots of bandwidth at the > >> larger MTU size. > >> - It could include duplicate Switching Capability > >> Descriptors, but that would need some clarification as > >> duplicate descriptors are intended for different > >> switching caps in the IGP RFCs. > >> - It could advertise two pieces of reachability > >> information, but that would be a change to how the > >> implementation currently works. The answer to your question is that if the implementation follows the spec, it would advertise information about *ports*. So, if a CE has two ports that connect it to a PE, then the PE originates two L1VPN advertisements, one per port, each with its own TE attribute. Yakov. From owner-ccamp@ops.ietf.org Tue Aug 26 06:12:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C6328C2F1 for ; Tue, 26 Aug 2008 06:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 XgfBJGFipnnk for ; Tue, 26 Aug 2008 06:12:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D26AB28C2E9 for ; Tue, 26 Aug 2008 06:12:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXy95-000HiS-KB for ccamp-data@psg.com; Tue, 26 Aug 2008 12:59:39 +0000 Received: from [64.18.2.161] (helo=exprod7og104.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXy8w-000Hgu-64 for ccamp@ops.ietf.org; Tue, 26 Aug 2008 12:59:36 +0000 Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 05:58:07 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:19 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7QCsJu33149; Tue, 26 Aug 2008 05:54:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808261254.m7QCsJu33149@magenta.juniper.net> To: "Adrian Farrel" cc: softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG In-reply-to: <001f01c90373$da047f60$0300a8c0@your029b8cecfe> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> X-MH-In-Reply-To: "Adrian Farrel" message dated "Thu, 21 Aug 2008 10:53:59 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46141.1219755259.1@juniper.net> Date: Tue, 26 Aug 2008 05:54:19 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 26 Aug 2008 12:54:19.0715 (UTC) FILETIME=[DAED2930:01C9077A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian, > Hi, > > > From: David Ward > > Sent: Tue Aug 12 23:48 > > Subject: BGP TE attr last call by softwires WG > > > > The softwire WG has LC'ed > > > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > > bgp-te-attribute-01.txt > > > > We will keep open an additional two-week period for wider > > review before moving forward in the publication process. > > Please have any comments to the authors and softwires WG > > by Aug 26, 2008. > > I have no objection to the basic idea of distributing TE > information about CE-PE links especially for use in VPNs. > But I am worried by one aspect of the document. Hopefully > this is just an editorial issue. > > The last call in Softwires appears to have generated some > discussion about aggregation, and this led to the addition > of section 4. > > | 4. Implication on aggregation > | > | Routes that carry the Traffic Engineering Attribute > | have additional semantics that could affect traffic > | forwarding behavior. Therefore, such routes SHALL NOT > | be aggregated unless they share identical Traffic > | Engineering Attributes. > > As far as it goes, this paragraph is great. It says "do not > perform route aggregation unless it is sensible to do so." > > But it says nothing about TE aggregation. > > Notwithstanding the TE attribute is non-transitive, there > is the potential for an implementation to believe that it > should provide some form of TE aggregation. > > Consider two cases: > > 1. A CE is attached by parallel links to a single PE > > Suppose the links have the same switching types, but > different bandwidths. Link-a has plenty of bandwidth > available with an MTU size of x. Link-b has not much > bandwidth available with an MTU size of y > x. > > Normally, we would expect the PE to advertise a single > piece of reachability information for the CE leaving > the actual choice of links to be made by the PE. > > What would the PE advertise in this case? > - It cannot aggregate the TE information because that > would imply that there was lots of bandwidth at the > larger MTU size. > - It could include duplicate Switching Capability > Descriptors, but that would need some clarification as > duplicate descriptors are intended for different > switching caps in the IGP RFCs. > - It could advertise two pieces of reachability > information, but that would be a change to how the > implementation currently works. I already answered this in my other e-mail yesterday. > 2. There is more than one AS > > Consider > > CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > PE2 advertises reachability to CE2 and includes TE > information. The TE attribute is non-transitive so it is > not just passed on, but ASBR2 wants to announce > reachability to CE2 (in the VPN case, we may want to > support a multi-AS VPN). > > So ASBR2 can advertise reachability to CE2, but what TE > parameters does it advertise? The parameters for the > link PE2-CE2 are not so helpful because the TE > reachability across AS2 may be different. Yet any attempt > to perform a computation of the TE reachability across > AS2 (i.e. TE aggregation) is complex and potentially > unstable. (Of course, if a tunnel is pre-established > between ASBR2 and PE2 this is a different matter.) > > > I think that these two different scenarios need attention > in the I-D. > > For the first one, it may just be a matter of indicating > which approach is to be used. > > For the second one, I hope the answer is to recommend > against any form of TE aggregation. This could easily be > added to section 4, and I would be happy to provide text. > BUT, it will still leave open the question about if and how > TE information is propagated beyond the AS. For the second one the answer is in rfc5251: Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document. Yakov. From owner-ccamp@ops.ietf.org Wed Aug 27 03:56:34 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0C428C225 for ; Wed, 27 Aug 2008 03:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.704 X-Spam-Level: * X-Spam-Status: No, score=1.704 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 Y0f6NOsRP51u for ; Wed, 27 Aug 2008 03:56:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0638A28C21A for ; Wed, 27 Aug 2008 03:56:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIYO-000BDC-Kn for ccamp-data@psg.com; Wed, 27 Aug 2008 10:47:08 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIYH-000B9i-Lq for ccamp@ops.ietf.org; Wed, 27 Aug 2008 10:47:06 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7RAkWTb015840; Wed, 27 Aug 2008 11:46:33 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7RAkVOJ015792; Wed, 27 Aug 2008 11:46:32 +0100 Message-ID: <051601c90832$2a87f530$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Yakov Rekhter" Cc: "Don Fedyk" , , , , , "Hamid Ould-Brahim" References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> <010601c903e4$2a081790$0300a8c0@your029b8cecfe> <200808251814.m7PIEFu54645@magenta.juniper.net> Subject: Re: BGP TE attr last call by softwires WG Date: Wed, 27 Aug 2008 11:46:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Yakov, You have answered my first question, within the limited scope of basic mode, single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with your interpretation. This is good, and I support the use of this draft in that limited scenario, and I suspect that the concept is extensible to any port-based VPN. Will you be adding to the draft to say that this is the full extent of the applicability of this draft (perhaps using RFC 2119 language)? If not, then I'm afraid that my question stands. What will happen in the case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE links? Thanks, Adrian >> >> 1. A CE is attached by parallel links to a single PE >> >> >> >> Suppose the links have the same switching types, but >> >> different bandwidths. Link-a has plenty of bandwidth >> >> available with an MTU size of x. Link-b has not much >> >> bandwidth available with an MTU size of y > x. >> > >> > Interface MTU is part of the PSC TE attributes in the our spec. If the >> > MTUs are different they should not be aggregated. >> >> Right. Aggregation in this case is hard to make representative of >> reality. >> >> > Also In L1VPN (LSC and TDM) networks the Switching type >> > covers Switching granularity (which is like an MTU). >> >> Sure. But I wanted to keep in PSC, because that problem represents a >> single >> layer network. >> >> > I'm trying to understand if you are saying the following text would >> > fix the problem or you see a larger issue: >> > "Therefore, such routes and the corresponding TE information >> > SHALL NOT be aggregated unless they share identical Traffic >> > Engineering Attributes". >> >> The question I am asking is - is the solution to this problem to >> advertise >> two routes? (Clearly two is a special case of many.) >> >> I don't believe that in the general (non-TE case) we would consider the >> case >> of two parallel links between CE and PE as route aggregation. The PE >> would >> simply advertise reachability (through itself) to the CE. > > Let's put the general (non-TE) case aside, and focus on the L1VPN > scenario. > > According to the bgp-auto-discovery and l1vpn-basic-mode drafts in > the context of L1VPN what is advertised in the BGP auto-discovery > information is the information about *ports*. Therefore, in the > context of L1VPN TE information advertisements are associated with > individual *ports*, not with a particular CE. Which means that if > a CE is connected to a PE by N ports, then the BGP auto-discovery > information has to advertise all these N ports, and associated with > each such advertisement may be the TE information. > >> Hence my question below. >> >> >> Normally, we would expect the PE to advertise a single >> >> piece of reachability information for the CE leaving >> >> the actual choice of links to be made by the PE. >> >> >> >> What would the PE advertise in this case? >> >> - It cannot aggregate the TE information because that >> >> would imply that there was lots of bandwidth at the >> >> larger MTU size. >> >> - It could include duplicate Switching Capability >> >> Descriptors, but that would need some clarification as >> >> duplicate descriptors are intended for different >> >> switching caps in the IGP RFCs. >> >> - It could advertise two pieces of reachability >> >> information, but that would be a change to how the >> >> implementation currently works. > > The answer to your question is that if the implementation follows > the spec, it would advertise information about *ports*. So, if a > CE has two ports that connect it to a PE, then the PE originates > two L1VPN advertisements, one per port, each with its own TE > attribute. From owner-ccamp@ops.ietf.org Wed Aug 27 04:01:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402413A6B7C for ; Wed, 27 Aug 2008 04:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.871 X-Spam-Level: * X-Spam-Status: No, score=1.871 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 dolvAbAdXJdT for ; Wed, 27 Aug 2008 04:01:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50F3C28C1BD for ; Wed, 27 Aug 2008 04:01:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIer-000C6B-GO for ccamp-data@psg.com; Wed, 27 Aug 2008 10:53:49 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYIem-000C40-Tw for ccamp@ops.ietf.org; Wed, 27 Aug 2008 10:53:47 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7RApwOd021042; Wed, 27 Aug 2008 11:51:58 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7RApvrG021036; Wed, 27 Aug 2008 11:51:58 +0100 Message-ID: <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Yakov Rekhter" Cc: , , , , "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> Subject: Re: BGP TE attr last call by softwires WG (2nd question) Date: Wed, 27 Aug 2008 11:51:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi again Yakov, Thanks also for the reply to my second question. Your answer seems to imply that the applicability of your work is strictly limited to L1VPNs. If this is the case, we can easily close this discussion by adding text to the Abstract and Introduction such as: The scope and applicability of this protocol extension is currently limited to single-AS deployment scenarios of the basic mode of L1VPNs. Further applications are for future study, but these mechanisms SHOULD NOT be used in any attempt to support TE aggregation. Cheers, Adrian >> 2. There is more than one AS >> >> Consider >> >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 >> >> PE2 advertises reachability to CE2 and includes TE >> information. The TE attribute is non-transitive so it is >> not just passed on, but ASBR2 wants to announce >> reachability to CE2 (in the VPN case, we may want to >> support a multi-AS VPN). >> >> So ASBR2 can advertise reachability to CE2, but what TE >> parameters does it advertise? The parameters for the >> link PE2-CE2 are not so helpful because the TE >> reachability across AS2 may be different. Yet any attempt >> to perform a computation of the TE reachability across >> AS2 (i.e. TE aggregation) is complex and potentially >> unstable. (Of course, if a tunnel is pre-established >> between ASBR2 and PE2 this is a different matter.) >> >> I think that these two different scenarios need attention >> in the I-D. >> >> For the first one, it may just be a matter of indicating >> which approach is to be used. >> >> For the second one, I hope the answer is to recommend >> against any form of TE aggregation. This could easily be >> added to section 4, and I would be happy to provide text. >> BUT, it will still leave open the question about if and how >> TE information is propagated beyond the AS. > > For the second one the answer is in rfc5251: > > Consideration of inter-AS and inter-provider L1VPNs requires further > analysis beyond the scope of this document. From owner-ccamp@ops.ietf.org Wed Aug 27 06:40:12 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2FE3A694F for ; Wed, 27 Aug 2008 06:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] 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 nha-iFsT1dLQ for ; Wed, 27 Aug 2008 06:40:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2DC33A68E8 for ; Wed, 27 Aug 2008 06:40:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYL6v-0005Fh-Jl for ccamp-data@psg.com; Wed, 27 Aug 2008 13:30:57 +0000 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYL6o-0005Ek-Fa for ccamp@ops.ietf.org; Wed, 27 Aug 2008 13:30:55 +0000 Received: from localhost ([127.0.0.1] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.69) (envelope-from ) id 1KYL6T-0004ER-LZ; Wed, 27 Aug 2008 09:30:29 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 09:30:25 -0400 To: Adrian Farrel From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: "Yakov Rekhter" ,ccamp@ops.ietf.org, softwires@ietf.org In-Reply-To: <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Why "SHOULD NOT" rather than "MUST NOT"? Lou At 06:51 AM 8/27/2008, Adrian Farrel wrote: >Hi again Yakov, > >Thanks also for the reply to my second question. > >Your answer seems to imply that the applicability of your work is strictly >limited to L1VPNs. > >If this is the case, we can easily close this discussion by adding text to >the Abstract and Introduction such as: > > The scope and applicability of this protocol extension is > currently limited to single-AS deployment scenarios of the > basic mode of L1VPNs. Further applications are for > future study, but these mechanisms SHOULD NOT be > used in any attempt to support TE aggregation. > >Cheers, >Adrian > > >> 2. There is more than one AS > >> > >> Consider > >> > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > >> > >> PE2 advertises reachability to CE2 and includes TE > >> information. The TE attribute is non-transitive so it is > >> not just passed on, but ASBR2 wants to announce > >> reachability to CE2 (in the VPN case, we may want to > >> support a multi-AS VPN). > >> > >> So ASBR2 can advertise reachability to CE2, but what TE > >> parameters does it advertise? The parameters for the > >> link PE2-CE2 are not so helpful because the TE > >> reachability across AS2 may be different. Yet any attempt > >> to perform a computation of the TE reachability across > >> AS2 (i.e. TE aggregation) is complex and potentially > >> unstable. (Of course, if a tunnel is pre-established > >> between ASBR2 and PE2 this is a different matter.) > >> > >> I think that these two different scenarios need attention > >> in the I-D. > >> > >> For the first one, it may just be a matter of indicating > >> which approach is to be used. > >> > >> For the second one, I hope the answer is to recommend > >> against any form of TE aggregation. This could easily be > >> added to section 4, and I would be happy to provide text. > >> BUT, it will still leave open the question about if and how > >> TE information is propagated beyond the AS. > > > > For the second one the answer is in rfc5251: > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > analysis beyond the scope of this document. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From owner-ccamp@ops.ietf.org Wed Aug 27 07:00:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ED228C294 for ; Wed, 27 Aug 2008 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.722 X-Spam-Level: X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 SGFq03EmDCZb for ; Wed, 27 Aug 2008 07:00:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE4E728C226 for ; Wed, 27 Aug 2008 07:00:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYLRK-0008AZ-Ae for ccamp-data@psg.com; Wed, 27 Aug 2008 13:52:02 +0000 Received: from [64.18.2.159] (helo=exprod7og103.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYLR8-00088h-EQ for ccamp@ops.ietf.org; Wed, 27 Aug 2008 13:51:56 +0000 Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 06:51:38 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 06:50:29 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 06:50:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 06:50:28 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7RDoSu86903; Wed, 27 Aug 2008 06:50:28 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808271350.m7RDoSu86903@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) In-reply-to: References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> X-MH-In-Reply-To: Lou Berger message dated "Wed, 27 Aug 2008 09:30:25 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27575.1219845028.1@juniper.net> Date: Wed, 27 Aug 2008 06:50:28 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 27 Aug 2008 13:50:28.0442 (UTC) FILETIME=[DD41DBA0:01C9084B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Lou, > Why "SHOULD NOT" rather than "MUST NOT"? It is already there (Section 4): Routes that carry the Traffic Engineering Attribute have additional semantics that could affect traffic forwarding behavior. Therefore, such routes SHALL NOT be aggregated unless they share identical Traffic Engineering Attributes. Yakov. > > Lou > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > >Hi again Yakov, > > > >Thanks also for the reply to my second question. > > > >Your answer seems to imply that the applicability of your work is strictly > >limited to L1VPNs. > > > >If this is the case, we can easily close this discussion by adding text to > >the Abstract and Introduction such as: > > > > The scope and applicability of this protocol extension is > > currently limited to single-AS deployment scenarios of the > > basic mode of L1VPNs. Further applications are for > > future study, but these mechanisms SHOULD NOT be > > used in any attempt to support TE aggregation. > > > >Cheers, > >Adrian > > > > >> 2. There is more than one AS > > >> > > >> Consider > > >> > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > >> > > >> PE2 advertises reachability to CE2 and includes TE > > >> information. The TE attribute is non-transitive so it is > > >> not just passed on, but ASBR2 wants to announce > > >> reachability to CE2 (in the VPN case, we may want to > > >> support a multi-AS VPN). > > >> > > >> So ASBR2 can advertise reachability to CE2, but what TE > > >> parameters does it advertise? The parameters for the > > >> link PE2-CE2 are not so helpful because the TE > > >> reachability across AS2 may be different. Yet any attempt > > >> to perform a computation of the TE reachability across > > >> AS2 (i.e. TE aggregation) is complex and potentially > > >> unstable. (Of course, if a tunnel is pre-established > > >> between ASBR2 and PE2 this is a different matter.) > > >> > > >> I think that these two different scenarios need attention > > >> in the I-D. > > >> > > >> For the first one, it may just be a matter of indicating > > >> which approach is to be used. > > >> > > >> For the second one, I hope the answer is to recommend > > >> against any form of TE aggregation. This could easily be > > >> added to section 4, and I would be happy to provide text. > > >> BUT, it will still leave open the question about if and how > > >> TE information is propagated beyond the AS. > > > > > > For the second one the answer is in rfc5251: > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > > analysis beyond the scope of this document. > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > From owner-ccamp@ops.ietf.org Wed Aug 27 07:38:53 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49D23A6C37 for ; Wed, 27 Aug 2008 07:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] 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 wkOFyr3yGvUN for ; Wed, 27 Aug 2008 07:38:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96FEA3A6C12 for ; Wed, 27 Aug 2008 07:38:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYM29-000Dcm-Pn for ccamp-data@psg.com; Wed, 27 Aug 2008 14:30:05 +0000 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYM22-000DbE-0j for ccamp@ops.ietf.org; Wed, 27 Aug 2008 14:30:03 +0000 Received: from localhost ([127.0.0.1] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.69) (envelope-from ) id 1KYM1T-0001ks-P4; Wed, 27 Aug 2008 10:29:23 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 10:29:15 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org In-Reply-To: <200808271350.m7RDoSu86903@magenta.juniper.net> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: If you drop the "unless they share identical Traffic Engineering Attributes" then we have alignment. Lou At 09:50 AM 8/27/2008, Yakov Rekhter wrote: >Lou, > > > Why "SHOULD NOT" rather than "MUST NOT"? > >It is already there (Section 4): > > Routes that carry the Traffic Engineering Attribute have additional > semantics that could affect traffic forwarding behavior. Therefore, > such routes SHALL NOT be aggregated unless they share identical > Traffic Engineering Attributes. > >Yakov. > > > > > Lou > > > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > > >Hi again Yakov, > > > > > >Thanks also for the reply to my second question. > > > > > >Your answer seems to imply that the applicability of your work is strictly > > >limited to L1VPNs. > > > > > >If this is the case, we can easily close this discussion by adding text to > > >the Abstract and Introduction such as: > > > > > > The scope and applicability of this protocol extension is > > > currently limited to single-AS deployment scenarios of the > > > basic mode of L1VPNs. Further applications are for > > > future study, but these mechanisms SHOULD NOT be > > > used in any attempt to support TE aggregation. > > > > > >Cheers, > > >Adrian > > > > > > >> 2. There is more than one AS > > > >> > > > >> Consider > > > >> > > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > > >> > > > >> PE2 advertises reachability to CE2 and includes TE > > > >> information. The TE attribute is non-transitive so it is > > > >> not just passed on, but ASBR2 wants to announce > > > >> reachability to CE2 (in the VPN case, we may want to > > > >> support a multi-AS VPN). > > > >> > > > >> So ASBR2 can advertise reachability to CE2, but what TE > > > >> parameters does it advertise? The parameters for the > > > >> link PE2-CE2 are not so helpful because the TE > > > >> reachability across AS2 may be different. Yet any attempt > > > >> to perform a computation of the TE reachability across > > > >> AS2 (i.e. TE aggregation) is complex and potentially > > > >> unstable. (Of course, if a tunnel is pre-established > > > >> between ASBR2 and PE2 this is a different matter.) > > > >> > > > >> I think that these two different scenarios need attention > > > >> in the I-D. > > > >> > > > >> For the first one, it may just be a matter of indicating > > > >> which approach is to be used. > > > >> > > > >> For the second one, I hope the answer is to recommend > > > >> against any form of TE aggregation. This could easily be > > > >> added to section 4, and I would be happy to provide text. > > > >> BUT, it will still leave open the question about if and how > > > >> TE information is propagated beyond the AS. > > > > > > > > For the second one the answer is in rfc5251: > > > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > > > analysis beyond the scope of this document. > > > > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > > > > From owner-ccamp@ops.ietf.org Wed Aug 27 09:29:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72493A67A3 for ; Wed, 27 Aug 2008 09:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.661 X-Spam-Level: X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 yejQGb-gdCNn for ; Wed, 27 Aug 2008 09:29:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B90F73A6843 for ; Wed, 27 Aug 2008 09:29:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYNew-0001mJ-U6 for ccamp-data@psg.com; Wed, 27 Aug 2008 16:14:14 +0000 Received: from [64.18.14.207] (helo=chip3og65.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYNeg-0001kQ-EF for ccamp@ops.ietf.org; Wed, 27 Aug 2008 16:14:05 +0000 Received: from source ([66.129.228.6]) by chip3ob65.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 09:13:06 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:02:22 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:02:21 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:02:21 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7RG2Ju46053; Wed, 27 Aug 2008 09:02:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808271602.m7RG2Ju46053@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) In-reply-to: References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> X-MH-In-Reply-To: Lou Berger message dated "Wed, 27 Aug 2008 10:29:15 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42761.1219852939.1@juniper.net> Date: Wed, 27 Aug 2008 09:02:19 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 27 Aug 2008 16:02:21.0639 (UTC) FILETIME=[49E3E570:01C9085E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Lou, > If you drop the "unless they share identical Traffic Engineering > Attributes" then we have alignment. If they do share identical TE attributes, then there is no problem to aggregate such routes. So, the current text is correct. Yakov. > > Lou > > At 09:50 AM 8/27/2008, Yakov Rekhter wrote: > >Lou, > > > > > Why "SHOULD NOT" rather than "MUST NOT"? > > > >It is already there (Section 4): > > > > Routes that carry the Traffic Engineering Attribute have additional > > semantics that could affect traffic forwarding behavior. Therefore, > > such routes SHALL NOT be aggregated unless they share identical > > Traffic Engineering Attributes. > > > >Yakov. > > > > > > > > Lou > > > > > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > > > >Hi again Yakov, > > > > > > > >Thanks also for the reply to my second question. > > > > > > > >Your answer seems to imply that the applicability of your work is strict ly > > > >limited to L1VPNs. > > > > > > > >If this is the case, we can easily close this discussion by adding text to > > > >the Abstract and Introduction such as: > > > > > > > > The scope and applicability of this protocol extension is > > > > currently limited to single-AS deployment scenarios of the > > > > basic mode of L1VPNs. Further applications are for > > > > future study, but these mechanisms SHOULD NOT be > > > > used in any attempt to support TE aggregation. > > > > > > > >Cheers, > > > >Adrian > > > > > > > > >> 2. There is more than one AS > > > > >> > > > > >> Consider > > > > >> > > > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > > > >> > > > > >> PE2 advertises reachability to CE2 and includes TE > > > > >> information. The TE attribute is non-transitive so it is > > > > >> not just passed on, but ASBR2 wants to announce > > > > >> reachability to CE2 (in the VPN case, we may want to > > > > >> support a multi-AS VPN). > > > > >> > > > > >> So ASBR2 can advertise reachability to CE2, but what TE > > > >> parameters does it advertise? The parameters for the > > > > >> link PE2-CE2 are not so helpful because the TE > > > > >> reachability across AS2 may be different. Yet any attempt > > > > >> to perform a computation of the TE reachability across > > > > >> AS2 (i.e. TE aggregation) is complex and potentially > > > > >> unstable. (Of course, if a tunnel is pre-established > > > > >> between ASBR2 and PE2 this is a different matter.) > > > > >> > > > > >> I think that these two different scenarios need attention > > > > >> in the I-D. > > > > >> > > > > >> For the first one, it may just be a matter of indicating > > > > >> which approach is to be used. > > > > >> > > > > >> For the second one, I hope the answer is to recommend > > > > >> against any form of TE aggregation. This could easily be > > > > >> added to section 4, and I would be happy to provide text. > > > > >> BUT, it will still leave open the question about if and how > > > > >> TE information is propagated beyond the AS. > > > > > > > > > > For the second one the answer is in rfc5251: > > > > > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires furthe r > > > > > analysis beyond the scope of this document. > > > > > > > >_______________________________________________ > > > >Softwires mailing list > > > >Softwires@ietf.org > > > >https://www.ietf.org/mailman/listinfo/softwires > > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 27 10:32:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F165828C1E9 for ; Wed, 27 Aug 2008 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 uHZHnopuOy3R for ; Wed, 27 Aug 2008 10:32:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 659D628C1D3 for ; Wed, 27 Aug 2008 10:32:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOhE-000C0Z-I2 for ccamp-data@psg.com; Wed, 27 Aug 2008 17:20:40 +0000 Received: from [64.18.14.201] (helo=chip3og62.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOgy-000Bxt-Rw for ccamp@ops.ietf.org; Wed, 27 Aug 2008 17:20:30 +0000 Received: from source ([66.129.228.6]) by chip3ob62.postini.com ([64.18.6.12]) with SMTP; Wed, 27 Aug 2008 10:20:04 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:05:41 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:05:41 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Aug 2008 09:05:41 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7RG5eu48071; Wed, 27 Aug 2008 09:05:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808271605.m7RG5eu48071@magenta.juniper.net> To: "Adrian Farrel" cc: "Don Fedyk" , softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG In-reply-to: <051601c90832$2a87f530$0300a8c0@your029b8cecfe> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> <010601c903e4$2a081790$0300a8c0@your029b8cecfe> <200808251814.m7PIEFu54645@magenta.juniper.net> <051601c90832$2a87f530$0300a8c0@your029b8cecfe> X-MH-In-Reply-To: "Adrian Farrel" message dated "Wed, 27 Aug 2008 11:46:26 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43155.1219853140.1@juniper.net> Date: Wed, 27 Aug 2008 09:05:40 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 27 Aug 2008 16:05:41.0308 (UTC) FILETIME=[C0E6F7C0:01C9085E] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian, > Hi Yakov, > > You have answered my first question, within the limited scope of basic mode, > single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with > your interpretation. > > This is good, and I support the use of this draft in that limited scenario, > and I suspect that the concept is extensible to any port-based VPN. > > Will you be adding to the draft to say that this is the full extent of the > applicability of this draft (perhaps using RFC 2119 language)? > > If not, then I'm afraid that my question stands. What will happen in the > case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE > links? To address this I would propose to add the following to the Abstract and Introduction: The scope and applicability of this protocol extension currently excludes its use for non-VPN deployment scenarios. Yakov. - > Thanks, > Adrian > > >> >> 1. A CE is attached by parallel links to a single PE > >> >> > >> >> Suppose the links have the same switching types, but > >> >> different bandwidths. Link-a has plenty of bandwidth > >> >> available with an MTU size of x. Link-b has not much > >> >> bandwidth available with an MTU size of y > x. > >> > > >> > Interface MTU is part of the PSC TE attributes in the our spec. If the > >> > MTUs are different they should not be aggregated. > >> > >> Right. Aggregation in this case is hard to make representative of > >> reality. > >> > >> > Also In L1VPN (LSC and TDM) networks the Switching type > >> > covers Switching granularity (which is like an MTU). > >> > >> Sure. But I wanted to keep in PSC, because that problem represents a > >> single > >> layer network. > >> > >> > I'm trying to understand if you are saying the following text would > >> > fix the problem or you see a larger issue: > >> > "Therefore, such routes and the corresponding TE information > >> > SHALL NOT be aggregated unless they share identical Traffic > >> > Engineering Attributes". > >> > >> The question I am asking is - is the solution to this problem to > >> advertise > >> two routes? (Clearly two is a special case of many.) > >> > >> I don't believe that in the general (non-TE case) we would consider the > >> case > >> of two parallel links between CE and PE as route aggregation. The PE > >> would > >> simply advertise reachability (through itself) to the CE. > > > > Let's put the general (non-TE) case aside, and focus on the L1VPN > > scenario. > > > > According to the bgp-auto-discovery and l1vpn-basic-mode drafts in > > the context of L1VPN what is advertised in the BGP auto-discovery > > information is the information about *ports*. Therefore, in the > > context of L1VPN TE information advertisements are associated with > > individual *ports*, not with a particular CE. Which means that if > > a CE is connected to a PE by N ports, then the BGP auto-discovery > > information has to advertise all these N ports, and associated with > > each such advertisement may be the TE information. > > > >> Hence my question below. > >> > >> >> Normally, we would expect the PE to advertise a single > >> >> piece of reachability information for the CE leaving > >> >> the actual choice of links to be made by the PE. > >> >> > >> >> What would the PE advertise in this case? > >> >> - It cannot aggregate the TE information because that > >> >> would imply that there was lots of bandwidth at the > >> >> larger MTU size. > >> >> - It could include duplicate Switching Capability > >> >> Descriptors, but that would need some clarification as > >> >> duplicate descriptors are intended for different > >> >> switching caps in the IGP RFCs. > >> >> - It could advertise two pieces of reachability > >> >> information, but that would be a change to how the > >> >> implementation currently works. > > > > The answer to your question is that if the implementation follows > > the spec, it would advertise information about *ports*. So, if a > > CE has two ports that connect it to a PE, then the PE originates > > two L1VPN advertisements, one per port, each with its own TE > > attribute. > From owner-ccamp@ops.ietf.org Wed Aug 27 11:54:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B878E3A699D for ; Wed, 27 Aug 2008 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mSFwiHkG+Boq for ; Wed, 27 Aug 2008 11:54:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30E4B3A6C61 for ; Wed, 27 Aug 2008 11:54:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYPwq-000Ovl-04 for ccamp-data@psg.com; Wed, 27 Aug 2008 18:40:52 +0000 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYPwl-000OvA-Sg for ccamp@ops.ietf.org; Wed, 27 Aug 2008 18:40:50 +0000 Received: from localhost ([127.0.0.1] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.69) (envelope-from ) id 1KYPwI-0005l0-6x; Wed, 27 Aug 2008 14:40:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Aug 2008 14:40:14 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org In-Reply-To: <200808271602.m7RG2Ju46053@magenta.juniper.net> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> <200808271602.m7RG2Ju46053@magenta.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 12:02 PM 8/27/2008, Yakov Rekhter wrote: >Lou, > > > If you drop the "unless they share identical Traffic Engineering > > Attributes" then we have alignment. > >If they do share identical TE attributes, then there is no >problem to aggregate such routes. So, the current text is correct. > >Yakov. I think you need some additional semantic and aggregation function definition if you want to aggregate. (For example: Does the TE aggregate represent the resources available to *each* route or to *all* the routes? If the latter, what's the distribution function?) Also I think some discussion on impact on scaling is warranted. (consider the case where each tuple from a PE now needs it's own advisement due to dissimilar TE information per port.) Lou From owner-ccamp@ops.ietf.org Thu Aug 28 02:13:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1143A6A0C for ; Thu, 28 Aug 2008 02:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.157 X-Spam-Level: X-Spam-Status: No, score=-0.157 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 LhU1bvgMeki0 for ; Thu, 28 Aug 2008 02:13:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D817A3A6859 for ; Thu, 28 Aug 2008 02:13:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYdD3-000JbN-Of for ccamp-data@psg.com; Thu, 28 Aug 2008 08:50:29 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYdCn-000JWe-R5 for ccamp@ops.ietf.org; Thu, 28 Aug 2008 08:50:24 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7S8nW6N001013 for ; Thu, 28 Aug 2008 09:49:37 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7S8nUnj000944 for ; Thu, 28 Aug 2008 09:49:31 +0100 Message-ID: <07a101c908ea$fc3b8b60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 5284 on User-Defined Errors for RSVP Date: Thu, 28 Aug 2008 09:49:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, FYI Adrian ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, August 28, 2008 12:27 AM Subject: RFC 5284 on User-Defined Errors for RSVP > A new Request for Comments is now available in online RFC libraries. > > RFC 5284 > > Title: User-Defined Errors for RSVP > Author: G. Swallow, A. Farrel > Status: Standards Track > Date: August 2008 > Mailbox: swallow@cisco.com, > adrian@olddog.co.uk > Pages: 9 > Characters: 17452 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-tsvwg-rsvp-user-error-spec-08.txt > > URL: http://www.rfc-editor.org/rfc/rfc5284.txt > > The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object > for communicating errors. That object has a defined format that > permits the definition of 256 error codes. As RSVP has been > developed and extended, the convention has been to be conservative in > defining new error codes. Further, no provision for user-defined > errors exists in RSVP. > > This document defines a USER_ERROR_SPEC to be used in addition to the > ERROR_SPEC to carry additional user information related to errors. > > This document is a product of the Transport Area Working Group Working > Group of the IETF. From owner-ccamp@ops.ietf.org Thu Aug 28 11:17:00 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6650428C2FA for ; Thu, 28 Aug 2008 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 jpUNV-ibKZBw for ; Thu, 28 Aug 2008 11:16:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BEAE28C2EF for ; Thu, 28 Aug 2008 11:16:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYlsB-0003G7-W6 for ccamp-data@psg.com; Thu, 28 Aug 2008 18:05:31 +0000 Received: from [64.18.14.179] (helo=chip3og57.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYls4-0003F2-Iy for ccamp@ops.ietf.org; Thu, 28 Aug 2008 18:05:27 +0000 Received: from source ([66.129.228.6]) by chip3ob57.postini.com ([64.18.6.12]) with SMTP; Thu, 28 Aug 2008 11:05:12 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 09:00:11 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 09:00:11 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 09:00:10 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7SG06u80869; Thu, 28 Aug 2008 09:00:06 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808281600.m7SG06u80869@magenta.juniper.net> To: Lou Berger cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) In-reply-to: References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> <200808271602.m7RG2Ju46053@magenta.juniper.net> X-MH-In-Reply-To: Lou Berger message dated "Wed, 27 Aug 2008 14:40:14 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22123.1219939205.1@juniper.net> Date: Thu, 28 Aug 2008 09:00:05 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 28 Aug 2008 16:00:10.0698 (UTC) FILETIME=[2641A2A0:01C90927] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Lou, > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > >Lou, > > > > > If you drop the "unless they share identical Traffic Engineering > > > Attributes" then we have alignment. > > > >If they do share identical TE attributes, then there is no > >problem to aggregate such routes. So, the current text is correct. > > > >Yakov. > > I think you need some additional semantic and aggregation function > definition if you want to aggregate. (For example: Does the TE > aggregate represent the resources available to *each* route or to > *all* the routes? If the latter, what's the distribution function?) Constructing BGP TE attribute when aggregating routes with identical BGP TE attributes follows procedure of rfc4201. > Also I think some discussion on impact on scaling is > warranted. (consider the case where each tuple from a PE > now needs it's own advisement due to dissimilar TE information per port.) As I said before, the granularity of L1VPN auto-discovery advertisements is a single PE-CE port anyway. So, each tuple from a PE forms its own route anyway. And while on the subject of scaling, please keep in mind that BGP only stores L1VPN routes on PEs that have sites of that VPN connected to them, and on an RR if used, but *not* on any of the P routers. In contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing *all VPN TE information for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based approach scales better than OSPF-based approach. Yakov. From owner-ccamp@ops.ietf.org Thu Aug 28 11:37:34 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9BD33A6A31 for ; Thu, 28 Aug 2008 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 abErQU73AFFH for ; Thu, 28 Aug 2008 11:37:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E36D03A68D5 for ; Thu, 28 Aug 2008 11:37:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYmFs-00060o-2I for ccamp-data@psg.com; Thu, 28 Aug 2008 18:30:00 +0000 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYmFk-0005zi-KY for ccamp@ops.ietf.org; Thu, 28 Aug 2008 18:29:57 +0000 Received: from [216.104.42.195] (helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.69) (envelope-from ) id 1KYmFQ-0001km-4C; Thu, 28 Aug 2008 14:29:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 14:29:25 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Yakov Rekhter , Adrian Farrel ,ccamp@ops.ietf.org, softwires@ietf.org In-Reply-To: <200808281600.m7SG06u80869@magenta.juniper.net> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> <200808271602.m7RG2Ju46053@magenta.juniper.net> <200808281600.m7SG06u80869@magenta.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Yakov, see below. At 12:00 PM 8/28/2008, Yakov Rekhter wrote: >Lou, > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > >Lou, > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > Attributes" then we have alignment. > > > > > >If they do share identical TE attributes, then there is no > > >problem to aggregate such routes. So, the current text is correct. > > > > > >Yakov. > > > > I think you need some additional semantic and aggregation function > > definition if you want to aggregate. (For example: Does the TE > > aggregate represent the resources available to *each* route or to > > *all* the routes? If the latter, what's the distribution function?) > >Constructing BGP TE attribute when aggregating routes with identical >BGP TE attributes follows procedure of rfc4201. ahh, that wasn't obvious. Need some specific language to that effect. > > Also I think some discussion on impact on scaling is > > warranted. (consider the case where each tuple from a PE > > now needs it's own advisement due to dissimilar TE information per port.) > >As I said before, the granularity of L1VPN auto-discovery advertisements >is a single PE-CE port anyway. So, each tuple from a PE >forms its own route anyway. Sure, but as the doc says more than on NLRI can be included in a MP_REACH_NLRI attribute. >And while on the subject of scaling, please keep in mind that BGP >only stores L1VPN routes on PEs that have sites of that VPN connected >to them, and on an RR if used, but *not* on any of the P routers. In >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P >and PE. So, clearly BGP-based approach scales better than OSPF-based >approach. sure this is made clear in the l1vpn document. What isn't made clear is that, per this document, when TE attributes cannot be aggregated, each tuple needs its own MP_REACH_NLRI attribute *and* advertisement. Lou >Yakov. From owner-ccamp@ops.ietf.org Thu Aug 28 16:58:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65DA3A6946 for ; Thu, 28 Aug 2008 16:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 addCSsHyLLrN for ; Thu, 28 Aug 2008 16:58:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2AC13A67CC for ; Thu, 28 Aug 2008 16:58:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrFV-000Bc6-Rp for ccamp-data@psg.com; Thu, 28 Aug 2008 23:49:57 +0000 Received: from [64.18.2.161] (helo=exprod7og104.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrFQ-000BbS-2w for ccamp@ops.ietf.org; Thu, 28 Aug 2008 23:49:55 +0000 Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 28 Aug 2008 16:49:10 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 16:48:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 16:48:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 16:48:02 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7SNlvu08136; Thu, 28 Aug 2008 16:47:59 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200808282347.m7SNlvu08136@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) In-reply-to: References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> <200808271602.m7RG2Ju46053@magenta.juniper.net> <200808281600.m7SG06u80869@magenta.juniper.net> X-MH-In-Reply-To: Lou Berger message dated "Thu, 28 Aug 2008 14:29:25 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62873.1219967277.1@juniper.net> Date: Thu, 28 Aug 2008 16:47:57 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 28 Aug 2008 23:48:02.0233 (UTC) FILETIME=[8231F290:01C90968] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Lou, > Yakov, > see below. > > At 12:00 PM 8/28/2008, Yakov Rekhter wrote: > >Lou, > > > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > > >Lou, > > > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > > Attributes" then we have alignment. > > > > > > > >If they do share identical TE attributes, then there is no > > > >problem to aggregate such routes. So, the current text is correct. > > > > > > > >Yakov. > > > > > > I think you need some additional semantic and aggregation function > > > definition if you want to aggregate. (For example: Does the TE > > > aggregate represent the resources available to *each* route or to > > > *all* the routes? If the latter, what's the distribution function?) > > > >Constructing BGP TE attribute when aggregating routes with identical > >BGP TE attributes follows procedure of rfc4201. > > ahh, that wasn't obvious. Need some specific language to that effect. Sure. To make it obvious I'll add the following: Constructing BGP TE attribute when aggregating routes with identical BGP TE attributes follows procedure of rfc4201. > > > Also I think some discussion on impact on scaling is > > > warranted. (consider the case where each tuple from a PE > > > now needs it's own advisement due to dissimilar TE information per port.) > > > >As I said before, the granularity of L1VPN auto-discovery advertisements > >is a single PE-CE port anyway. So, each tuple from a PE > >forms its own route anyway. > > Sure, but as the doc says more than one NLRI can be included in a > MP_REACH_NLRI attribute. That does not change the number of routes that PEs and RRs have to maintain. > >And while on the subject of scaling, please keep in mind that BGP > >only stores L1VPN routes on PEs that have sites of that VPN connected > >to them, and on an RR if used, but *not* on any of the P routers. In > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P > >and PE. So, clearly BGP-based approach scales better than OSPF-based > >approach. > > sure this is made clear in the l1vpn document. What isn't made clear > is that, per this document, when TE attributes cannot be aggregated, > each tuple needs its own MP_REACH_NLRI attribute *and* > advertisement. It would be quite clear if you would read base BGP spec (which is quoted as a Normative Refence in this document). Quoting Section 3.1 of BGP spec (rfc4271): Multiple routes that have the same path attributes can be advertised in a single UPDATE message by including multiple prefixes in the NLRI field of the UPDATE message. Yakov. From owner-ccamp@ops.ietf.org Fri Aug 29 02:21:55 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50F43A6829 for ; Fri, 29 Aug 2008 02:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1] 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 txxMJ4OFEJZU for ; Fri, 29 Aug 2008 02:21:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C65EC3A6816 for ; Fri, 29 Aug 2008 02:21:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYzyM-0008uW-3T for ccamp-data@psg.com; Fri, 29 Aug 2008 09:08:50 +0000 Received: from [194.113.59.96] (helo=mailrelay2.alcatel.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYzyH-0008tI-K0 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 09:08:47 +0000 Received: from [149.204.107.181] (destgn0t02145.ad1.ad.alcatel.com [149.204.107.181]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m7T97xVC032269; Fri, 29 Aug 2008 11:07:59 +0200 Message-ID: <48B7BC6E.5010705@alcatel-lucent.de> Date: Fri, 29 Aug 2008 11:07:58 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Diego Caviglia CC: stbryant@cisco.com, maarten.vissers@huawei.com, adrian@olddog.co.uk, Italo.Busi@alcatel-lucent.it, francesco.fondelli@gmail.com, julien.meuric@orange-ftgroup.com, ccamp@ops.ietf.org, mpls-tp@ietf.org Subject: Re: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) References: <0428AC48A879ED46A94F39D5665DF684EEAF81@esealmw110.eemea.ericsson.se> In-Reply-To: <0428AC48A879ED46A94F39D5665DF684EEAF81@esealmw110.eemea.ericsson.se> Content-Type: multipart/mixed; boundary="------------060808090408050600000300" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------060808090408050600000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ... resent this mail because it did not appear on the mailing lists :-( .

Hi Diego,


Diego Caviglia wrote: 
Stewart,
           I think i agree here.

Even if i'm coming from sdh i don'e see the need to hane osi capability
in brand new mpls-tp boxes.
I actually do not fully agree here. If, due to historical reasons, the existing DCN
is an OSI network and if the new MPLS-TP boxes will only understand IP and have
to use the existing OSI-based DCN, then the new MPLS-TP boxes need to support
at least tunneling of IP over CLNP tunnels. Otherwise, a dual stack DCN would
indeed be needed (I am assuming here that the existing OSI-only DCN cannot be
turned into an IP-only DCN).


Cheers,
Dieter
Br

Diego

--

--
--------------060808090408050600000300 Content-Type: text/x-vcard; charset=utf-8; name="D_Beller.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D_Beller.vcf" begin:vcard fn:Dieter Beller n:Beller;Dieter org:Alcatel-Lucent, Carrier Business Group;Optics Division - Network & Product Strategy adr:;;Lorenzstrasse 10;Stuttgart;;70435;Germany email;internet:D.Beller@alcatel-lucent.de tel;work:+49 711 821-43125 tel;cell:+49 175 7266874 note;quoted-printable:Alcatel-Lucent Deutschland AG:=0D=0A= =0D=0A= Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026=0D=0A= Vorsitzender des Aufsichtsrats: Michael Oppenhoff=0D=0A= Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger,Al= f Henryk Wulf x-mozilla-html:TRUE version:2.1 end:vcard --------------060808090408050600000300-- From owner-ccamp@ops.ietf.org Fri Aug 29 05:05:02 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4D73A697B for ; Fri, 29 Aug 2008 05:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.147 X-Spam-Level: * X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 1Ovm7l7hBirO for ; Fri, 29 Aug 2008 05:05:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5B673A692C for ; Fri, 29 Aug 2008 05:05:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2ZW-000PeA-Gm for ccamp-data@psg.com; Fri, 29 Aug 2008 11:55:22 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2ZQ-000PdM-RM for ccamp@ops.ietf.org; Fri, 29 Aug 2008 11:55:19 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7TBt5I5000811; Fri, 29 Aug 2008 12:55:06 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7TBt4j1000796; Fri, 29 Aug 2008 12:55:05 +0100 Message-ID: <090901c909ce$123eac60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Greg Bernstein" References: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Subject: RWA Info model as WG I-D Date: Fri, 29 Aug 2008 12:48:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, I heard no objections to this. Authors, please submit as draft-ietf-ccamp-rwa-info-00.txt (Note the subtle change in file name) Please run I-D nits (http://tools.ietf.org/tools/idnits/) and clean up before submission. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, August 05, 2008 5:24 PM Subject: Poll for RWA Info model as WG I-D > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed > to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment Information > Model for Wavelength Switched Optical Networks." That is, the scope is > limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > From owner-ccamp@ops.ietf.org Fri Aug 29 06:06:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F723A692C for ; Fri, 29 Aug 2008 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 Y4nymH5P9dIj for ; Fri, 29 Aug 2008 06:06:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2AA03A6819 for ; Fri, 29 Aug 2008 06:06:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ3RH-0005Gh-CH for ccamp-data@psg.com; Fri, 29 Aug 2008 12:50:55 +0000 Received: from [209.191.85.55] (helo=web36804.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ3RD-0005Fx-89 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 12:50:53 +0000 Received: (qmail 41531 invoked by uid 60001); 29 Aug 2008 12:50:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=T7832ypo8CCQ0FncR08MqQajZoz/cUNQH1f0TQ/qT5HY2/m91bPw2T7gY8dpPCekGSoFZlhOa2jL/jp5AbxKYwFEuICy/iUQMR7JLo9OIV3EERFIytY72I9HP0D7nGxaPUV/yMq/zXUUYumZTOSCTwn7Q/i2EsCuw7vYRvylqNo=; X-YMail-OSG: 7Hwkj3AVM1k.b_JF9I5vZ2vY2xvwVLBNTPFI4e9AxNbBsxphWYGT1Y3.2IW3wRsWfmsXwcJYXF4PvcPC.LNs.hHu6uKo8_pdPnmWScP0Xxzty8P8Oic.y3UzfoBndg-- Received: from [67.102.145.11] by web36804.mail.mud.yahoo.com via HTTP; Fri, 29 Aug 2008 05:50:49 PDT X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218.2 Date: Fri, 29 Aug 2008 05:50:49 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1589213789-1220014249=:41469" Message-ID: <896057.41469.qm@web36804.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-1589213789-1220014249=:41469 Content-Type: text/plain; charset=us-ascii Yakov, You said: ... And while on the subject of scaling, please keep in mind that BGP only stores L1VPN routes on PEs that have sites of that VPN connected to them, and on an RR if used, but *not* on any of the P routers. In contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing *all VPN TE information for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based approach scales better than OSPF-based approach. Yakov. This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs. Regards, Igor --0-1589213789-1220014249=:41469 Content-Type: text/html; charset=us-ascii
Yakov,

You said:

... And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.

This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs.

Regards,
Igor


--0-1589213789-1220014249=:41469-- From owner-ccamp@ops.ietf.org Fri Aug 29 06:44:30 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364473A69DA for ; Fri, 29 Aug 2008 06:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 xOrF0Tsa5dx7 for ; Fri, 29 Aug 2008 06:44:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FCEF3A6859 for ; Fri, 29 Aug 2008 06:44:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ49M-000A7I-4o for ccamp-data@psg.com; Fri, 29 Aug 2008 13:36:28 +0000 Received: from [216.104.33.66] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ49G-000A6Z-23 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 13:36:24 +0000 Received: from [216.104.42.195] (helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.69) (envelope-from ) id 1KZ48d-00018Z-Ej; Fri, 29 Aug 2008 09:35:43 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Aug 2008 09:35:41 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org In-Reply-To: <200808282347.m7SNlvu08136@magenta.juniper.net> References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe> <200808261254.m7QCsJu33149@magenta.juniper.net> <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> <200808271350.m7RDoSu86903@magenta.juniper.net> <200808271602.m7RG2Ju46053@magenta.juniper.net> <200808281600.m7SG06u80869@magenta.juniper.net> <200808282347.m7SNlvu08136@magenta.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Yakov, See below. At 07:47 PM 8/28/2008, Yakov Rekhter wrote: >Lou, > > > Yakov, > > see below. > > > > At 12:00 PM 8/28/2008, Yakov Rekhter wrote: > > >Lou, > > > > > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > > > >Lou, > > > > > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > > > Attributes" then we have alignment. > > > > > > > > > >If they do share identical TE attributes, then there is no > > > > >problem to aggregate such routes. So, the current text is correct. > > > > > > > > > >Yakov. > > > > > > > > I think you need some additional semantic and aggregation function > > > > definition if you want to aggregate. (For example: Does the TE > > > > aggregate represent the resources available to *each* route or to > > > > *all* the routes? If the latter, what's the distribution function?) > > > > > >Constructing BGP TE attribute when aggregating routes with identical > > >BGP TE attributes follows procedure of rfc4201. > > > > ahh, that wasn't obvious. Need some specific language to that effect. > >Sure. To make it obvious I'll add the following: > > Constructing BGP TE attribute when aggregating routes with identical > BGP TE attributes follows procedure of rfc4201. great. > > > > > Also I think some discussion on impact on scaling is > > > > warranted. (consider the case where each tuple from a PE > > > > now needs it's own advisement due to dissimilar TE > information per port.) > > > > > >As I said before, the granularity of L1VPN auto-discovery advertisements > > >is a single PE-CE port anyway. So, each tuple from a PE > > >forms its own route anyway. > > > > Sure, but as the doc says more than one NLRI can be included in a > > MP_REACH_NLRI attribute. > >That does not change the number of routes that PEs and RRs have >to maintain. sure, but there's potential for significant impact on number/size of advertisements and corresponding processing. > > >And while on the subject of scaling, please keep in mind that BGP > > >only stores L1VPN routes on PEs that have sites of that VPN connected > > >to them, and on an RR if used, but *not* on any of the P routers. In > > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing > > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P > > >and PE. So, clearly BGP-based approach scales better than OSPF-based > > >approach. > > > > sure this is made clear in the l1vpn document. What isn't made clear > > is that, per this document, when TE attributes cannot be aggregated, > > each tuple needs its own MP_REACH_NLRI attribute *and* > > advertisement. > >It would be quite clear if you would read base BGP spec (which is >quoted as a Normative Refence in this document). Quoting Section >3.1 of BGP spec (rfc4271): > > Multiple routes that have the same path attributes can be advertised > in a single UPDATE message by including multiple prefixes in the NLRI > field of the UPDATE message. I believe it is both worthwhile and appropriate to discuss how this draft impacts/relates to scaling. In essence, I'm suggesting a similar/parallel to section 5 of rfc 5195. (which also states things that are "quite clear if you would read" BGP specs.) Lou >Yakov. From owner-ccamp@ops.ietf.org Fri Aug 29 08:29:35 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72283A686C for ; Fri, 29 Aug 2008 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 HLKWZLtu4SXQ for ; Fri, 29 Aug 2008 08:29:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB7873A6816 for ; Fri, 29 Aug 2008 08:29:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5mC-000MQg-8y for ccamp-data@psg.com; Fri, 29 Aug 2008 15:20:40 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5m5-000MPk-DG for ccamp@ops.ietf.org; Fri, 29 Aug 2008 15:20:35 +0000 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7TFKHVt001520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 08:20:17 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7TFKHoZ008767; Fri, 29 Aug 2008 08:20:17 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7TFKHwc008751; Fri, 29 Aug 2008 08:20:17 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 08:20:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Date: Fri, 29 Aug 2008 08:20:16 -0700 Message-ID: <51661468CBD1354294533DA79E85955A010A0470@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <896057.41469.qm@web36804.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] BGP TE attr last call by softwires WG (2nd question) Thread-Index: AckJ2Ibk1awXR/VRQEG+Q+ujHHpT7wAEgZVw References: <896057.41469.qm@web36804.mail.mud.yahoo.com> From: "Drake, John E" To: "Igor Bryskin" , "Yakov Rekhter" , "Lou Berger" Cc: "Yakov Rekhter" , "Adrian Farrel" , , X-OriginalArrivalTime: 29 Aug 2008 15:20:17.0387 (UTC) FILETIME=[BE251BB0:01C909EA] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Igor, Doesn't this defeat auto-discovery? I.e., how is a new PE added to a given L1VPN? Thanks, John=20 >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Sent: Friday, August 29, 2008 5:51 AM >To: Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Yakov, > >You said: > > >... And while on the subject of scaling, please keep in mind=20 >that BGP only stores L1VPN routes on PEs that have sites of=20 >that VPN connected to them, and on an RR if used, but *not* on=20 >any of the P routers. In contrast, rfc5252 (OSPF for L1VPN=20 >autodiscovery) results in storing *all VPN TE information for=20 >all the VPNs* on *all* the IGP nodes, both P and PE. So,=20 >clearly BGP-based approach scales better than OSPF-based approach. > >Yakov. > >This is not true in case of multi-instance OSPF: one can build=20 >an overlay interconnecting PEs via one or small number of Ps=20 >using IPinIP tunnels and run in this overlay an instance of=20 >OSPF specifically designated for distribution of L1VPN=20 >information. In this case the OSPF solution won't scale any=20 >worse than the BGP approach. Note. that rfc252 never said that=20 >the instance of OSPF used for flooding of the L1VPN=20 >information must be the same instance that is used for the=20 >distribution of IP-related LSAs. > >Regards, >Igor > > > > From owner-ccamp@ops.ietf.org Fri Aug 29 09:38:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9362D28C11C for ; Fri, 29 Aug 2008 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.153 X-Spam-Level: * X-Spam-Status: No, score=1.153 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 uOpl6tmJsEwG for ; Fri, 29 Aug 2008 09:38:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF3A828C117 for ; Fri, 29 Aug 2008 09:38:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6ru-0005by-QD for ccamp-data@psg.com; Fri, 29 Aug 2008 16:30:38 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6rb-0005ZV-El for ccamp@ops.ietf.org; Fri, 29 Aug 2008 16:30:28 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7TGU47B007616; Fri, 29 Aug 2008 17:30:06 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7TGU3ej007600; Fri, 29 Aug 2008 17:30:03 +0100 Message-ID: <0a8601c909f4$7c014ce0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: Subject: Comments on ITU's Work Plan for Optical Transport Networks Date: Fri, 29 Aug 2008 17:29:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We received a liaison back in February (https://datatracker.ietf.org/liaison/425/) asking for our comments on ITU-T Study Group 15's "Optical Transport Networks & Technologies Standardization Work Plan" (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html) Please let me know by Friday September 5th if you have any comments you would like us to make. If I don't receive anything, I will send a response to thank them for keeping us informed and asking them to share any future work plans with us. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Aug 29 11:19:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1AD3A6A3B for ; Fri, 29 Aug 2008 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.641 X-Spam-Level: X-Spam-Status: No, score=0.641 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 Qp0La8RYCP-s for ; Fri, 29 Aug 2008 11:19:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 393133A6A47 for ; Fri, 29 Aug 2008 11:19:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Rp-000HhL-CO for ccamp-data@psg.com; Fri, 29 Aug 2008 18:11:49 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Ri-000Hfh-P7 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 18:11:46 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7TIBLu3016665; Fri, 29 Aug 2008 19:11:21 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7TIBKTX016657; Fri, 29 Aug 2008 19:11:20 +0100 Message-ID: <0ac301c90a02$a226bd70$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "Ross Callon" , , "Scott Bradner" Subject: Draft response to ITU-T on VCAT Date: Fri, 29 Aug 2008 19:10:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi CCAMP, We have a liaison to respond to from the ITU-T on VCAT (https://datatracker.ietf.org/liaison/429/). Please a draft response below. Comments to me by Friday September 5. Thanks, Adrian ===== The IETF CCAMP working group thanks you for your liaison on GMPLS control of VCAT/LCAS dated February 1st 2008, and received February 29th. Please find our responses in line. > Here are our comments to the responses provided in your liaison: > > a) Regarding your response to Question 1 on protocol > extensibility to encompass technologies other than > SONET/SDH, we notice that the recent I-D > (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the > number of VCGs per call to one. We support this > position and consider this to be a VCAT call. Thank you. Your support is noted. > b) Regarding your response to Question 4 on multiple calls > support, VCAT is viewed as a layer of its own and has its > own call controller. > As per the interlayer architecture in G.8080 section 6.6, > the VCAT call would be associated with a server layer call > or calls, each of which would have/own one or more server > layer connections. It is these connections that are part of the > VCG. In retrospect, a single call is sufficient for diverse > routing as it can hold details of both connections so that they > don't use the same resources. > An example where multiple server calls associated with one > VCAT call would be useful is when all VCAT connections > are to be protected. > Here, rather than one call maintain the knowledge of all > working/protection pairs, it is simpler to have multiple calls > each of which only maintains one working/protection pair. > This is even more convenient when restoration behavior is > applied when the protection connection fails. We note that in a functional architecture it makes good sense to separate the VCAT layer from the server/protection layer. We also observe that the protocol solution does not need to be tied rigidly to the functional architecture where optimizations may be made from collapsing layers into a single set of protocol exchanges. > c) Regarding your response to Question 6 on IP address format in > GMPLS, we suggest the I-D clarifies that there are different name > (or identifier) spaces even though they may all use the same IP > address format, e.g. > - Control component > The identifiers used to identify the entities that perform the > control > plane functions, such as route computation, signaling, control plane > message delivering, etc. > - Transport resource > The identifiers used to identify transport resource when they are > referred to in the control plane messages. Note that these > identifiers > may not be the same as those referred to in the management plane > messages. > - SCN > The addresses used to deliver control plane messages > > Examples of a similar address format in use in two different name > spaces can be seen in the OSPF routing protocol, where router ID > (control and transport link scope) and IP address (used by the > forwarder) do not have to be the same. While we understand that these distinctions are not clear from reading this particular Internet-Draft, we believe that the distinction is clear from the weight of GMPLS RFCs. However, we thank you for pointing out that further clarity could be achieved, and will look at ways to add text to this document. The CCAMP working group is currently entering the final phase of work on this topic. The current version of the draft can be seen at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt and we would welcome any final input from ITU-T SG15 before we complete the publication process. With that in mind, we invite you to review this document and send us any comments before our November meeting. The response date to this liaison is set accordingly. From owner-ccamp@ops.ietf.org Fri Aug 29 11:38:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701673A6A65 for ; Fri, 29 Aug 2008 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 luRLbnllZTGv for ; Fri, 29 Aug 2008 11:38:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D8853A6A11 for ; Fri, 29 Aug 2008 11:38:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8iC-000K9C-PS for ccamp-data@psg.com; Fri, 29 Aug 2008 18:28:44 +0000 Received: from [209.191.85.58] (helo=web36807.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8i8-000K8D-BZ for ccamp@ops.ietf.org; Fri, 29 Aug 2008 18:28:42 +0000 Received: (qmail 98471 invoked by uid 60001); 29 Aug 2008 18:28:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=0c6uKtyovkTjJzFxT0xo9yi+DNSE56b+FyJwwwXi/z80dGc0I+pCnamJNgylkc49zR9demarP+evLc4mXWRtyDmoxkH3Z1t9/KKgCKJhHMlkrgK08lA2/Xo49LLI1Mh+3lIDtRDV35rgHcFB/jHAoY7YfnREUWzmZY+8O00CjhQ=; X-YMail-OSG: 2WLf_uIVM1mfALQa4LtNNwz0h8JGuPxLz_BiXel2KxGxRg94Z89jvVoI3zPHrE5sruoTg9jkLVVWe1zcuv8S0Ch6FOidEQDiIdFnZm8yW2OYcE5CFHnkRPy0dMf8milHaEp6MIf9wKeUOhIfAtc- Received: from [67.102.145.11] by web36807.mail.mud.yahoo.com via HTTP; Fri, 29 Aug 2008 11:28:38 PDT X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218.2 Date: Fri, 29 Aug 2008 11:28:38 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: "Drake, John E" , Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-763070498-1220034518=:96489" Message-ID: <826937.96489.qm@web36807.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-763070498-1220034518=:96489 Content-Type: text/plain; charset=us-ascii Hi John, No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs. Cheers, Igor ----- Original Message ---- From: "Drake, John E" To: Igor Bryskin ; Yakov Rekhter ; Lou Berger Cc: Yakov Rekhter ; Adrian Farrel ; ccamp@ops.ietf.org; softwires@ietf.org Sent: Friday, August 29, 2008 11:20:16 AM Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Igor, Doesn't this defeat auto-discovery? I.e., how is a new PE added to a given L1VPN? Thanks, John >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >Sent: Friday, August 29, 2008 5:51 AM >To: Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Yakov, > >You said: > > >... And while on the subject of scaling, please keep in mind >that BGP only stores L1VPN routes on PEs that have sites of >that VPN connected to them, and on an RR if used, but *not* on >any of the P routers. In contrast, rfc5252 (OSPF for L1VPN >autodiscovery) results in storing *all VPN TE information for >all the VPNs* on *all* the IGP nodes, both P and PE. So, >clearly BGP-based approach scales better than OSPF-based approach. > >Yakov. > >This is not true in case of multi-instance OSPF: one can build >an overlay interconnecting PEs via one or small number of Ps >using IPinIP tunnels and run in this overlay an instance of >OSPF specifically designated for distribution of L1VPN >information. In this case the OSPF solution won't scale any >worse than the BGP approach. Note. that rfc252 never said that >the instance of OSPF used for flooding of the L1VPN >information must be the same instance that is used for the >distribution of IP-related LSAs. > >Regards, >Igor > > > > --0-763070498-1220034518=:96489 Content-Type: text/html; charset=us-ascii
Hi John,

No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs.

Cheers,
Igor

----- Original Message ----
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.net>; Lou Berger <lberger@labn.net>
Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
Sent: Friday, August 29, 2008 11:20:16 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a
given L1VPN?

Thanks,

John

>-----Original Message-----
>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>Sent: Friday, August 29, 2008 5:51 AM
>To: Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>softwires@ietf.org
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Yakov,
>
>You said:
>
>
>... And while on the subject of scaling, please keep in mind
>that BGP only stores L1VPN routes on PEs that have sites of
>that VPN connected to them, and on an RR if used, but *not* on
>any of the P routers. In contrast, rfc5252 (OSPF for L1VPN
>autodiscovery) results in storing *all VPN TE information for
>all the VPNs* on *all* the IGP nodes, both P and PE. So,
>clearly BGP-based approach scales better than OSPF-based approach.
>
>Yakov.
>
>This is not true in case of multi-instance OSPF: one can build
>an overlay interconnecting PEs via one or small number of Ps
>using IPinIP tunnels and run in this overlay an instance of
>OSPF specifically designated for distribution of L1VPN
>information. In this case the OSPF solution won't scale any
>worse than the BGP approach. Note. that rfc252 never said that
>the instance of OSPF used for flooding of the L1VPN
>information must be the same instance that is used for the
>distribution of IP-related LSAs.
>
>Regards,
>Igor
>
>
>
>


--0-763070498-1220034518=:96489-- From owner-ccamp@ops.ietf.org Fri Aug 29 11:38:51 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474783A6A12 for ; Fri, 29 Aug 2008 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 bIkGHe6S54tF for ; Fri, 29 Aug 2008 11:38:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F2803A6A11 for ; Fri, 29 Aug 2008 11:38:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8la-000Kfj-Q2 for ccamp-data@psg.com; Fri, 29 Aug 2008 18:32:14 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8lW-000Keq-Ml for ccamp@ops.ietf.org; Fri, 29 Aug 2008 18:32:12 +0000 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m7TIVc1d012140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Aug 2008 11:31:38 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m7TIVbFd008047; Fri, 29 Aug 2008 13:31:38 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m7TIVbAx008037; Fri, 29 Aug 2008 13:31:37 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 11:31:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Date: Fri, 29 Aug 2008 11:31:36 -0700 Message-ID: <51661468CBD1354294533DA79E85955A010A0555@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <826937.96489.qm@web36807.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] BGP TE attr last call by softwires WG (2nd question) Thread-Index: AckKBRAvps9RfSsHS6ekJW0tSKnVzQAACnKw References: <826937.96489.qm@web36807.mail.mud.yahoo.com> From: "Drake, John E" To: "Igor Bryskin" , "Yakov Rekhter" , "Lou Berger" Cc: "Yakov Rekhter" , "Adrian Farrel" , , X-OriginalArrivalTime: 29 Aug 2008 18:31:37.0415 (UTC) FILETIME=[78C65D70:01C90A05] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: So you are proposing an OSPF route reflector? At what point does the silliness stop?=20 >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Sent: Friday, August 29, 2008 11:29 AM >To: Drake, John E; Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Hi John, > >No, not really. When you add a PE you configure local=20 >interfaces, local VPN port mappings, stuff like that. While=20 >doing this you will also configure an IPinIP tunnel to one of=20 >your spoke Ps and enable L1VPN OSPF instance on the tunnel.=20 >Once you did that the local VPN information will be flooded=20 >accross the overlay, likewise, the new PE will get all the=20 >necessary information from other PEs. > >Cheers, >Igor > > >----- Original Message ---- >From: "Drake, John E" >To: Igor Bryskin ; Yakov Rekhter=20 >; Lou Berger >Cc: Yakov Rekhter ; Adrian Farrel=20 >; ccamp@ops.ietf.org; softwires@ietf.org >Sent: Friday, August 29, 2008 11:20:16 AM >Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Igor, > >Doesn't this defeat auto-discovery? I.e., how is a new PE=20 >added to a given L1VPN? > >Thanks, > >John=20 > >>-----Original Message----- >>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >>Sent: Friday, August 29, 2008 5:51 AM >>To: Yakov Rekhter; Lou Berger >>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >>softwires@ietf.org >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20 >>question) >> >>Yakov, >> >>You said: >> >> >>... And while on the subject of scaling, please keep in mind that BGP=20 >>only stores L1VPN routes on PEs that have sites of that VPN connected=20 >>to them, and on an RR if used, but *not* on any of the P routers. In=20 >>contrast, rfc5252 (OSPF for L1VPN >>autodiscovery) results in storing *all VPN TE information for all the=20 >>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20 >>approach scales better than OSPF-based approach. >> >>Yakov. >> >>This is not true in case of multi-instance OSPF: one can build an=20 >>overlay interconnecting PEs via one or small number of Ps=20 >using IPinIP=20 >>tunnels and run in this overlay an instance of OSPF specifically=20 >>designated for distribution of L1VPN information. In this=20 >case the OSPF=20 >>solution won't scale any worse than the BGP approach. Note.=20 >that rfc252=20 >>never said that the instance of OSPF used for flooding of the L1VPN=20 >>information must be the same instance that is used for the=20 >distribution=20 >>of IP-related LSAs. >> >>Regards, >>Igor >> >> >> >> > > > > From owner-ccamp@ops.ietf.org Fri Aug 29 12:20:21 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DC23A68A7 for ; Fri, 29 Aug 2008 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] 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 odxiFjHNvw7x for ; Fri, 29 Aug 2008 12:20:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FE383A685D for ; Fri, 29 Aug 2008 12:20:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9MR-000PgX-9H for ccamp-data@psg.com; Fri, 29 Aug 2008 19:10:19 +0000 Received: from [209.191.85.52] (helo=web36801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9MM-000Pfs-V8 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 19:10:17 +0000 Received: (qmail 23651 invoked by uid 60001); 29 Aug 2008 19:10:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KnHwlhV8pszx+SUdQ5aXmXUymbEkh5cIW+gV0/QTPfmp9+fke1I6I47W3vLHMqqWW9s4IcXFyh2KDYxIYwuXqTKBnCz+5iBrxnPdY9OakRsB61em/fm4qdbAE80UbmuXkT5bxSZS986pCC6iwvoPkgjnQiI0T7Vm85hIM1kL/I4=; X-YMail-OSG: u.Mrk5cVM1k1ZPNxTfCfE6iikhlk4Dizzh8phmKP4VvgjuwWhUkOtuMClqVuLpkuqQAj0Ag_8eHrtWQYme9vLAbBOVfqM7jfgYIM.lzM3GmQCcV3U3MAB4DnlHFSy0GHjwHGQnRPR6jT2ZpIlHk- Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Fri, 29 Aug 2008 12:10:13 PDT X-Mailer: YahooMailRC/1042.48 YahooMailWebService/0.7.218.2 Date: Fri, 29 Aug 2008 12:10:13 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: "Drake, John E" , Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-575769772-1220037013=:22737" Message-ID: <163244.22737.qm@web36801.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-575769772-1220037013=:22737 Content-Type: text/plain; charset=us-ascii Are you calling me silly? Are you coming to Minneapolis? :=) Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability: a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s); b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process. In my opinion this is exactly what is needed for the OSPF-based L1VPN application. Igor ----- Original Message ---- From: "Drake, John E" To: Igor Bryskin ; Yakov Rekhter ; Lou Berger Cc: Yakov Rekhter ; Adrian Farrel ; ccamp@ops.ietf.org; softwires@ietf.org Sent: Friday, August 29, 2008 2:31:36 PM Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) So you are proposing an OSPF route reflector? At what point does the silliness stop? >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >Sent: Friday, August 29, 2008 11:29 AM >To: Drake, John E; Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Hi John, > >No, not really. When you add a PE you configure local >interfaces, local VPN port mappings, stuff like that. While >doing this you will also configure an IPinIP tunnel to one of >your spoke Ps and enable L1VPN OSPF instance on the tunnel. >Once you did that the local VPN information will be flooded >accross the overlay, likewise, the new PE will get all the >necessary information from other PEs. > >Cheers, >Igor > > >----- Original Message ---- >From: "Drake, John E" >To: Igor Bryskin ; Yakov Rekhter >; Lou Berger >Cc: Yakov Rekhter ; Adrian Farrel >; ccamp@ops.ietf.org; softwires@ietf.org >Sent: Friday, August 29, 2008 11:20:16 AM >Subject: RE: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Igor, > >Doesn't this defeat auto-discovery? I.e., how is a new PE >added to a given L1VPN? > >Thanks, > >John > >>-----Original Message----- >>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >>Sent: Friday, August 29, 2008 5:51 AM >>To: Yakov Rekhter; Lou Berger >>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >>softwires@ietf.org >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd >>question) >> >>Yakov, >> >>You said: >> >> >>... And while on the subject of scaling, please keep in mind that BGP >>only stores L1VPN routes on PEs that have sites of that VPN connected >>to them, and on an RR if used, but *not* on any of the P routers. In >>contrast, rfc5252 (OSPF for L1VPN >>autodiscovery) results in storing *all VPN TE information for all the >>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based >>approach scales better than OSPF-based approach. >> >>Yakov. >> >>This is not true in case of multi-instance OSPF: one can build an >>overlay interconnecting PEs via one or small number of Ps >using IPinIP >>tunnels and run in this overlay an instance of OSPF specifically >>designated for distribution of L1VPN information. In this >case the OSPF >>solution won't scale any worse than the BGP approach. Note. >that rfc252 >>never said that the instance of OSPF used for flooding of the L1VPN >>information must be the same instance that is used for the >distribution >>of IP-related LSAs. >> >>Regards, >>Igor >> >> >> >> > > > > --0-575769772-1220037013=:22737 Content-Type: text/html; charset=us-ascii
Are you calling me silly? Are you coming to Minneapolis? :=)

Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability:
a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s);
b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process.

In my opinion this is exactly what is needed for the OSPF-based L1VPN application.

Igor





----- Original Message ----
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.net>; Lou Berger <lberger@labn.net>
Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
Sent: Friday, August 29, 2008 2:31:36 PM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

So you are proposing an OSPF route reflector?  At what point does the
silliness stop?

>-----Original Message-----
>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>Sent: Friday, August 29, 2008 11:29 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>softwires@ietf.org
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Hi John,
>
>No, not really. When you add a PE you configure local
>interfaces, local VPN port mappings, stuff like that. While
>doing this you will also configure an IPinIP tunnel to one of
>your spoke Ps and enable L1VPN OSPF instance on the tunnel.
>Once you did that the local VPN information will be flooded
>accross the overlay, likewise, the new PE will get all the
>necessary information from other PEs.
>
>Cheers,
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <John.E.Drake2@boeing.com>
>To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter
><yakov@juniper.net>; Lou Berger <lberger@labn.net>
>Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel
><adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
>Sent: Friday, August 29, 2008 11:20:16 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Igor,
>
>Doesn't this defeat auto-discovery?  I.e., how is a new PE
>added to a given L1VPN?
>
>Thanks,
>
>John
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>>Sent: Friday, August 29, 2008 5:51 AM
>>To: Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>>softwires@ietf.org
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>question)
>>
>>Yakov,
>>
>>You said:
>>
>>
>>... And while on the subject of scaling, please keep in mind that BGP
>>only stores L1VPN routes on PEs that have sites of that VPN connected
>>to them, and on an RR if used, but *not* on any of the P routers. In
>>contrast, rfc5252 (OSPF for L1VPN
>>autodiscovery) results in storing *all VPN TE information for all the
>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based
>>approach scales better than OSPF-based approach.
>>
>>Yakov.
>>
>>This is not true in case of multi-instance OSPF: one can build an
>>overlay interconnecting PEs via one or small number of Ps
>using IPinIP
>>tunnels and run in this overlay an instance of OSPF specifically
>>designated for distribution of L1VPN information. In this
>case the OSPF
>>solution won't scale any worse than the BGP approach. Note.
>that rfc252
>>never said that the instance of OSPF used for flooding of the L1VPN
>>information must be the same instance that is used for the
>distribution
>>of IP-related LSAs.
>>
>>Regards,
>>Igor
>>
>>
>>
>>
>
>
>
>

--0-575769772-1220037013=:22737-- From cheepy_1955@BLACKBERRY.NET Sun Aug 31 08:14:01 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F92C3A6B36 for ; Sun, 31 Aug 2008 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.128 X-Spam-Level: X-Spam-Status: No, score=-21.128 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_EJACULA=10.357, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, IMPOTENCE=1.886, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_ADLTSUB1=1.66, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, 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 GYT-JM-c8C6B for ; Sun, 31 Aug 2008 08:14:00 -0700 (PDT) Received: from p4FCABC38.dip0.t-ipconnect.de (p4FCABC38.dip0.t-ipconnect.de [79.202.188.56]) by core3.amsl.com (Postfix) with ESMTP id F3A923A6B24 for ; Sun, 31 Aug 2008 08:13:59 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 19:14:01 +0400 From: ROBERT User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Reduce premature ejaculation Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit She will ride you like she has never done before when you have
upgraded your wang with us. http://www.wandtell.com/
From asamblea30082008@gmail.com Sun Aug 31 22:37:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4153A68EF for ; Sun, 31 Aug 2008 22:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.545 X-Spam-Level: ** X-Spam-Status: No, score=2.545 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] 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 MFucKFgaI8Oo for ; Sun, 31 Aug 2008 22:37:23 -0700 (PDT) Received: from avas-mr19.fibertel.com.ar (avas-mr19.fibertel.com.ar [24.232.0.122]) by core3.amsl.com (Postfix) with ESMTP id 153873A6818 for ; Sun, 31 Aug 2008 22:37:23 -0700 (PDT) Received: from 133-9-245-190.fibertel.com.ar ([190.245.9.133]:4846 "EHLO f3t" smtp-auth: "asamblea30082008" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr19.fibertel.com.ar with ESMTPA id S1191090AbYIAFhW convert rfc822-to-8bit; Mon, 1 Sep 2008 02:37:22 -0300 Message-ID: <3848-220089110376515@f3t> To: "core2duo" From: "asamblea30082008@gmail.com" Subject: COMPUTADORA CORE 2 DUO E7200 + Monitor Samasung LCD 19" Date: Mon, 1 Sep 2008 02:37:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 788c3c6d7746022c9dc9e77f52ddb231 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: asamblea30082008@gmail.com COMPUTADORAS con 1 AÑO DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALLITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS TAMBIEN DISPONIBLES PARA EL INTERIOR. CONSULTE FACTURA A o B CEL: 15-3197-5821 EMail: asamblea30082008@gmail.com -Modelo: CORE 2 DUO -Procesador: E7200 CORE DUO 2.53 3MB cache 775 BOX 3 años de garantia -Motherboard: Asus P5GC-MX Socket 775 BOX -Memoria: DDR2 2GB 667MHZ -Placa de video: PCI-E 512MB NX8400GS-TD256E MSI -Disco rígido: 250GB SATA 2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 integrada -Placa de sonido: 6 canales -Puertos: 2USB frontales y 4USB traseros -Gabinete: SENTEY ATX c2 coolers fuente 500W -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 1/2 -Garantia equipo 12 meses -Sistema operativo instalado y funcionando FULL, todos los programas y utilidades -Monitor: LCD 19" Samsung 943NWX 3 años de garantia -PRECIO $2499 FINAL (IVA inc) Consulte otras configuraciones a medida, notebooks, camaras digitales y mucho mas Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 19:14:21 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KnHwlhV8pszx+SUdQ5aXmXUymbEkh5cIW+gV0/QTPfmp9+fke1I6I47W3vLHMqqWW9s4IcXFyh2KDYxIYwuXqTKBnCz+5iBrxnPdY9OakRsB61em/fm4qdbAE80UbmuXkT5bxSZS986pCC6iwvoPkgjnQiI0T7Vm85hIM1kL/I4=; Date: Fri, 29 Aug 2008 12:10:13 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: "Drake, John E" , Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-575769772-1220037013=:22737" Message-ID: <163244.22737.qm@web36801.mail.mud.yahoo.com> --0-575769772-1220037013=:22737 Content-Type: text/plain; charset=us-ascii Are you calling me silly? Are you coming to Minneapolis? :=) Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability: a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s); b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process. In my opinion this is exactly what is needed for the OSPF-based L1VPN application. Igor ----- Original Message ---- From: "Drake, John E" To: Igor Bryskin ; Yakov Rekhter ; Lou Berger Cc: Yakov Rekhter ; Adrian Farrel ; ccamp@ops.ietf.org; softwires@ietf.org Sent: Friday, August 29, 2008 2:31:36 PM Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) So you are proposing an OSPF route reflector? At what point does the silliness stop? >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >Sent: Friday, August 29, 2008 11:29 AM >To: Drake, John E; Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Hi John, > >No, not really. When you add a PE you configure local >interfaces, local VPN port mappings, stuff like that. While >doing this you will also configure an IPinIP tunnel to one of >your spoke Ps and enable L1VPN OSPF instance on the tunnel. >Once you did that the local VPN information will be flooded >accross the overlay, likewise, the new PE will get all the >necessary information from other PEs. > >Cheers, >Igor > > >----- Original Message ---- >From: "Drake, John E" >To: Igor Bryskin ; Yakov Rekhter >; Lou Berger >Cc: Yakov Rekhter ; Adrian Farrel >; ccamp@ops.ietf.org; softwires@ietf.org >Sent: Friday, August 29, 2008 11:20:16 AM >Subject: RE: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Igor, > >Doesn't this defeat auto-discovery? I.e., how is a new PE >added to a given L1VPN? > >Thanks, > >John > >>-----Original Message----- >>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >>Sent: Friday, August 29, 2008 5:51 AM >>To: Yakov Rekhter; Lou Berger >>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >>softwires@ietf.org >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd >>question) >> >>Yakov, >> >>You said: >> >> >>... And while on the subject of scaling, please keep in mind that BGP >>only stores L1VPN routes on PEs that have sites of that VPN connected >>to them, and on an RR if used, but *not* on any of the P routers. In >>contrast, rfc5252 (OSPF for L1VPN >>autodiscovery) results in storing *all VPN TE information for all the >>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based >>approach scales better than OSPF-based approach. >> >>Yakov. >> >>This is not true in case of multi-instance OSPF: one can build an >>overlay interconnecting PEs via one or small number of Ps >using IPinIP >>tunnels and run in this overlay an instance of OSPF specifically >>designated for distribution of L1VPN information. In this >case the OSPF >>solution won't scale any worse than the BGP approach. Note. >that rfc252 >>never said that the instance of OSPF used for flooding of the L1VPN >>information must be the same instance that is used for the >distribution >>of IP-related LSAs. >> >>Regards, >>Igor >> >> >> >> > > > > --0-575769772-1220037013=:22737 Content-Type: text/html; charset=us-ascii
Are you calling me silly? Are you coming to Minneapolis? :=)

Seriously, what is wrong in your opinion with this approach? Many people are talking about multi-instance IGPs. What they have in mind is improving the IGP scalability:
a) by removing non-IP advertisements from the instance of IGP that manages IP routing/forwarding tables into separate IGP instance(s);
b) by distributing non-IP information only to and via inerested parties leaving the bulk of Ps out of the process.

In my opinion this is exactly what is needed for the OSPF-based L1VPN application.

Igor





----- Original Message ----
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.net>; Lou Berger <lberger@labn.net>
Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
Sent: Friday, August 29, 2008 2:31:36 PM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

So you are proposing an OSPF route reflector?  At what point does the
silliness stop?

>-----Original Message-----
>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>Sent: Friday, August 29, 2008 11:29 AM
>To: Drake, John E; Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>softwires@ietf.org
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Hi John,
>
>No, not really. When you add a PE you configure local
>interfaces, local VPN port mappings, stuff like that. While
>doing this you will also configure an IPinIP tunnel to one of
>your spoke Ps and enable L1VPN OSPF instance on the tunnel.
>Once you did that the local VPN information will be flooded
>accross the overlay, likewise, the new PE will get all the
>necessary information from other PEs.
>
>Cheers,
>Igor
>
>
>----- Original Message ----
>From: "Drake, John E" <John.E.Drake2@boeing.com>
>To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter
><yakov@juniper.net>; Lou Berger <lberger@labn.net>
>Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel
><adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
>Sent: Friday, August 29, 2008 11:20:16 AM
>Subject: RE: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Igor,
>
>Doesn't this defeat auto-discovery?  I.e., how is a new PE
>added to a given L1VPN?
>
>Thanks,
>
>John
>
>>-----Original Message-----
>>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>>Sent: Friday, August 29, 2008 5:51 AM
>>To: Yakov Rekhter; Lou Berger
>>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>>softwires@ietf.org
>>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd
>>question)
>>
>>Yakov,
>>
>>You said:
>>
>>
>>... And while on the subject of scaling, please keep in mind that BGP
>>only stores L1VPN routes on PEs that have sites of that VPN connected
>>to them, and on an RR if used, but *not* on any of the P routers. In
>>contrast, rfc5252 (OSPF for L1VPN
>>autodiscovery) results in storing *all VPN TE information for all the
>>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based
>>approach scales better than OSPF-based approach.
>>
>>Yakov.
>>
>>This is not true in case of multi-instance OSPF: one can build an
>>overlay interconnecting PEs via one or small number of Ps
>using IPinIP
>>tunnels and run in this overlay an instance of OSPF specifically
>>designated for distribution of L1VPN information. In this
>case the OSPF
>>solution won't scale any worse than the BGP approach. Note.
>that rfc252
>>never said that the instance of OSPF used for flooding of the L1VPN
>>information must be the same instance that is used for the
>distribution
>>of IP-related LSAs.
>>
>>Regards,
>>Igor
>>
>>
>>
>>
>
>
>
>

--0-575769772-1220037013=:22737-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 18:35:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Date: Fri, 29 Aug 2008 11:31:36 -0700 Message-ID: <51661468CBD1354294533DA79E85955A010A0555@XCH-SW-5V2.sw.nos.boeing.com> Thread-Topic: [Softwires] BGP TE attr last call by softwires WG (2nd question) Thread-Index: AckKBRAvps9RfSsHS6ekJW0tSKnVzQAACnKw From: "Drake, John E" To: "Igor Bryskin" , "Yakov Rekhter" , "Lou Berger" Cc: "Yakov Rekhter" , "Adrian Farrel" , , So you are proposing an OSPF route reflector? At what point does the silliness stop?=20 >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Sent: Friday, August 29, 2008 11:29 AM >To: Drake, John E; Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Hi John, > >No, not really. When you add a PE you configure local=20 >interfaces, local VPN port mappings, stuff like that. While=20 >doing this you will also configure an IPinIP tunnel to one of=20 >your spoke Ps and enable L1VPN OSPF instance on the tunnel.=20 >Once you did that the local VPN information will be flooded=20 >accross the overlay, likewise, the new PE will get all the=20 >necessary information from other PEs. > >Cheers, >Igor > > >----- Original Message ---- >From: "Drake, John E" >To: Igor Bryskin ; Yakov Rekhter=20 >; Lou Berger >Cc: Yakov Rekhter ; Adrian Farrel=20 >; ccamp@ops.ietf.org; softwires@ietf.org >Sent: Friday, August 29, 2008 11:20:16 AM >Subject: RE: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Igor, > >Doesn't this defeat auto-discovery? I.e., how is a new PE=20 >added to a given L1VPN? > >Thanks, > >John=20 > >>-----Original Message----- >>From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >>Sent: Friday, August 29, 2008 5:51 AM >>To: Yakov Rekhter; Lou Berger >>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >>softwires@ietf.org >>Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd=20 >>question) >> >>Yakov, >> >>You said: >> >> >>... And while on the subject of scaling, please keep in mind that BGP=20 >>only stores L1VPN routes on PEs that have sites of that VPN connected=20 >>to them, and on an RR if used, but *not* on any of the P routers. In=20 >>contrast, rfc5252 (OSPF for L1VPN >>autodiscovery) results in storing *all VPN TE information for all the=20 >>VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based=20 >>approach scales better than OSPF-based approach. >> >>Yakov. >> >>This is not true in case of multi-instance OSPF: one can build an=20 >>overlay interconnecting PEs via one or small number of Ps=20 >using IPinIP=20 >>tunnels and run in this overlay an instance of OSPF specifically=20 >>designated for distribution of L1VPN information. In this=20 >case the OSPF=20 >>solution won't scale any worse than the BGP approach. Note.=20 >that rfc252=20 >>never said that the instance of OSPF used for flooding of the L1VPN=20 >>information must be the same instance that is used for the=20 >distribution=20 >>of IP-related LSAs. >> >>Regards, >>Igor >> >> >> >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 18:32:20 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=0c6uKtyovkTjJzFxT0xo9yi+DNSE56b+FyJwwwXi/z80dGc0I+pCnamJNgylkc49zR9demarP+evLc4mXWRtyDmoxkH3Z1t9/KKgCKJhHMlkrgK08lA2/Xo49LLI1Mh+3lIDtRDV35rgHcFB/jHAoY7YfnREUWzmZY+8O00CjhQ=; Date: Fri, 29 Aug 2008 11:28:38 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: "Drake, John E" , Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-763070498-1220034518=:96489" Message-ID: <826937.96489.qm@web36807.mail.mud.yahoo.com> --0-763070498-1220034518=:96489 Content-Type: text/plain; charset=us-ascii Hi John, No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs. Cheers, Igor ----- Original Message ---- From: "Drake, John E" To: Igor Bryskin ; Yakov Rekhter ; Lou Berger Cc: Yakov Rekhter ; Adrian Farrel ; ccamp@ops.ietf.org; softwires@ietf.org Sent: Friday, August 29, 2008 11:20:16 AM Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Igor, Doesn't this defeat auto-discovery? I.e., how is a new PE added to a given L1VPN? Thanks, John >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com] >Sent: Friday, August 29, 2008 5:51 AM >To: Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org; >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG >(2nd question) > >Yakov, > >You said: > > >... And while on the subject of scaling, please keep in mind >that BGP only stores L1VPN routes on PEs that have sites of >that VPN connected to them, and on an RR if used, but *not* on >any of the P routers. In contrast, rfc5252 (OSPF for L1VPN >autodiscovery) results in storing *all VPN TE information for >all the VPNs* on *all* the IGP nodes, both P and PE. So, >clearly BGP-based approach scales better than OSPF-based approach. > >Yakov. > >This is not true in case of multi-instance OSPF: one can build >an overlay interconnecting PEs via one or small number of Ps >using IPinIP tunnels and run in this overlay an instance of >OSPF specifically designated for distribution of L1VPN >information. In this case the OSPF solution won't scale any >worse than the BGP approach. Note. that rfc252 never said that >the instance of OSPF used for flooding of the L1VPN >information must be the same instance that is used for the >distribution of IP-related LSAs. > >Regards, >Igor > > > > --0-763070498-1220034518=:96489 Content-Type: text/html; charset=us-ascii
Hi John,

No, not really. When you add a PE you configure local interfaces, local VPN port mappings, stuff like that. While doing this you will also configure an IPinIP tunnel to one of your spoke Ps and enable L1VPN OSPF instance on the tunnel. Once you did that the local VPN information will be flooded accross the overlay, likewise, the new PE will get all the necessary information from other PEs.

Cheers,
Igor

----- Original Message ----
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Yakov Rekhter <yakov@juniper.net>; Lou Berger <lberger@labn.net>
Cc: Yakov Rekhter <yakov@juniper.net>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org; softwires@ietf.org
Sent: Friday, August 29, 2008 11:20:16 AM
Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question)

Igor,

Doesn't this defeat auto-discovery?  I.e., how is a new PE added to a
given L1VPN?

Thanks,

John

>-----Original Message-----
>From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
>Sent: Friday, August 29, 2008 5:51 AM
>To: Yakov Rekhter; Lou Berger
>Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;
>softwires@ietf.org
>Subject: Re: [Softwires] BGP TE attr last call by softwires WG
>(2nd question)
>
>Yakov,
>
>You said:
>
>
>... And while on the subject of scaling, please keep in mind
>that BGP only stores L1VPN routes on PEs that have sites of
>that VPN connected to them, and on an RR if used, but *not* on
>any of the P routers. In contrast, rfc5252 (OSPF for L1VPN
>autodiscovery) results in storing *all VPN TE information for
>all the VPNs* on *all* the IGP nodes, both P and PE. So,
>clearly BGP-based approach scales better than OSPF-based approach.
>
>Yakov.
>
>This is not true in case of multi-instance OSPF: one can build
>an overlay interconnecting PEs via one or small number of Ps
>using IPinIP tunnels and run in this overlay an instance of
>OSPF specifically designated for distribution of L1VPN
>information. In this case the OSPF solution won't scale any
>worse than the BGP approach. Note. that rfc252 never said that
>the instance of OSPF used for flooding of the L1VPN
>information must be the same instance that is used for the
>distribution of IP-related LSAs.
>
>Regards,
>Igor
>
>
>
>


--0-763070498-1220034518=:96489-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 18:15:45 +0000 Message-ID: <0ac301c90a02$a226bd70$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Brungard, Deborah A, ALABS" , "Ross Callon" , , "Scott Bradner" Subject: Draft response to ITU-T on VCAT Date: Fri, 29 Aug 2008 19:10:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi CCAMP, We have a liaison to respond to from the ITU-T on VCAT (https://datatracker.ietf.org/liaison/429/). Please a draft response below. Comments to me by Friday September 5. Thanks, Adrian ===== The IETF CCAMP working group thanks you for your liaison on GMPLS control of VCAT/LCAS dated February 1st 2008, and received February 29th. Please find our responses in line. > Here are our comments to the responses provided in your liaison: > > a) Regarding your response to Question 1 on protocol > extensibility to encompass technologies other than > SONET/SDH, we notice that the recent I-D > (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the > number of VCGs per call to one. We support this > position and consider this to be a VCAT call. Thank you. Your support is noted. > b) Regarding your response to Question 4 on multiple calls > support, VCAT is viewed as a layer of its own and has its > own call controller. > As per the interlayer architecture in G.8080 section 6.6, > the VCAT call would be associated with a server layer call > or calls, each of which would have/own one or more server > layer connections. It is these connections that are part of the > VCG. In retrospect, a single call is sufficient for diverse > routing as it can hold details of both connections so that they > don't use the same resources. > An example where multiple server calls associated with one > VCAT call would be useful is when all VCAT connections > are to be protected. > Here, rather than one call maintain the knowledge of all > working/protection pairs, it is simpler to have multiple calls > each of which only maintains one working/protection pair. > This is even more convenient when restoration behavior is > applied when the protection connection fails. We note that in a functional architecture it makes good sense to separate the VCAT layer from the server/protection layer. We also observe that the protocol solution does not need to be tied rigidly to the functional architecture where optimizations may be made from collapsing layers into a single set of protocol exchanges. > c) Regarding your response to Question 6 on IP address format in > GMPLS, we suggest the I-D clarifies that there are different name > (or identifier) spaces even though they may all use the same IP > address format, e.g. > - Control component > The identifiers used to identify the entities that perform the > control > plane functions, such as route computation, signaling, control plane > message delivering, etc. > - Transport resource > The identifiers used to identify transport resource when they are > referred to in the control plane messages. Note that these > identifiers > may not be the same as those referred to in the management plane > messages. > - SCN > The addresses used to deliver control plane messages > > Examples of a similar address format in use in two different name > spaces can be seen in the OSPF routing protocol, where router ID > (control and transport link scope) and IP address (used by the > forwarder) do not have to be the same. While we understand that these distinctions are not clear from reading this particular Internet-Draft, we believe that the distinction is clear from the weight of GMPLS RFCs. However, we thank you for pointing out that further clarity could be achieved, and will look at ways to add text to this document. The CCAMP working group is currently entering the final phase of work on this topic. The current version of the draft can be seen at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt and we would welcome any final input from ITU-T SG15 before we complete the publication process. With that in mind, we invite you to review this document and send us any comments before our November meeting. The response date to this liaison is set accordingly. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 16:34:31 +0000 Message-ID: <0a8601c909f4$7c014ce0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: Subject: Comments on ITU's Work Plan for Optical Transport Networks Date: Fri, 29 Aug 2008 17:29:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We received a liaison back in February (https://datatracker.ietf.org/liaison/425/) asking for our comments on ITU-T Study Group 15's "Optical Transport Networks & Technologies Standardization Work Plan" (http://www.itu.int/ITU-T/studygroups/com15/otn/index.html) Please let me know by Friday September 5th if you have any comments you would like us to make. If I don't receive anything, I will send a response to thank them for keeping us informed and asking them to share any future work plans with us. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 15:24:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Softwires] BGP TE attr last call by softwires WG (2nd question) Date: Fri, 29 Aug 2008 08:20:16 -0700 Message-ID: <51661468CBD1354294533DA79E85955A010A0470@XCH-SW-5V2.sw.nos.boeing.com> Thread-Topic: [Softwires] BGP TE attr last call by softwires WG (2nd question) Thread-Index: AckJ2Ibk1awXR/VRQEG+Q+ujHHpT7wAEgZVw From: "Drake, John E" To: "Igor Bryskin" , "Yakov Rekhter" , "Lou Berger" Cc: "Yakov Rekhter" , "Adrian Farrel" , , Igor, Doesn't this defeat auto-discovery? I.e., how is a new PE added to a given L1VPN? Thanks, John=20 >-----Original Message----- >From: Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Sent: Friday, August 29, 2008 5:51 AM >To: Yakov Rekhter; Lou Berger >Cc: Yakov Rekhter; Adrian Farrel; ccamp@ops.ietf.org;=20 >softwires@ietf.org >Subject: Re: [Softwires] BGP TE attr last call by softwires WG=20 >(2nd question) > >Yakov, > >You said: > > >... And while on the subject of scaling, please keep in mind=20 >that BGP only stores L1VPN routes on PEs that have sites of=20 >that VPN connected to them, and on an RR if used, but *not* on=20 >any of the P routers. In contrast, rfc5252 (OSPF for L1VPN=20 >autodiscovery) results in storing *all VPN TE information for=20 >all the VPNs* on *all* the IGP nodes, both P and PE. So,=20 >clearly BGP-based approach scales better than OSPF-based approach. > >Yakov. > >This is not true in case of multi-instance OSPF: one can build=20 >an overlay interconnecting PEs via one or small number of Ps=20 >using IPinIP tunnels and run in this overlay an instance of=20 >OSPF specifically designated for distribution of L1VPN=20 >information. In this case the OSPF solution won't scale any=20 >worse than the BGP approach. Note. that rfc252 never said that=20 >the instance of OSPF used for flooding of the L1VPN=20 >information must be the same instance that is used for the=20 >distribution of IP-related LSAs. > >Regards, >Igor > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 13:40:08 +0000 Date: Fri, 29 Aug 2008 09:35:41 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Yakov, See below. At 07:47 PM 8/28/2008, Yakov Rekhter wrote: >Lou, > > > Yakov, > > see below. > > > > At 12:00 PM 8/28/2008, Yakov Rekhter wrote: > > >Lou, > > > > > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > > > >Lou, > > > > > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > > > Attributes" then we have alignment. > > > > > > > > > >If they do share identical TE attributes, then there is no > > > > >problem to aggregate such routes. So, the current text is correct. > > > > > > > > > >Yakov. > > > > > > > > I think you need some additional semantic and aggregation function > > > > definition if you want to aggregate. (For example: Does the TE > > > > aggregate represent the resources available to *each* route or to > > > > *all* the routes? If the latter, what's the distribution function?) > > > > > >Constructing BGP TE attribute when aggregating routes with identical > > >BGP TE attributes follows procedure of rfc4201. > > > > ahh, that wasn't obvious. Need some specific language to that effect. > >Sure. To make it obvious I'll add the following: > > Constructing BGP TE attribute when aggregating routes with identical > BGP TE attributes follows procedure of rfc4201. great. > > > > > Also I think some discussion on impact on scaling is > > > > warranted. (consider the case where each tuple from a PE > > > > now needs it's own advisement due to dissimilar TE > information per port.) > > > > > >As I said before, the granularity of L1VPN auto-discovery advertisements > > >is a single PE-CE port anyway. So, each tuple from a PE > > >forms its own route anyway. > > > > Sure, but as the doc says more than one NLRI can be included in a > > MP_REACH_NLRI attribute. > >That does not change the number of routes that PEs and RRs have >to maintain. sure, but there's potential for significant impact on number/size of advertisements and corresponding processing. > > >And while on the subject of scaling, please keep in mind that BGP > > >only stores L1VPN routes on PEs that have sites of that VPN connected > > >to them, and on an RR if used, but *not* on any of the P routers. In > > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing > > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P > > >and PE. So, clearly BGP-based approach scales better than OSPF-based > > >approach. > > > > sure this is made clear in the l1vpn document. What isn't made clear > > is that, per this document, when TE attributes cannot be aggregated, > > each tuple needs its own MP_REACH_NLRI attribute *and* > > advertisement. > >It would be quite clear if you would read base BGP spec (which is >quoted as a Normative Refence in this document). Quoting Section >3.1 of BGP spec (rfc4271): > > Multiple routes that have the same path attributes can be advertised > in a single UPDATE message by including multiple prefixes in the NLRI > field of the UPDATE message. I believe it is both worthwhile and appropriate to discuss how this draft impacts/relates to scaling. In essence, I'm suggesting a similar/parallel to section 5 of rfc 5195. (which also states things that are "quite clear if you would read" BGP specs.) Lou >Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 12:56:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=T7832ypo8CCQ0FncR08MqQajZoz/cUNQH1f0TQ/qT5HY2/m91bPw2T7gY8dpPCekGSoFZlhOa2jL/jp5AbxKYwFEuICy/iUQMR7JLo9OIV3EERFIytY72I9HP0D7nGxaPUV/yMq/zXUUYumZTOSCTwn7Q/i2EsCuw7vYRvylqNo=; Date: Fri, 29 Aug 2008 05:50:49 -0700 (PDT) From: Igor Bryskin Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) To: Yakov Rekhter , Lou Berger Cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1589213789-1220014249=:41469" Message-ID: <896057.41469.qm@web36804.mail.mud.yahoo.com> --0-1589213789-1220014249=:41469 Content-Type: text/plain; charset=us-ascii Yakov, You said: ... And while on the subject of scaling, please keep in mind that BGP only stores L1VPN routes on PEs that have sites of that VPN connected to them, and on an RR if used, but *not* on any of the P routers. In contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing *all VPN TE information for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based approach scales better than OSPF-based approach. Yakov. This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs. Regards, Igor --0-1589213789-1220014249=:41469 Content-Type: text/html; charset=us-ascii
Yakov,

You said:

... And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.

This is not true in case of multi-instance OSPF: one can build an overlay interconnecting PEs via one or small number of Ps using IPinIP tunnels and run in this overlay an instance of OSPF specifically designated for distribution of L1VPN information. In this case the OSPF solution won't scale any worse than the BGP approach. Note. that rfc252 never said that the instance of OSPF used for flooding of the L1VPN information must be the same instance that is used for the distribution of IP-related LSAs.

Regards,
Igor


--0-1589213789-1220014249=:41469-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 11:59:44 +0000 Message-ID: <090901c909ce$123eac60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Greg Bernstein" Subject: RWA Info model as WG I-D Date: Fri, 29 Aug 2008 12:48:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, I heard no objections to this. Authors, please submit as draft-ietf-ccamp-rwa-info-00.txt (Note the subtle change in file name) Please run I-D nits (http://tools.ietf.org/tools/idnits/) and clean up before submission. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, August 05, 2008 5:24 PM Subject: Poll for RWA Info model as WG I-D > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed > to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment Information > Model for Wavelength Switched Optical Networks." That is, the scope is > limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Aug 2008 09:12:52 +0000 Message-ID: <48B7BC6E.5010705@alcatel-lucent.de> Date: Fri, 29 Aug 2008 11:07:58 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Diego Caviglia CC: stbryant@cisco.com, maarten.vissers@huawei.com, adrian@olddog.co.uk, Italo.Busi@alcatel-lucent.it, francesco.fondelli@gmail.com, julien.meuric@orange-ftgroup.com, ccamp@ops.ietf.org, mpls-tp@ietf.org Subject: Re: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Content-Type: multipart/mixed; boundary="------------060808090408050600000300" This is a multi-part message in MIME format. --------------060808090408050600000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ... resent this mail because it did not appear on the mailing lists :-( .

Hi Diego,


Diego Caviglia wrote: 
Stewart,
           I think i agree here.

Even if i'm coming from sdh i don'e see the need to hane osi capability
in brand new mpls-tp boxes.
I actually do not fully agree here. If, due to historical reasons, the existing DCN
is an OSI network and if the new MPLS-TP boxes will only understand IP and have
to use the existing OSI-based DCN, then the new MPLS-TP boxes need to support
at least tunneling of IP over CLNP tunnels. Otherwise, a dual stack DCN would
indeed be needed (I am assuming here that the existing OSI-only DCN cannot be
turned into an IP-only DCN).


Cheers,
Dieter
Br

Diego

--

--
--------------060808090408050600000300 Content-Type: text/x-vcard; charset=utf-8; name="D_Beller.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D_Beller.vcf" begin:vcard fn:Dieter Beller n:Beller;Dieter org:Alcatel-Lucent, Carrier Business Group;Optics Division - Network & Product Strategy adr:;;Lorenzstrasse 10;Stuttgart;;70435;Germany email;internet:D.Beller@alcatel-lucent.de tel;work:+49 711 821-43125 tel;cell:+49 175 7266874 note;quoted-printable:Alcatel-Lucent Deutschland AG:=0D=0A= =0D=0A= Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026=0D=0A= Vorsitzender des Aufsichtsrats: Michael Oppenhoff=0D=0A= Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger,Al= f Henryk Wulf x-mozilla-html:TRUE version:2.1 end:vcard --------------060808090408050600000300-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Aug 2008 23:54:10 +0000 Message-Id: <200808282347.m7SNlvu08136@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62873.1219967277.1@juniper.net> Date: Thu, 28 Aug 2008 16:47:57 -0700 From: Yakov Rekhter Lou, > Yakov, > see below. > > At 12:00 PM 8/28/2008, Yakov Rekhter wrote: > >Lou, > > > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > > >Lou, > > > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > > Attributes" then we have alignment. > > > > > > > >If they do share identical TE attributes, then there is no > > > >problem to aggregate such routes. So, the current text is correct. > > > > > > > >Yakov. > > > > > > I think you need some additional semantic and aggregation function > > > definition if you want to aggregate. (For example: Does the TE > > > aggregate represent the resources available to *each* route or to > > > *all* the routes? If the latter, what's the distribution function?) > > > >Constructing BGP TE attribute when aggregating routes with identical > >BGP TE attributes follows procedure of rfc4201. > > ahh, that wasn't obvious. Need some specific language to that effect. Sure. To make it obvious I'll add the following: Constructing BGP TE attribute when aggregating routes with identical BGP TE attributes follows procedure of rfc4201. > > > Also I think some discussion on impact on scaling is > > > warranted. (consider the case where each tuple from a PE > > > now needs it's own advisement due to dissimilar TE information per port.) > > > >As I said before, the granularity of L1VPN auto-discovery advertisements > >is a single PE-CE port anyway. So, each tuple from a PE > >forms its own route anyway. > > Sure, but as the doc says more than one NLRI can be included in a > MP_REACH_NLRI attribute. That does not change the number of routes that PEs and RRs have to maintain. > >And while on the subject of scaling, please keep in mind that BGP > >only stores L1VPN routes on PEs that have sites of that VPN connected > >to them, and on an RR if used, but *not* on any of the P routers. In > >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing > >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P > >and PE. So, clearly BGP-based approach scales better than OSPF-based > >approach. > > sure this is made clear in the l1vpn document. What isn't made clear > is that, per this document, when TE attributes cannot be aggregated, > each tuple needs its own MP_REACH_NLRI attribute *and* > advertisement. It would be quite clear if you would read base BGP spec (which is quoted as a Normative Refence in this document). Quoting Section 3.1 of BGP spec (rfc4271): Multiple routes that have the same path attributes can be advertised in a single UPDATE message by including multiple prefixes in the NLRI field of the UPDATE message. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Aug 2008 18:33:47 +0000 Date: Thu, 28 Aug 2008 14:29:25 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Yakov Rekhter , Adrian Farrel ,ccamp@ops.ietf.org, softwires@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Yakov, see below. At 12:00 PM 8/28/2008, Yakov Rekhter wrote: >Lou, > > > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > > >Lou, > > > > > > > If you drop the "unless they share identical Traffic Engineering > > > > Attributes" then we have alignment. > > > > > >If they do share identical TE attributes, then there is no > > >problem to aggregate such routes. So, the current text is correct. > > > > > >Yakov. > > > > I think you need some additional semantic and aggregation function > > definition if you want to aggregate. (For example: Does the TE > > aggregate represent the resources available to *each* route or to > > *all* the routes? If the latter, what's the distribution function?) > >Constructing BGP TE attribute when aggregating routes with identical >BGP TE attributes follows procedure of rfc4201. ahh, that wasn't obvious. Need some specific language to that effect. > > Also I think some discussion on impact on scaling is > > warranted. (consider the case where each tuple from a PE > > now needs it's own advisement due to dissimilar TE information per port.) > >As I said before, the granularity of L1VPN auto-discovery advertisements >is a single PE-CE port anyway. So, each tuple from a PE >forms its own route anyway. Sure, but as the doc says more than on NLRI can be included in a MP_REACH_NLRI attribute. >And while on the subject of scaling, please keep in mind that BGP >only stores L1VPN routes on PEs that have sites of that VPN connected >to them, and on an RR if used, but *not* on any of the P routers. In >contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing >*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P >and PE. So, clearly BGP-based approach scales better than OSPF-based >approach. sure this is made clear in the l1vpn document. What isn't made clear is that, per this document, when TE attributes cannot be aggregated, each tuple needs its own MP_REACH_NLRI attribute *and* advertisement. Lou >Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Aug 2008 18:09:42 +0000 Message-Id: <200808281600.m7SG06u80869@magenta.juniper.net> To: Lou Berger cc: Yakov Rekhter , Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22123.1219939205.1@juniper.net> Date: Thu, 28 Aug 2008 09:00:05 -0700 From: Yakov Rekhter Lou, > At 12:02 PM 8/27/2008, Yakov Rekhter wrote: > >Lou, > > > > > If you drop the "unless they share identical Traffic Engineering > > > Attributes" then we have alignment. > > > >If they do share identical TE attributes, then there is no > >problem to aggregate such routes. So, the current text is correct. > > > >Yakov. > > I think you need some additional semantic and aggregation function > definition if you want to aggregate. (For example: Does the TE > aggregate represent the resources available to *each* route or to > *all* the routes? If the latter, what's the distribution function?) Constructing BGP TE attribute when aggregating routes with identical BGP TE attributes follows procedure of rfc4201. > Also I think some discussion on impact on scaling is > warranted. (consider the case where each tuple from a PE > now needs it's own advisement due to dissimilar TE information per port.) As I said before, the granularity of L1VPN auto-discovery advertisements is a single PE-CE port anyway. So, each tuple from a PE forms its own route anyway. And while on the subject of scaling, please keep in mind that BGP only stores L1VPN routes on PEs that have sites of that VPN connected to them, and on an RR if used, but *not* on any of the P routers. In contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing *all VPN TE information for all the VPNs* on *all* the IGP nodes, both P and PE. So, clearly BGP-based approach scales better than OSPF-based approach. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Aug 2008 08:59:21 +0000 Message-ID: <07a101c908ea$fc3b8b60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 5284 on User-Defined Errors for RSVP Date: Thu, 28 Aug 2008 09:49:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, FYI Adrian ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, August 28, 2008 12:27 AM Subject: RFC 5284 on User-Defined Errors for RSVP > A new Request for Comments is now available in online RFC libraries. > > RFC 5284 > > Title: User-Defined Errors for RSVP > Author: G. Swallow, A. Farrel > Status: Standards Track > Date: August 2008 > Mailbox: swallow@cisco.com, > adrian@olddog.co.uk > Pages: 9 > Characters: 17452 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-tsvwg-rsvp-user-error-spec-08.txt > > URL: http://www.rfc-editor.org/rfc/rfc5284.txt > > The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object > for communicating errors. That object has a defined format that > permits the definition of 256 error codes. As RSVP has been > developed and extended, the convention has been to be conservative in > defining new error codes. Further, no provision for user-defined > errors exists in RSVP. > > This document defines a USER_ERROR_SPEC to be used in addition to the > ERROR_SPEC to carry additional user information related to errors. > > This document is a product of the Transport Area Working Group Working > Group of the IETF. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 18:42:21 +0000 Date: Wed, 27 Aug 2008 14:40:14 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: At 12:02 PM 8/27/2008, Yakov Rekhter wrote: >Lou, > > > If you drop the "unless they share identical Traffic Engineering > > Attributes" then we have alignment. > >If they do share identical TE attributes, then there is no >problem to aggregate such routes. So, the current text is correct. > >Yakov. I think you need some additional semantic and aggregation function definition if you want to aggregate. (For example: Does the TE aggregate represent the resources available to *each* route or to *all* the routes? If the latter, what's the distribution function?) Also I think some discussion on impact on scaling is warranted. (consider the case where each tuple from a PE now needs it's own advisement due to dissimilar TE information per port.) Lou Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 17:22:21 +0000 Message-Id: <200808271605.m7RG5eu48071@magenta.juniper.net> To: "Adrian Farrel" cc: "Don Fedyk" , softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43155.1219853140.1@juniper.net> Date: Wed, 27 Aug 2008 09:05:40 -0700 From: Yakov Rekhter Adrian, > Hi Yakov, > > You have answered my first question, within the limited scope of basic mode, > single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with > your interpretation. > > This is good, and I support the use of this draft in that limited scenario, > and I suspect that the concept is extensible to any port-based VPN. > > Will you be adding to the draft to say that this is the full extent of the > applicability of this draft (perhaps using RFC 2119 language)? > > If not, then I'm afraid that my question stands. What will happen in the > case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE > links? To address this I would propose to add the following to the Abstract and Introduction: The scope and applicability of this protocol extension currently excludes its use for non-VPN deployment scenarios. Yakov. - > Thanks, > Adrian > > >> >> 1. A CE is attached by parallel links to a single PE > >> >> > >> >> Suppose the links have the same switching types, but > >> >> different bandwidths. Link-a has plenty of bandwidth > >> >> available with an MTU size of x. Link-b has not much > >> >> bandwidth available with an MTU size of y > x. > >> > > >> > Interface MTU is part of the PSC TE attributes in the our spec. If the > >> > MTUs are different they should not be aggregated. > >> > >> Right. Aggregation in this case is hard to make representative of > >> reality. > >> > >> > Also In L1VPN (LSC and TDM) networks the Switching type > >> > covers Switching granularity (which is like an MTU). > >> > >> Sure. But I wanted to keep in PSC, because that problem represents a > >> single > >> layer network. > >> > >> > I'm trying to understand if you are saying the following text would > >> > fix the problem or you see a larger issue: > >> > "Therefore, such routes and the corresponding TE information > >> > SHALL NOT be aggregated unless they share identical Traffic > >> > Engineering Attributes". > >> > >> The question I am asking is - is the solution to this problem to > >> advertise > >> two routes? (Clearly two is a special case of many.) > >> > >> I don't believe that in the general (non-TE case) we would consider the > >> case > >> of two parallel links between CE and PE as route aggregation. The PE > >> would > >> simply advertise reachability (through itself) to the CE. > > > > Let's put the general (non-TE) case aside, and focus on the L1VPN > > scenario. > > > > According to the bgp-auto-discovery and l1vpn-basic-mode drafts in > > the context of L1VPN what is advertised in the BGP auto-discovery > > information is the information about *ports*. Therefore, in the > > context of L1VPN TE information advertisements are associated with > > individual *ports*, not with a particular CE. Which means that if > > a CE is connected to a PE by N ports, then the BGP auto-discovery > > information has to advertise all these N ports, and associated with > > each such advertisement may be the TE information. > > > >> Hence my question below. > >> > >> >> Normally, we would expect the PE to advertise a single > >> >> piece of reachability information for the CE leaving > >> >> the actual choice of links to be made by the PE. > >> >> > >> >> What would the PE advertise in this case? > >> >> - It cannot aggregate the TE information because that > >> >> would imply that there was lots of bandwidth at the > >> >> larger MTU size. > >> >> - It could include duplicate Switching Capability > >> >> Descriptors, but that would need some clarification as > >> >> duplicate descriptors are intended for different > >> >> switching caps in the IGP RFCs. > >> >> - It could advertise two pieces of reachability > >> >> information, but that would be a change to how the > >> >> implementation currently works. > > > > The answer to your question is that if the implementation follows > > the spec, it would advertise information about *ports*. So, if a > > CE has two ports that connect it to a PE, then the PE originates > > two L1VPN advertisements, one per port, each with its own TE > > attribute. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 16:16:01 +0000 Message-Id: <200808271602.m7RG2Ju46053@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42761.1219852939.1@juniper.net> Date: Wed, 27 Aug 2008 09:02:19 -0700 From: Yakov Rekhter Lou, > If you drop the "unless they share identical Traffic Engineering > Attributes" then we have alignment. If they do share identical TE attributes, then there is no problem to aggregate such routes. So, the current text is correct. Yakov. > > Lou > > At 09:50 AM 8/27/2008, Yakov Rekhter wrote: > >Lou, > > > > > Why "SHOULD NOT" rather than "MUST NOT"? > > > >It is already there (Section 4): > > > > Routes that carry the Traffic Engineering Attribute have additional > > semantics that could affect traffic forwarding behavior. Therefore, > > such routes SHALL NOT be aggregated unless they share identical > > Traffic Engineering Attributes. > > > >Yakov. > > > > > > > > Lou > > > > > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > > > >Hi again Yakov, > > > > > > > >Thanks also for the reply to my second question. > > > > > > > >Your answer seems to imply that the applicability of your work is strict ly > > > >limited to L1VPNs. > > > > > > > >If this is the case, we can easily close this discussion by adding text to > > > >the Abstract and Introduction such as: > > > > > > > > The scope and applicability of this protocol extension is > > > > currently limited to single-AS deployment scenarios of the > > > > basic mode of L1VPNs. Further applications are for > > > > future study, but these mechanisms SHOULD NOT be > > > > used in any attempt to support TE aggregation. > > > > > > > >Cheers, > > > >Adrian > > > > > > > > >> 2. There is more than one AS > > > > >> > > > > >> Consider > > > > >> > > > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > > > >> > > > > >> PE2 advertises reachability to CE2 and includes TE > > > > >> information. The TE attribute is non-transitive so it is > > > > >> not just passed on, but ASBR2 wants to announce > > > > >> reachability to CE2 (in the VPN case, we may want to > > > > >> support a multi-AS VPN). > > > > >> > > > > >> So ASBR2 can advertise reachability to CE2, but what TE > > > >> parameters does it advertise? The parameters for the > > > > >> link PE2-CE2 are not so helpful because the TE > > > > >> reachability across AS2 may be different. Yet any attempt > > > > >> to perform a computation of the TE reachability across > > > > >> AS2 (i.e. TE aggregation) is complex and potentially > > > > >> unstable. (Of course, if a tunnel is pre-established > > > > >> between ASBR2 and PE2 this is a different matter.) > > > > >> > > > > >> I think that these two different scenarios need attention > > > > >> in the I-D. > > > > >> > > > > >> For the first one, it may just be a matter of indicating > > > > >> which approach is to be used. > > > > >> > > > > >> For the second one, I hope the answer is to recommend > > > > >> against any form of TE aggregation. This could easily be > > > > >> added to section 4, and I would be happy to provide text. > > > > >> BUT, it will still leave open the question about if and how > > > > >> TE information is propagated beyond the AS. > > > > > > > > > > For the second one the answer is in rfc5251: > > > > > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires furthe r > > > > > analysis beyond the scope of this document. > > > > > > > >_______________________________________________ > > > >Softwires mailing list > > > >Softwires@ietf.org > > > >https://www.ietf.org/mailman/listinfo/softwires > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 14:30:40 +0000 Date: Wed, 27 Aug 2008 10:29:15 -0400 To: Yakov Rekhter From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: Lou Berger ,Adrian Farrel , ccamp@ops.ietf.org,softwires@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: If you drop the "unless they share identical Traffic Engineering Attributes" then we have alignment. Lou At 09:50 AM 8/27/2008, Yakov Rekhter wrote: >Lou, > > > Why "SHOULD NOT" rather than "MUST NOT"? > >It is already there (Section 4): > > Routes that carry the Traffic Engineering Attribute have additional > semantics that could affect traffic forwarding behavior. Therefore, > such routes SHALL NOT be aggregated unless they share identical > Traffic Engineering Attributes. > >Yakov. > > > > > Lou > > > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > > >Hi again Yakov, > > > > > >Thanks also for the reply to my second question. > > > > > >Your answer seems to imply that the applicability of your work is strictly > > >limited to L1VPNs. > > > > > >If this is the case, we can easily close this discussion by adding text to > > >the Abstract and Introduction such as: > > > > > > The scope and applicability of this protocol extension is > > > currently limited to single-AS deployment scenarios of the > > > basic mode of L1VPNs. Further applications are for > > > future study, but these mechanisms SHOULD NOT be > > > used in any attempt to support TE aggregation. > > > > > >Cheers, > > >Adrian > > > > > > >> 2. There is more than one AS > > > >> > > > >> Consider > > > >> > > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > > >> > > > >> PE2 advertises reachability to CE2 and includes TE > > > >> information. The TE attribute is non-transitive so it is > > > >> not just passed on, but ASBR2 wants to announce > > > >> reachability to CE2 (in the VPN case, we may want to > > > >> support a multi-AS VPN). > > > >> > > > >> So ASBR2 can advertise reachability to CE2, but what TE > > > >> parameters does it advertise? The parameters for the > > > >> link PE2-CE2 are not so helpful because the TE > > > >> reachability across AS2 may be different. Yet any attempt > > > >> to perform a computation of the TE reachability across > > > >> AS2 (i.e. TE aggregation) is complex and potentially > > > >> unstable. (Of course, if a tunnel is pre-established > > > >> between ASBR2 and PE2 this is a different matter.) > > > >> > > > >> I think that these two different scenarios need attention > > > >> in the I-D. > > > >> > > > >> For the first one, it may just be a matter of indicating > > > >> which approach is to be used. > > > >> > > > >> For the second one, I hope the answer is to recommend > > > >> against any form of TE aggregation. This could easily be > > > >> added to section 4, and I would be happy to provide text. > > > >> BUT, it will still leave open the question about if and how > > > >> TE information is propagated beyond the AS. > > > > > > > > For the second one the answer is in rfc5251: > > > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > > > analysis beyond the scope of this document. > > > > > >_______________________________________________ > > >Softwires mailing list > > >Softwires@ietf.org > > >https://www.ietf.org/mailman/listinfo/softwires > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 13:52:54 +0000 Message-Id: <200808271350.m7RDoSu86903@magenta.juniper.net> To: Lou Berger cc: Adrian Farrel , ccamp@ops.ietf.org, softwires@ietf.org Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27575.1219845028.1@juniper.net> Date: Wed, 27 Aug 2008 06:50:28 -0700 From: Yakov Rekhter Lou, > Why "SHOULD NOT" rather than "MUST NOT"? It is already there (Section 4): Routes that carry the Traffic Engineering Attribute have additional semantics that could affect traffic forwarding behavior. Therefore, such routes SHALL NOT be aggregated unless they share identical Traffic Engineering Attributes. Yakov. > > Lou > > At 06:51 AM 8/27/2008, Adrian Farrel wrote: > >Hi again Yakov, > > > >Thanks also for the reply to my second question. > > > >Your answer seems to imply that the applicability of your work is strictly > >limited to L1VPNs. > > > >If this is the case, we can easily close this discussion by adding text to > >the Abstract and Introduction such as: > > > > The scope and applicability of this protocol extension is > > currently limited to single-AS deployment scenarios of the > > basic mode of L1VPNs. Further applications are for > > future study, but these mechanisms SHOULD NOT be > > used in any attempt to support TE aggregation. > > > >Cheers, > >Adrian > > > > >> 2. There is more than one AS > > >> > > >> Consider > > >> > > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > >> > > >> PE2 advertises reachability to CE2 and includes TE > > >> information. The TE attribute is non-transitive so it is > > >> not just passed on, but ASBR2 wants to announce > > >> reachability to CE2 (in the VPN case, we may want to > > >> support a multi-AS VPN). > > >> > > >> So ASBR2 can advertise reachability to CE2, but what TE > > >> parameters does it advertise? The parameters for the > > >> link PE2-CE2 are not so helpful because the TE > > >> reachability across AS2 may be different. Yet any attempt > > >> to perform a computation of the TE reachability across > > >> AS2 (i.e. TE aggregation) is complex and potentially > > >> unstable. (Of course, if a tunnel is pre-established > > >> between ASBR2 and PE2 this is a different matter.) > > >> > > >> I think that these two different scenarios need attention > > >> in the I-D. > > >> > > >> For the first one, it may just be a matter of indicating > > >> which approach is to be used. > > >> > > >> For the second one, I hope the answer is to recommend > > >> against any form of TE aggregation. This could easily be > > >> added to section 4, and I would be happy to provide text. > > >> BUT, it will still leave open the question about if and how > > >> TE information is propagated beyond the AS. > > > > > > For the second one the answer is in rfc5251: > > > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > > analysis beyond the scope of this document. > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 13:32:14 +0000 Date: Wed, 27 Aug 2008 09:30:25 -0400 To: Adrian Farrel From: Lou Berger Subject: Re: [Softwires] BGP TE attr last call by softwires WG (2nd question) Cc: "Yakov Rekhter" ,ccamp@ops.ietf.org, softwires@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Why "SHOULD NOT" rather than "MUST NOT"? Lou At 06:51 AM 8/27/2008, Adrian Farrel wrote: >Hi again Yakov, > >Thanks also for the reply to my second question. > >Your answer seems to imply that the applicability of your work is strictly >limited to L1VPNs. > >If this is the case, we can easily close this discussion by adding text to >the Abstract and Introduction such as: > > The scope and applicability of this protocol extension is > currently limited to single-AS deployment scenarios of the > basic mode of L1VPNs. Further applications are for > future study, but these mechanisms SHOULD NOT be > used in any attempt to support TE aggregation. > >Cheers, >Adrian > > >> 2. There is more than one AS > >> > >> Consider > >> > >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > >> > >> PE2 advertises reachability to CE2 and includes TE > >> information. The TE attribute is non-transitive so it is > >> not just passed on, but ASBR2 wants to announce > >> reachability to CE2 (in the VPN case, we may want to > >> support a multi-AS VPN). > >> > >> So ASBR2 can advertise reachability to CE2, but what TE > >> parameters does it advertise? The parameters for the > >> link PE2-CE2 are not so helpful because the TE > >> reachability across AS2 may be different. Yet any attempt > >> to perform a computation of the TE reachability across > >> AS2 (i.e. TE aggregation) is complex and potentially > >> unstable. (Of course, if a tunnel is pre-established > >> between ASBR2 and PE2 this is a different matter.) > >> > >> I think that these two different scenarios need attention > >> in the I-D. > >> > >> For the first one, it may just be a matter of indicating > >> which approach is to be used. > >> > >> For the second one, I hope the answer is to recommend > >> against any form of TE aggregation. This could easily be > >> added to section 4, and I would be happy to provide text. > >> BUT, it will still leave open the question about if and how > >> TE information is propagated beyond the AS. > > > > For the second one the answer is in rfc5251: > > > > Consideration of inter-AS and inter-provider L1VPNs requires further > > analysis beyond the scope of this document. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 10:54:10 +0000 Message-ID: <051a01c90832$ecb8a280$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Yakov Rekhter" Cc: , , , , "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG (2nd question) Date: Wed, 27 Aug 2008 11:51:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi again Yakov, Thanks also for the reply to my second question. Your answer seems to imply that the applicability of your work is strictly limited to L1VPNs. If this is the case, we can easily close this discussion by adding text to the Abstract and Introduction such as: The scope and applicability of this protocol extension is currently limited to single-AS deployment scenarios of the basic mode of L1VPNs. Further applications are for future study, but these mechanisms SHOULD NOT be used in any attempt to support TE aggregation. Cheers, Adrian >> 2. There is more than one AS >> >> Consider >> >> CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 >> >> PE2 advertises reachability to CE2 and includes TE >> information. The TE attribute is non-transitive so it is >> not just passed on, but ASBR2 wants to announce >> reachability to CE2 (in the VPN case, we may want to >> support a multi-AS VPN). >> >> So ASBR2 can advertise reachability to CE2, but what TE >> parameters does it advertise? The parameters for the >> link PE2-CE2 are not so helpful because the TE >> reachability across AS2 may be different. Yet any attempt >> to perform a computation of the TE reachability across >> AS2 (i.e. TE aggregation) is complex and potentially >> unstable. (Of course, if a tunnel is pre-established >> between ASBR2 and PE2 this is a different matter.) >> >> I think that these two different scenarios need attention >> in the I-D. >> >> For the first one, it may just be a matter of indicating >> which approach is to be used. >> >> For the second one, I hope the answer is to recommend >> against any form of TE aggregation. This could easily be >> added to section 4, and I would be happy to provide text. >> BUT, it will still leave open the question about if and how >> TE information is propagated beyond the AS. > > For the second one the answer is in rfc5251: > > Consideration of inter-AS and inter-provider L1VPNs requires further > analysis beyond the scope of this document. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Aug 2008 10:48:35 +0000 Message-ID: <051601c90832$2a87f530$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Yakov Rekhter" Cc: "Don Fedyk" , , , , , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG Date: Wed, 27 Aug 2008 11:46:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Yakov, You have answered my first question, within the limited scope of basic mode, single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with your interpretation. This is good, and I support the use of this draft in that limited scenario, and I suspect that the concept is extensible to any port-based VPN. Will you be adding to the draft to say that this is the full extent of the applicability of this draft (perhaps using RFC 2119 language)? If not, then I'm afraid that my question stands. What will happen in the case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE links? Thanks, Adrian >> >> 1. A CE is attached by parallel links to a single PE >> >> >> >> Suppose the links have the same switching types, but >> >> different bandwidths. Link-a has plenty of bandwidth >> >> available with an MTU size of x. Link-b has not much >> >> bandwidth available with an MTU size of y > x. >> > >> > Interface MTU is part of the PSC TE attributes in the our spec. If the >> > MTUs are different they should not be aggregated. >> >> Right. Aggregation in this case is hard to make representative of >> reality. >> >> > Also In L1VPN (LSC and TDM) networks the Switching type >> > covers Switching granularity (which is like an MTU). >> >> Sure. But I wanted to keep in PSC, because that problem represents a >> single >> layer network. >> >> > I'm trying to understand if you are saying the following text would >> > fix the problem or you see a larger issue: >> > "Therefore, such routes and the corresponding TE information >> > SHALL NOT be aggregated unless they share identical Traffic >> > Engineering Attributes". >> >> The question I am asking is - is the solution to this problem to >> advertise >> two routes? (Clearly two is a special case of many.) >> >> I don't believe that in the general (non-TE case) we would consider the >> case >> of two parallel links between CE and PE as route aggregation. The PE >> would >> simply advertise reachability (through itself) to the CE. > > Let's put the general (non-TE) case aside, and focus on the L1VPN > scenario. > > According to the bgp-auto-discovery and l1vpn-basic-mode drafts in > the context of L1VPN what is advertised in the BGP auto-discovery > information is the information about *ports*. Therefore, in the > context of L1VPN TE information advertisements are associated with > individual *ports*, not with a particular CE. Which means that if > a CE is connected to a PE by N ports, then the BGP auto-discovery > information has to advertise all these N ports, and associated with > each such advertisement may be the TE information. > >> Hence my question below. >> >> >> Normally, we would expect the PE to advertise a single >> >> piece of reachability information for the CE leaving >> >> the actual choice of links to be made by the PE. >> >> >> >> What would the PE advertise in this case? >> >> - It cannot aggregate the TE information because that >> >> would imply that there was lots of bandwidth at the >> >> larger MTU size. >> >> - It could include duplicate Switching Capability >> >> Descriptors, but that would need some clarification as >> >> duplicate descriptors are intended for different >> >> switching caps in the IGP RFCs. >> >> - It could advertise two pieces of reachability >> >> information, but that would be a change to how the >> >> implementation currently works. > > The answer to your question is that if the implementation follows > the spec, it would advertise information about *ports*. So, if a > CE has two ports that connect it to a PE, then the PE originates > two L1VPN advertisements, one per port, each with its own TE > attribute. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Aug 2008 13:01:35 +0000 Message-Id: <200808261254.m7QCsJu33149@magenta.juniper.net> To: "Adrian Farrel" cc: softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46141.1219755259.1@juniper.net> Date: Tue, 26 Aug 2008 05:54:19 -0700 From: Yakov Rekhter Adrian, > Hi, > > > From: David Ward > > Sent: Tue Aug 12 23:48 > > Subject: BGP TE attr last call by softwires WG > > > > The softwire WG has LC'ed > > > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > > bgp-te-attribute-01.txt > > > > We will keep open an additional two-week period for wider > > review before moving forward in the publication process. > > Please have any comments to the authors and softwires WG > > by Aug 26, 2008. > > I have no objection to the basic idea of distributing TE > information about CE-PE links especially for use in VPNs. > But I am worried by one aspect of the document. Hopefully > this is just an editorial issue. > > The last call in Softwires appears to have generated some > discussion about aggregation, and this led to the addition > of section 4. > > | 4. Implication on aggregation > | > | Routes that carry the Traffic Engineering Attribute > | have additional semantics that could affect traffic > | forwarding behavior. Therefore, such routes SHALL NOT > | be aggregated unless they share identical Traffic > | Engineering Attributes. > > As far as it goes, this paragraph is great. It says "do not > perform route aggregation unless it is sensible to do so." > > But it says nothing about TE aggregation. > > Notwithstanding the TE attribute is non-transitive, there > is the potential for an implementation to believe that it > should provide some form of TE aggregation. > > Consider two cases: > > 1. A CE is attached by parallel links to a single PE > > Suppose the links have the same switching types, but > different bandwidths. Link-a has plenty of bandwidth > available with an MTU size of x. Link-b has not much > bandwidth available with an MTU size of y > x. > > Normally, we would expect the PE to advertise a single > piece of reachability information for the CE leaving > the actual choice of links to be made by the PE. > > What would the PE advertise in this case? > - It cannot aggregate the TE information because that > would imply that there was lots of bandwidth at the > larger MTU size. > - It could include duplicate Switching Capability > Descriptors, but that would need some clarification as > duplicate descriptors are intended for different > switching caps in the IGP RFCs. > - It could advertise two pieces of reachability > information, but that would be a change to how the > implementation currently works. I already answered this in my other e-mail yesterday. > 2. There is more than one AS > > Consider > > CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 > > PE2 advertises reachability to CE2 and includes TE > information. The TE attribute is non-transitive so it is > not just passed on, but ASBR2 wants to announce > reachability to CE2 (in the VPN case, we may want to > support a multi-AS VPN). > > So ASBR2 can advertise reachability to CE2, but what TE > parameters does it advertise? The parameters for the > link PE2-CE2 are not so helpful because the TE > reachability across AS2 may be different. Yet any attempt > to perform a computation of the TE reachability across > AS2 (i.e. TE aggregation) is complex and potentially > unstable. (Of course, if a tunnel is pre-established > between ASBR2 and PE2 this is a different matter.) > > > I think that these two different scenarios need attention > in the I-D. > > For the first one, it may just be a matter of indicating > which approach is to be used. > > For the second one, I hope the answer is to recommend > against any form of TE aggregation. This could easily be > added to section 4, and I would be happy to provide text. > BUT, it will still leave open the question about if and how > TE information is propagated beyond the AS. For the second one the answer is in rfc5251: Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Aug 2008 18:18:40 +0000 Message-Id: <200808251814.m7PIEFu54645@magenta.juniper.net> To: "Adrian Farrel" cc: "Don Fedyk" , softwires@ietf.org, dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17410.1219688055.1@juniper.net> Date: Mon, 25 Aug 2008 11:14:15 -0700 From: Yakov Rekhter Adrian, > Hello Don, > > Thanks for the response. > > >> 1. A CE is attached by parallel links to a single PE > >> > >> Suppose the links have the same switching types, but > >> different bandwidths. Link-a has plenty of bandwidth > >> available with an MTU size of x. Link-b has not much > >> bandwidth available with an MTU size of y > x. > > > > Interface MTU is part of the PSC TE attributes in the our spec. If the > > MTUs are different they should not be aggregated. > > Right. Aggregation in this case is hard to make representative of reality. > > > Also In L1VPN (LSC and TDM) networks the Switching type > > covers Switching granularity (which is like an MTU). > > Sure. But I wanted to keep in PSC, because that problem represents a single > layer network. > > > I'm trying to understand if you are saying the following text would > > fix the problem or you see a larger issue: > > "Therefore, such routes and the corresponding TE information > > SHALL NOT be aggregated unless they share identical Traffic > > Engineering Attributes". > > The question I am asking is - is the solution to this problem to advertise > two routes? (Clearly two is a special case of many.) > > I don't believe that in the general (non-TE case) we would consider the case > of two parallel links between CE and PE as route aggregation. The PE would > simply advertise reachability (through itself) to the CE. Let's put the general (non-TE) case aside, and focus on the L1VPN scenario. According to the bgp-auto-discovery and l1vpn-basic-mode drafts in the context of L1VPN what is advertised in the BGP auto-discovery information is the information about *ports*. Therefore, in the context of L1VPN TE information advertisements are associated with individual *ports*, not with a particular CE. Which means that if a CE is connected to a PE by N ports, then the BGP auto-discovery information has to advertise all these N ports, and associated with each such advertisement may be the TE information. > Hence my question below. > > >> Normally, we would expect the PE to advertise a single > >> piece of reachability information for the CE leaving > >> the actual choice of links to be made by the PE. > >> > >> What would the PE advertise in this case? > >> - It cannot aggregate the TE information because that > >> would imply that there was lots of bandwidth at the > >> larger MTU size. > >> - It could include duplicate Switching Capability > >> Descriptors, but that would need some clarification as > >> duplicate descriptors are intended for different > >> switching caps in the IGP RFCs. > >> - It could advertise two pieces of reachability > >> information, but that would be a change to how the > >> implementation currently works. The answer to your question is that if the implementation follows the spec, it would advertise information about *ports*. So, if a CE has two ports that connect it to a PE, then the PE originates two L1VPN advertisements, one per port, each with its own TE attribute. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Aug 2008 03:31:56 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080825033001.8F16A3A682B@core3.amsl.com> Date: Sun, 24 Aug 2008 20:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-isis-interas-te-extension-03.txt Pages : 20 Date : 2008-08-24 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-isis-interas-te-extension-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-24202349.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Aug 2008 15:49:15 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 22 Aug 2008 17:42:18 +0200 Subject: Re: BGP TE attr last call by softwires WG From: JP Vasseur To: Adrian Farrel , Don Fedyk , CC: , , , Yakov Rekhter , Hamid Ould-Brahim Message-ID: Thread-Topic: BGP TE attr last call by softwires WG Thread-Index: AckEbahm2i50H6DSZkGNaiR5Sc3eJQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2992; t=1219420078; x=1220284078; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20BGP=20TE=20attr=20last=20call=20by=20so ftwires=20WG |Sender:=20; bh=xY2Z4B5XuQ6sC1pYhm6vi+VcgoDyLYT4GyFXblvsoR0=; b=rbv0pq1rQTcB8QLwAXY+RKfFqb3otPII+Sp+/PblbLXTYpQ4tG0HUJzeUi tp/JVLN1X2ry3aJpqui9M9xtOh2SIkRVMY/hhyhDdZxwUoCmxcc/fqKM4Os1 f2+HP7sosYKV+mOV3RKcXhDvQw/i6YFEOlzlavIBqrGYrRZru/x3I=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Hi all, I'd like to second Adrian's point here - see below. On 8/22/08 1:18 AM, "Adrian Farrel" wrote: > Hello Don, > > Thanks for the response. > >>> 1. A CE is attached by parallel links to a single PE >>> >>> Suppose the links have the same switching types, but >>> different bandwidths. Link-a has plenty of bandwidth >>> available with an MTU size of x. Link-b has not much >>> bandwidth available with an MTU size of y > x. >> >> Interface MTU is part of the PSC TE attributes in the our spec. If the >> MTUs are different they should not be aggregated. > > Right. > Aggregation in this case is hard to make representative of reality. That is also my concern ... It would be really nice to clarify that TE aggregation must be avoided. > >> Also In L1VPN (LSC and TDM) networks the Switching type >> covers Switching granularity (which is like an MTU). > > Sure. But I wanted to keep in PSC, because that problem represents a single > layer network. > >> I'm trying to understand if you are saying the following text would >> fix the problem or you see a larger issue: >> "Therefore, such routes and the corresponding TE information >> SHALL NOT be aggregated unless they share identical Traffic >> Engineering Attributes". > > The question I am asking is - is the solution to this problem to advertise > two routes? > (Clearly two is a special case of many.) > > I don't believe that in the general (non-TE case) we would consider the case > of two parallel links between CE and PE as route aggregation. The PE would > simply advertise reachability (through itself) to the CE. > > Hence my question below. > >>> Normally, we would expect the PE to advertise a single >>> piece of reachability information for the CE leaving >>> the actual choice of links to be made by the PE. >>> >>> What would the PE advertise in this case? >>> - It cannot aggregate the TE information because that >>> would imply that there was lots of bandwidth at the >>> larger MTU size. >>> - It could include duplicate Switching Capability >>> Descriptors, but that would need some clarification as >>> duplicate descriptors are intended for different >>> switching caps in the IGP RFCs. >>> - It could advertise two pieces of reachability >>> information, but that would be a change to how the >>> implementation currently works. > >>> 2. There is more than one AS > [SNIP] >> I remember we discussed this aspect originally in the context of >> L1VPNs and limited it to a single AS since L1VPNs Basic Mode >> are limited to a single AS. I don't recall if we thought this was >> applicable to a multi-AS solution. >> >> We should clarify this point either way. > > Thanks. > I guess: > - if applicable, how? > - if not applicable, how prevent? > Same question. Thanks Don. JP. > Cheers, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Aug 2008 13:50:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Date: Fri, 22 Aug 2008 09:47:16 -0400 Message-ID: Thread-Topic: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Thread-Index: AckEK1xostfKZrU/SRa9RapZDI/EcAAMfPig From: "BRUNGARD, DEBORAH A, ATTLABS" To: In preparing the proto for publishing, I had several editorial comments which this updated draft reflects. Thanks Authors- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, August 22, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Pages : 11 Date : 2008-08-22 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Aug 2008 07:46:53 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-pc-and-sc-reqs-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080822074502.0738528C102@core3.amsl.com> Date: Fri, 22 Aug 2008 00:45:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-and-sc-reqs-05.txt Pages : 11 Date : 2008-08-22 >From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-pc-and-sc-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-22004208.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Aug 2008 23:19:38 +0000 Message-ID: <010601c903e4$2a081790$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Don Fedyk" , Cc: , , , "Yakov Rekhter" , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG Date: Fri, 22 Aug 2008 00:18:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hello Don, Thanks for the response. >> 1. A CE is attached by parallel links to a single PE >> >> Suppose the links have the same switching types, but >> different bandwidths. Link-a has plenty of bandwidth >> available with an MTU size of x. Link-b has not much >> bandwidth available with an MTU size of y > x. > > Interface MTU is part of the PSC TE attributes in the our spec. If the > MTUs are different they should not be aggregated. Right. Aggregation in this case is hard to make representative of reality. > Also In L1VPN (LSC and TDM) networks the Switching type > covers Switching granularity (which is like an MTU). Sure. But I wanted to keep in PSC, because that problem represents a single layer network. > I'm trying to understand if you are saying the following text would > fix the problem or you see a larger issue: > "Therefore, such routes and the corresponding TE information > SHALL NOT be aggregated unless they share identical Traffic > Engineering Attributes". The question I am asking is - is the solution to this problem to advertise two routes? (Clearly two is a special case of many.) I don't believe that in the general (non-TE case) we would consider the case of two parallel links between CE and PE as route aggregation. The PE would simply advertise reachability (through itself) to the CE. Hence my question below. >> Normally, we would expect the PE to advertise a single >> piece of reachability information for the CE leaving >> the actual choice of links to be made by the PE. >> >> What would the PE advertise in this case? >> - It cannot aggregate the TE information because that >> would imply that there was lots of bandwidth at the >> larger MTU size. >> - It could include duplicate Switching Capability >> Descriptors, but that would need some clarification as >> duplicate descriptors are intended for different >> switching caps in the IGP RFCs. >> - It could advertise two pieces of reachability >> information, but that would be a change to how the >> implementation currently works. >> 2. There is more than one AS [SNIP] >I remember we discussed this aspect originally in the context of >L1VPNs and limited it to a single AS since L1VPNs Basic Mode >are limited to a single AS. I don't recall if we thought this was >applicable to a multi-AS solution. > >We should clarify this point either way. Thanks. I guess: - if applicable, how? - if not applicable, how prevent? Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Aug 2008 23:08:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BGP TE attr last call by softwires WG Date: Thu, 21 Aug 2008 19:04:46 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4165F47EB@zrtphxm2.corp.nortel.com> Thread-Topic: BGP TE attr last call by softwires WG Thread-Index: AckDdFwlKr2PTql+SjuqzSiskbBx0wAYmanQ From: "Don Fedyk" To: "Adrian Farrel" , Cc: , , , "Yakov Rekhter" , "Hamid Ould-Brahim" Hi Adrian I should talk this over with my Co-authors so for now I won't answer all your points but I will ask for clarification. See Inline: > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 >=20 > Hi, >=20 > > From: David Ward =20 > > Sent: Tue Aug 12 23:48=20 > > Subject: BGP TE attr last call by softwires WG=20 > > > > The softwire WG has LC'ed=20 > > > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > > bgp-te-attribute-01.txt=20 > > > > We will keep open an additional two-week period for wider > > review before moving forward in the publication process.=20 > > Please have any comments to the authors and softwires WG=20 > > by Aug 26, 2008.=20 >=20 > I have no objection to the basic idea of distributing TE > information about CE-PE links especially for use in VPNs.=20 > But I am worried by one aspect of the document. Hopefully > this is just an editorial issue. >=20 > The last call in Softwires appears to have generated some > discussion about aggregation, and this led to the addition=20 > of section 4. >=20 > | 4. Implication on aggregation > | > | Routes that carry the Traffic Engineering Attribute=20 > | have additional semantics that could affect traffic=20 > | forwarding behavior. Therefore, such routes SHALL NOT=20 > | be aggregated unless they share identical Traffic > | Engineering Attributes. >=20 > As far as it goes, this paragraph is great. It says "do not > perform route aggregation unless it is sensible to do so." >=20 > But it says nothing about TE aggregation. >=20 > Notwithstanding the TE attribute is non-transitive, there=20 > is the potential for an implementation to believe that it > should provide some form of TE aggregation. >=20 > Consider two cases: >=20 > 1. A CE is attached by parallel links to a single PE >=20 > Suppose the links have the same switching types, but=20 > different bandwidths. Link-a has plenty of bandwidth > available with an MTU size of x. Link-b has not much > bandwidth available with an MTU size of y > x. Interface MTU is part of the PSC TE attributes in the our spec. If the MTUs are different they should not be aggregated.=20 Also In L1VPN (LSC and TDM) networks the Switching type covers Switching granularity (which is like an MTU). =20 I'm trying to understand if you are saying the following text would fix the problem or you see a larger issue:=20 "Therefore, such routes and the corresponding TE information SHALL NOT be aggregated unless they share identical Traffic Engineering Attributes". >=20 > Normally, we would expect the PE to advertise a single > piece of reachability information for the CE leaving > the actual choice of links to be made by the PE. >=20 > What would the PE advertise in this case? > - It cannot aggregate the TE information because that > would imply that there was lots of bandwidth at the=20 > larger MTU size. > - It could include duplicate Switching Capability > Descriptors, but that would need some clarification as > duplicate descriptors are intended for different=20 > switching caps in the IGP RFCs. > - It could advertise two pieces of reachability > information, but that would be a change to how the > implementation currently works. >=20 > 2. There is more than one AS >=20 > Consider >=20 > CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 >=20 > PE2 advertises reachability to CE2 and includes TE=20 > information. The TE attribute is non-transitive so it is > not just passed on, but ASBR2 wants to announce > reachability to CE2 (in the VPN case, we may want to=20 > support a multi-AS VPN). >=20 > So ASBR2 can advertise reachability to CE2, but what TE > parameters does it advertise? The parameters for the=20 > link PE2-CE2 are not so helpful because the TE=20 > reachability across AS2 may be different. Yet any attempt > to perform a computation of the TE reachability across > AS2 (i.e. TE aggregation) is complex and potentially > unstable. (Of course, if a tunnel is pre-established > between ASBR2 and PE2 this is a different matter.) I remember we discussed this aspect originally in the context of L1VPNs and limited it to a single AS since L1VPNs Basic Mode are limited to a single AS. I don't recall if we thought this was applicable to a multi AS solution. We should clarify this point either way. =20 We will get back to you shortly on this point.=20 Thanks, Don=20 >=20 >=20 > I think that these two different scenarios need attention > in the I-D.=20 >=20 > For the first one, it may just be a matter of indicating=20 > which approach is to be used. >=20 > For the second one, I hope the answer is to recommend=20 > against any form of TE aggregation. This could easily be > added to section 4, and I would be happy to provide text. > BUT, it will still leave open the question about if and how > TE information is propagated beyond the AS. >=20 > Thanks for any clarifications. >=20 > Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Aug 2008 18:50:49 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5298 on Analysis of Inter-Domain Label Switched Path (LSP) Recovery From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20080821184833.4B63214FC3B@bosco.isi.edu> Date: Thu, 21 Aug 2008 11:48:33 -0700 (PDT) A new Request for Comments is now available in online RFC libraries. RFC 5298 Title: Analysis of Inter-Domain Label Switched Path (LSP) Recovery Author: T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur Status: Informational Date: August 2008 Mailbox: takeda.tomonori@lab.ntt.co.jp, y.ikejiri@ntt.com, adrian@olddog.co.uk, jpv@cisco.com Pages: 26 Characters: 59894 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt URL: http://www.rfc-editor.org/rfc/rfc5298.txt Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering". This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community. This document is a product of the Common Control and Measurement Plane 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/rfcsearch.html. 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 USC/Information Sciences Institute Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Aug 2008 09:59:43 +0000 Message-ID: <001f01c90373$da047f60$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , , , "Yakov Rekhter" , "Don Fedyk" , "Hamid Ould-Brahim" Subject: Re: BGP TE attr last call by softwires WG Date: Thu, 21 Aug 2008 10:53:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, > From: David Ward > Sent: Tue Aug 12 23:48 > Subject: BGP TE attr last call by softwires WG > > The softwire WG has LC'ed > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > bgp-te-attribute-01.txt > > We will keep open an additional two-week period for wider > review before moving forward in the publication process. > Please have any comments to the authors and softwires WG > by Aug 26, 2008. I have no objection to the basic idea of distributing TE information about CE-PE links especially for use in VPNs. But I am worried by one aspect of the document. Hopefully this is just an editorial issue. The last call in Softwires appears to have generated some discussion about aggregation, and this led to the addition of section 4. | 4. Implication on aggregation | | Routes that carry the Traffic Engineering Attribute | have additional semantics that could affect traffic | forwarding behavior. Therefore, such routes SHALL NOT | be aggregated unless they share identical Traffic | Engineering Attributes. As far as it goes, this paragraph is great. It says "do not perform route aggregation unless it is sensible to do so." But it says nothing about TE aggregation. Notwithstanding the TE attribute is non-transitive, there is the potential for an implementation to believe that it should provide some form of TE aggregation. Consider two cases: 1. A CE is attached by parallel links to a single PE Suppose the links have the same switching types, but different bandwidths. Link-a has plenty of bandwidth available with an MTU size of x. Link-b has not much bandwidth available with an MTU size of y > x. Normally, we would expect the PE to advertise a single piece of reachability information for the CE leaving the actual choice of links to be made by the PE. What would the PE advertise in this case? - It cannot aggregate the TE information because that would imply that there was lots of bandwidth at the larger MTU size. - It could include duplicate Switching Capability Descriptors, but that would need some clarification as duplicate descriptors are intended for different switching caps in the IGP RFCs. - It could advertise two pieces of reachability information, but that would be a change to how the implementation currently works. 2. There is more than one AS Consider CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 PE2 advertises reachability to CE2 and includes TE information. The TE attribute is non-transitive so it is not just passed on, but ASBR2 wants to announce reachability to CE2 (in the VPN case, we may want to support a multi-AS VPN). So ASBR2 can advertise reachability to CE2, but what TE parameters does it advertise? The parameters for the link PE2-CE2 are not so helpful because the TE reachability across AS2 may be different. Yet any attempt to perform a computation of the TE reachability across AS2 (i.e. TE aggregation) is complex and potentially unstable. (Of course, if a tunnel is pre-established between ASBR2 and PE2 this is a different matter.) I think that these two different scenarios need attention in the I-D. For the first one, it may just be a matter of indicating which approach is to be used. For the second one, I hope the answer is to recommend against any form of TE aggregation. This could easily be added to section 4, and I would be happy to provide text. BUT, it will still leave open the question about if and how TE information is propagated beyond the AS. Thanks for any clarifications. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Aug 2008 10:03:44 +0000 Message-ID: <039501c902ab$cae9c170$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Dan Li'" , "'Igor Bryskin'" , , Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Wed, 20 Aug 2008 11:01:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Tony, (and by the way, welcome to CCAMP) >> 1) The amount of information advertised >> The amount of information carried and the stability of that information >> is >> similar to that used in TE networks today. In those networks, when a TE >> LSP >> is set up or torn down, there is a change in the bandwidth availability >> on >> all links traversed. This causes an update to the TE information >> advertised >> in the IGP for those links. > > True. However, typically the number of TE LSPs that are established is a > static number. Even in extreme cases, folks typically use O(n^2) LSPs to > form a complete mesh of their nodes. > > In the applications that I think that you're contemplating, there are many > more links, with the ability of end users to set up their own links > throughout the network. Please correct me if I'm misunderstanding. I think there is some misunderstanding here. It is true that in a private lambda model, the end-user may request the establishment of the LSP (where the end-user might be a packet network), but I don't think we should assume that the connectivity is worse than that in a TE network. Indeed, it is likely to be much less. This is in part due to the expense of equipment, the topology of the network, and the constraint of the number of lambdas supported on any link. That means that a single PE will only connect to a realtively small number of other PEs. Of course, this may vary in time as technology improves and as networks get larger and have greater use. >> In general, this is not seen as a critical issue. There are several >> possibilities to reduce the impact of TE advertisements if they become a >> problem. For example, as implemented in some of our current IP network, >> each >> router can impose a threshold (time and/or bandwidth delta) before which >> it >> will not re-issue an advertisement. > > Effectively rate limiting the link state database flooding, which is the > goal. > >> In networks that require IGP convergence (for IP data traffic) and TE >> advertisement (for MPLS-TE traffic) there is some concern that the >> distribution of TE information might impact the IGP convergence time. In >> these cases, implementations may prioritise normal LSAs ahead of opaque >> LSAs, or may use separate protocol instances. > > The former is more difficult in IS-IS, as TE information is typically > distributed as part of the same LSP that carries the physical link > information. Separate protocol instances is of course possible, but it > would seem like it would become more of a manageability issue (do you need > identical topologies?) and would not obviate the need for CPU cycles. Yes. The Gen-App work in IS-IS is specifically to address this issue, I believe. CPU cycles will remain an issue for everyone. But if you build a box for a specific environment, you had better buiold a big enough box! >> 2) Speed of convergence of wavelength availability >> In a TE network, the need for an up-to-date TED depends to a good degree >> on >> the relative size of LSPs and residual bandwidth, and on the rate of >> arrival >> of new LSPs. Increasingly, core TE LSPs may be quite large, but in >> general, >> the rate of arrival of large LSPs is quite low, and the holding times are >> quite high. >> >> So, the bottom line in a TE network is that when an LSP needs more >> bandwidth >> than is actually available, it is crucial that the TED is up-to-date (or >> "real-time" like some folks may call it). > > I'm not sure that I would characterize it as 'crucial'. It would seem > like > there is always going to be *some* window where remote nodes have > imperfect > information, just due to speed of light delays. Ergo, the head end must > always be prepared for its path to be rejected during setup and then > recompute the path based on new information. Absolutely. And the signaling protocols are specifically designed to handle this case. Nevertheless, for customer experience (TM) we would hope to make this window relatively small. And, indeed, the debate lower down the email is really about how likely we are to fall through the window. If it happens for every LSP setup attempt, something clearly needs to be done in the protocols. If it happens less than 1% and only in really busy networks, this may be acceptable. >> But as Igor has pointed out, this is impossible to achieve in a >> distributed >> system. Indeed, it is impossible to achieve even in a centralised system >> since network failures may occur. That means that there is always a >> possibility that a computed path will be signaled and will fail to be >> established. We should be familiar with this situation in scenarios such >> as >> contention during restoration after network failure, and the signaling >> protocols are designed to fail and try again (usually using "crankback" >> information about the failed link, but also assuming that the IGP may >> have >> converged in the mean time). > > Note that crankback (recomputing the path DURING setup) is not always > necessary. Sometimes recomputation at the head end will suffice. Yes. It all depends on whether the TED has converged in the mean time. If so, then reporting the failure and triggering recomputation is needed. If not (or if you can't be sure) it is best to recompute with the knowledge of which link caused the failure in the original setup. That's crankback (RFC 4920). >> We can look at a couple of things: >> - What is the arrival rate of lambda LSPs? >> - What is the required setup time of lambda LSPs? >> >> With the exception of restoration LSPs, I think we may say that a 5-10 >> second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but >> you >> may have a different experience. > > In my experience nearly static LSPs are perfectly acceptable, and setup > time > is not an issue. ;-) Exactly. What we find at the moment, however, is that there is a lot of discussion about moving the transport network from a "nearly static" animal to something that is semi-dynamic, or even "on-demand". This changes the boundaries, but it is still not clear to me that "on-demand" means sub-second as I would expect all lambda LSPs to go through a testing phase before being put in service (even if this is an automatic phase). And I would expect such a phase to take a number of seconds. That said, restoration is a different question. > My concern however is simpler: limiting the rate of link state database > flooding. This is vital to ensure the stability of the IGP. Agreed, but let's be careful to understand the size of the network, the amount of information, and the rate of change of that information. This is really what Dan's I-D is starting to look at, so contributions to helping with that understanding are welcome. If, as you say, most of these LSPs are nearly static, we obviously don't have to worry about the amount of flooding. It is only when LSPs come and go (or when nodes/links come and go) that we will see a change in flooding. I think that what Dan said in this email points out that the amount of flooding (but not necessarily the amount of information flooded) is similar to what we already see in TE networks. We should certainly look to see what the stability experience is with those networks - my understanding is that they are deployed and functional. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Aug 2008 05:25:00 +0000 Reply-To: From: "Tony Li" To: "'Dan Li'" , "'Igor Bryskin'" , , , Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Tue, 19 Aug 2008 22:22:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C9024A.32CE8300" Thread-Index: AckCcxcrmx2RXyoLSCGen5w+2Vk+6gAD5r3A This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C9024A.32CE8300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dan, 1) The amount of information advertised The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links. True. However, typically the number of TE LSPs that are established is a static number. Even in extreme cases, folks typically use O(n^2) LSPs to form a complete mesh of their nodes. In the applications that I think that you're contemplating, there are many more links, with the ability of end users to set up their own links throughout the network. Please correct me if I'm misunderstanding. In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement. Effectively rate limiting the link state database flooding, which is the goal. In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances. The former is more difficult in IS-IS, as TE information is typically distributed as part of the same LSP that carries the physical link information. Separate protocol instances is of course possible, but it would seem like it would become more of a manageability issue (do you need identical topologies?) and would not obviate the need for CPU cycles. 2) Speed of convergence of wavelength availability In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high. So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it). I'm not sure that I would characterize it as 'crucial'. It would seem like there is always going to be *some* window where remote nodes have imperfect information, just due to speed of light delays. Ergo, the head end must always be prepared for its path to be rejected during setup and then recompute the path based on new information. But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback" information about the failed link, but also assuming that the IGP may have converged in the mean time). Note that crankback (recomputing the path DURING setup) is not always necessary. Sometimes recomputation at the head end will suffice. We can look at a couple of things: - What is the arrival rate of lambda LSPs? - What is the required setup time of lambda LSPs? With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience. In my experience nearly static LSPs are perfectly acceptable, and setup time is not an issue. ;-) My concern however is simpler: limiting the rate of link state database flooding. This is vital to ensure the stability of the IGP. Regards, Tony ------=_NextPart_000_0021_01C9024A.32CE8300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Dan,
 
1) The amount of information advertised
The amount of=20 information carried and the stability of that information is similar = to that=20 used in TE networks today. In those networks, when a TE LSP is = set up or=20 torn down, there is a change in the bandwidth availability on all = links=20 traversed. This causes an update to the TE information advertised in = the IGP=20 for those links. 
 
True.  However, typically the number of TE LSPs = that are=20 established is a static number.  Even in extreme cases, folks = typically use=20 O(n^2) LSPs to form a complete mesh of their nodes.
 
In=20 the applications that I think that you're contemplating, there are many = more=20 links, with the ability of end users to set up their own links = throughout the=20 network.  Please correct me if I'm = misunderstanding.
 
In general, this is not seen as a critical issue. There are = several=20 possibilities to reduce the impact of TE advertisements if they become = a=20 problem. For example, as implemented in some of our current IP = network, each=20 router can impose a threshold (time and/or bandwidth delta) before = which it=20 will not re-issue an advertisement. 
 
Effectively rate limiting the link state database = flooding, which=20 is the goal.
 
 In networks that = require IGP=20 convergence (for IP data traffic) and TE advertisement (for MPLS-TE = traffic)=20 there is some concern that the distribution of TE information might = impact the=20 IGP convergence time. In these cases, implementations may prioritise = normal=20 LSAs ahead of opaque LSAs, or may use separate protocol = instances. 
 
The=20 former is more difficult in IS-IS, as TE information is typically = distributed as=20 part of the same LSP that carries the physical link information.  = Separate=20 protocol instances is of course possible, but it would seem like it = would become=20 more of a manageability issue (do you need identical topologies?) and = would not=20 obviate the need for CPU cycles.
 
 2) Speed of convergence of = wavelength=20 availability
In a TE network, the need for an up-to-date TED = depends to=20 a good degree on the relative size of LSPs and residual bandwidth, and = on the=20 rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite = large,=20 but in general, the rate of arrival of large LSPs is quite low, and = the=20 holding times are quite high.

So, the bottom line in a TE = network is=20 that when an LSP needs more bandwidth than is actually available, it = is=20 crucial that the TED is up-to-date (or "real-time" like some folks may = call=20 it). 
 
I'm=20 not sure that I would characterize it as 'crucial'.  It would seem = like=20 there is always going to be *some* window where remote nodes have = imperfect=20 information, just due to speed of light delays.  Ergo, the head end = must=20 always be prepared for its path to be rejected during setup and then = recompute=20 the path based on new information.
 
 But as Igor has = pointed out,=20 this is impossible to achieve in a distributed system. Indeed, it is=20 impossible to achieve even in a centralised system since network = failures may=20 occur. That means that there is always a possibility that a computed = path will=20 be signaled and will fail to be established. We should be familiar = with this=20 situation in scenarios such as contention during restoration after = network=20 failure, and the signaling protocols are designed to fail and try = again=20 (usually using "crankback"  information about the failed link, = but also=20 assuming that the IGP may have converged in the mean time). 
 
Note=20 that crankback (recomputing the path DURING setup) is not always=20 necessary.  Sometimes recomputation at the head end will=20 suffice.
 
 We can look at a = couple of=20 things:
- What is the arrival rate of lambda LSPs?
- What is the = required setup time of lambda LSPs?

With the exception of = restoration=20 LSPs, I think we may say that a 5-10 second delay in LSP = setup time=20 for 1 in 50 LSPs would be acceptable, but you may have a different=20 experience. 
 
 
In my=20 experience nearly static LSPs are perfectly acceptable, and setup time = is not an=20 issue.  ;-)
 
My=20 concern however is simpler: limiting the rate of link state database=20 flooding.  This is vital to ensure the stability of the=20 IGP.
 
Regards,
Tony
  
------=_NextPart_000_0021_01C9024A.32CE8300-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Aug 2008 03:18:16 +0000 Date: Wed, 20 Aug 2008 11:15:53 +0800 From: Dan Li Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: tony.li@tony.li, 'Igor Bryskin' , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <03e101c90273$0dd3aac0$394d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)" This is a multi-part message in MIME format. --Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Tony, Igor, I think we should separate two points for this discussion. 1) The amount of information advertised The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links. In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement. In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances. Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern. 2) Speed of convergence of wavelength availability In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high. So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it). But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback" information about the failed link, but also assuming that the IGP may have converged in the mean time). As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation. We can look at a couple of things: - What is the arrival rate of lambda LSPs? - What is the required setup time of lambda LSPs? With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience. Regards, Dan ----- Original Message ----- From: Tony Li To: 'Igor Bryskin' ; 'Dan Li' ; adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org Sent: Tuesday, August 19, 2008 3:43 AM Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Igor, Dan, Perhaps there's an important distinction to be made here. Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure. Debouncing techniques should be used to prevent any connectivity oscillations. However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time. Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale. This of course won't match many folks' requirements for 'real-time'. Tony ---------------------------------------------------------------------------- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin Sent: Monday, August 18, 2008 8:15 AM To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Tony, Igor,
 
I think we should separate two points for this discussion.

1) The amount of information advertised
The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links.

In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement.

In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances.

Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern.

2) Speed of convergence of wavelength availability
In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high.

So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it).

But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback"  information about the failed link, but also assuming that the IGP may have converged in the mean time).

As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation.

We can look at a couple of things:
- What is the arrival rate of lambda LSPs?
- What is the required setup time of lambda LSPs?

With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience.
Regards,
 
Dan
 
----- Original Message -----
From: Tony Li
Sent: Tuesday, August 19, 2008 3:43 AM
Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

 
Igor, Dan,
 
Perhaps there's an important distinction to be made here.  Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure.  Debouncing techniques should be used to prevent any connectivity oscillations.
 
However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time.  Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale.  This of course won't match many folks' requirements for 'real-time'.
 
Tony
 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <danli@huawei.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian



--Boundary_(ID_Qt1ZL212CIMB5FZ08nclmA)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Aug 2008 19:46:20 +0000 Reply-To: From: "Tony Li" To: "'Igor Bryskin'" , "'Dan Li'" , , , Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Date: Mon, 18 Aug 2008 12:43:27 -0700 Message-ID: <30CDDADB3BE248069E16208195D56458@ad.redback.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0126_01C90130.10DE6C80" Thread-Index: AckBSK952Mj6IUCkSguZjw/s3lCgxAAIS1ag This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C90130.10DE6C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Igor, Dan, Perhaps there's an important distinction to be made here. Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure. Debouncing techniques should be used to prevent any connectivity oscillations. However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time. Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale. This of course won't match many folks' requirements for 'real-time'. Tony _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin Sent: Monday, August 18, 2008 8:15 AM To: Dan Li; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian ------=_NextPart_000_0126_01C90130.10DE6C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Igor, Dan,
 
Perhaps there's an=20 important distinction to be made here.  Typically, having an IGP = carry=20 lambda connectivity status isn't a significant issue, as that = should=20 only change when there is a significant failure.  Debouncing = techniques=20 should be used to prevent any connectivity=20 oscillations.
 
However, carrying lambda utilization status = in the IGP=20 is not going to prove practical, as the continued series of updates = would easily=20 lead to IGP thrash if done at anything approaching real-time.  Note = that=20 carrying utlization on a low-frequency basis (e.g., cycle time of 1 = minute) is=20 probably not an issue for networks of reasonable scale.  This of = course=20 won't match many folks' requirements for = 'real-time'.
 
Tony
 

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor=20 Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: = Dan Li;=20 adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com;=20 ccamp@ops.ietf.org
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Dan,

That's the point. How does PCE maintain the lambda=20 availability status? PCE architecture shyly puts this problem out of = its=20 scope, but the only known way today for the PCE is to participate in = one or=20 more IGP-TEor BGP-TE routing protocols. So, in this respect it does = not matter=20 whether paths are computed locally or via PCE = service.

Igor

-----=20 Original Message ----
From: Dan Li <danli@huawei.com>
To: = Igor=20 Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk;=20 Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, = August=20 15, 2008 1:55:04 AM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE = link lambda=20 available status should be precise and real time updated. If we do the = path=20 computation in distribute way, this would be a big problem because of = the TE=20 link lambda available status may not be updated right away. But we can = do it=20 in centralized way to minimized this problem. For example, using PCE = and if=20 the PCE can maintain the TE link lambda available status, this may not = be a=20 problem because all the path computation requests are in the queue of = PCE, and=20 PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
From:=20 Igor = Bryskin
To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fu= jitsu.com=20 ; ccamp@ops.ietf.org ; danli@huawei.com
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for=20 IB>>

Cheers,
Igor

-----=20 Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To:= Snigdho.Bardalai@us.fu= jitsu.com;=20 ccamp@ops.ietf.org; danli@huawei.com
Sent: = Monday,=20 August 11, 2008 1:24:50 PM
Subject: Re: Comments on=20 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering = what=20 were the objectives for the IGP evaluation. IMHO the evaluation = from WSON=20 perspective should address the following:
1. IGP usage in the = context=20 of traditional distributed solutions for WSON
[Dan] With the situation that TE information is = already be=20 carried by IGP, it's nature to think that the wavelength = information can=20 also be carried by IGP. I am not saying it should be, but it's = worth to=20 look at.

IB>> There is an important difference in=20 requirements for advertising of TE link information vs. = advertising TE=20 link lambda availability. When OSPF TE speaker advertises TE link = info it,=20 apart from link statical information, is pretty much saying : "I = have 70%=20 of bandwdith availbale on priority p". For the path computer (say, = PCE) it=20 is almost always not important if the link has actually 75%, 70% = or 60% of=20 available bandwidth. However, lambda availability (like pregnancy) = is=20 boolen: either it is there ot it is not. PCE which perfoms path=20 computation in terms of lambdas, unfortunately. must have almost=20 momentarily lambda availability states. With the speed of TE info = flooding=20 current IGP-TE protocols have to offer, such mechanism will not = work on=20 dynamic networks. And in any case one can never rely on PCE during = recovery path computations. These limitations. I think, should be = clearly=20 stated in the document.

[Bardalai,=20 Snigdho] Do you see any particular issues with using the IGP for = this=20 purpose ?
[Dan] From the result of the = simulation, the=20 OSPF convergency time takes a liitle bit longer when the = entire=20 network restarts. Because the WSON information is added in = the OSPF=20 LSA. During the network running normally, the update of = wavelength=20 availability information doesn't impact the IGP = performance=20 obviously.
[Adrian] Certainly, from the point of = view of=20 someone coming at this without an implementation (I used to = have one=20 :-), the concern is that adding the RWA information to the IGP = might mean=20 that there was simply too much information to be distributed. What = Dan's=20 draft is trying to do is show the dimensions of the information=20 and how dynamic it is. From this, we can quickly see how = things will=20 scale.
I do not believe = that there=20 is an issue with the interaction with IP routing, but I guess we = should=20 consider that it is possible that the DCN will be a real IP = network=20 carrying other traffic and that we need to not disrupt IGP = convergence in=20 that network. Mechanisms exist (or are being developed) to make = that safe,=20 and Dan's I-D should be able to tell us how important it is to use = them.
 
2. IGP usage in the context of = PCE=20 solutions for WSON
[Dan] It's a potential = way for=20 PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location = where=20 path-computation takes place is it possible to limit LSA = advertisements=20 from PCC to PCE neighbors, instead of to every PCC = neighbor?
[Dan] You are right, PCC which doesn't = do the=20 path-computation doesn't need this kind of = information.
[Adrian] This is = an important=20 point which you raised in conversation with me in Dublin: it is = possible=20 to consider using link-local scope flooding of RWA information = from PCC to=20 PCE so that it goes no further. But there is a clear trade-off... = with how=20 many PCCs will a PCE be required to maintain an IGP association? = There is=20 also a quesiton to be answered about the function required for = restoration=20 - how much information does the head-end LSR need to perform = rapid,=20 "best-effort" path computation to restore LSPs after a network = failure?=20 This information *does* need to be flooded. The informaiton model = I-D is=20 intended to help with this question.

3. = Flooding and=20 refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the = performance of=20 IGP.
[Bardalai, Snigdho] Is it = possible to=20 limit refreshing of static LSA? Ex. using the OSPF "do not age"=20 concept?
[Dan] Yes, it's possible to take this = way to=20 reduce the protocol traffic. But we should consider the scenario = when a=20 node gets restart or goes down, so the HELLO message may still = need to be=20 kept.
[Adrian] Yes. You = are both=20 right. We should treat "static" as truely static and not needing = refresh.=20 We can handle node-down and link-down events without the need to = time out=20 the LSAs containing the static data if we link the behavior to the = time-out of other node/link information. But we *do* need to = consider the=20 amount of information that will be held in LSA DBs and need to be = flooded=20 at start of day and in node restart as = below.

4. Data=20 base sync-up during node restarts
[Dan] = Yes, this=20 should be considered. Especially the very large amount of data = will be=20 sent to the restarting node. We may consider the point to point = data=20 exchange instead of flooding the LSA updates. Or slice the big = data packet=20 into small pieces.
[Bardalai, = Snigdho] This=20 is little tricky, I would be interested to see if there is a clean = solution.
[Adrian] An important point to consider = (in OSPF)=20 is what happens in a lossy environment if the LSA gets very large. = In this=20 case it will be fragmented into very many IP packets and there = will be a=20 good statistical likelihood of at least one packet being lost. = That means=20 that the LSA might never get delivered whiled the DCN will get = hammered.=20 One solution (thanks, Igor) is to break the information down into = smaller=20 LSAs. Since the information is essentially lists or matrices, this = is=20 quite easy to do.

Could you please let me know = if the=20 above is within the current scope? I believe that these are = important.=20
[Adrian] Very much in = scope!
 
Cheers,
Adrian


------=_NextPart_000_0126_01C90130.10DE6C80-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Aug 2008 15:17:13 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=k5A9ruuiDkj8x3xSvbXZ3MdcpOww0MIBYrmp56+RjtvdfOQh2i1mFpXOa5P2ikuWRZ4FHppxATRqCBNYEEi2k2C4RvYEUm9WRYdYhyP3V4mzHGo3QzdrZV67O6QsqlBl5NHaCQLXMGZJwrtszuaiO4IgyCVtXAFeTxqNaiQmXI0=; Date: Mon, 18 Aug 2008 08:15:26 -0700 (PDT) From: Igor Bryskin Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: Dan Li , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-391644484-1219072526=:51910" Message-ID: <563325.51910.qm@web36801.mail.mud.yahoo.com> --0-391644484-1219072526=:51910 Content-Type: text/plain; charset=us-ascii Dan, That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service. Igor ----- Original Message ---- From: Dan Li To: Igor Bryskin ; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August 15, 2008 1:55:04 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --0-391644484-1219072526=:51910 Content-Type: text/html; charset=us-ascii
Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor

----- Original Message ----
From: Dan Li <danli@huawei.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk; Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian



--0-391644484-1219072526=:51910-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Aug 2008 15:17:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: R: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Date: Fri, 15 Aug 2008 17:15:58 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684EEAF81@esealmw110.eemea.ericsson.se> Thread-Topic: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Thread-Index: Acj+6dISuH7s3gxgSGqiSexIJF2/QQ== From: "Diego Caviglia" To: Cc: , , "Diego Caviglia" , , , , , Stewart, I think i agree here. Even if i'm coming from sdh i don'e see the need to hane osi capability in brand new mpls-tp boxes. Br Diego Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Aug 2008 13:45:32 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 15 Aug 2008 14:43:22 +0100 Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) From: Ben Niven-Jenkins To: Maarten Vissers , , 'Adrian Farrel' CC: , , 'Italo Busi' Message-ID: Thread-Topic: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Thread-Index: Acj7qj3OFgdIw17KRmq76189Mj92hACuhA3QAB4lB9g= Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Maarten, I agree that OSI is still present in many transport network elements and therefore DCN support for OSI will be required for some DCNs. However, does this lead to a requirement that MPLS-TP equipment *must* support OSI? Modern transport gear also supports IP for DCN and this is the direction many operators are choosing to move. So it would appear to me that the requirements placed on DCN design in general are different to the requirements placed on the transport equipment itself (which will be controlled via the DCN). Let me use BT's transmission DCN as an example - we have a significant sized DCN consisting of several thousand routers/switches (just for the transmission DCN itself). It supports both OSI and IP. Therefore we are able to accommodate new transport equipment control via IP while maintaining control of old transport equipment via OSI. Ben On 15/08/2008 00:27, "Maarten Vissers" wrote: > Do routers today only support IPv6, or are there still many of the older > protocols supported? I assume it is the latter case, as it is difficult to > switch off support for older protocols as long as its original equipment is > still present at some places in the network. I.e. wouldn't it be in the long > term economic interest of the customer to migrate to IPv6 only? When do you > think you can switch of support for IPv4 and older protocols in the routers? > > With OSI in the DCN we have a similar situation. It is still present in many > network elements and must as such be supported within the existing and > future DCN. > > Regards, > Maarten > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 11 August 2008 13:52 > To: Adrian Farrel > Cc: Maarten Vissers; 'Diego Caviglia'; 'Italo Busi'; 'Francesco Fondelli'; > julien.meuric@orange-ftgroup.com; ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) > > These control channels are the last vestige of OSI in modern networks (apart > from ISIS which is alive and well). Surely it is in the long term economic > interests of the customer (infrastructure equipment costs, training, > commonality etc) to migrate to IP? > > Stewart >> > > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 15 Aug 2008 05:57:17 +0000 Date: Fri, 15 Aug 2008 13:55:04 +0800 From: Dan Li Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: Igor Bryskin , adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org Message-id: <00d601c8fe9b$77003f30$394d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)" This is a multi-part message in MIME format. --Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Igor, You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available. Regards, Dan ----- Original Message ----- From: Igor Bryskin To: adrian@olddog.co.uk ; Snigdho.Bardalai@us.fujitsu.com ; ccamp@ops.ietf.org ; danli@huawei.com Sent: Tuesday, August 12, 2008 4:25 AM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda available status should be precise and real time updated. If we do the path computation in distribute way, this would be a big problem because of the TE link lambda available status may not be updated right away. But we can do it in centralized way to minimized this problem. For example, using PCE and if the PCE can maintain the TE link lambda available status, this may not be a problem because all the path computation requests are in the queue of PCE, and PCE knows which lambda is available.
 
Regards,
 
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian


--Boundary_(ID_oHdnSBmjsjaRSUNKm1STlw)-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Aug 2008 09:05:25 +0000 Message-Id: <200808130902.m7D929Xi030025@mta4.iomartmail.com> Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: Adrian Farrel To: ccamp@ops.ietf.org Subject: BGP TE attr last call by softwires WG Reply-To: adrian@olddog.co.uk Date: Wed, 13 Aug 2008 10:02:08 +0100 Cc: dward@cisco.com, alain_durand@cable.comcast.com, softwires@ietf.org [Forwarding to the correct CCAMP mailing address]=0D =0D From: David Ward =0D To: David Ward , =0D Alain Durand , softwires@ietf.org =0D Sent: Tue Aug 12 23:48 =0D Subject: BGP TE attr last call by softwires WG =0D =0D The softwire WG has LC'ed =0D =0D http://www.ietf.org/internet-drafts/draft-ietf-softwire-bgp-te- =0D attribute-01.txt =0D =0D We will keep open an additional two-week period for wider review =0D before moving forward in the publication process. Please have any =0D comments to the authors and softwires WG by Aug 26, 2008. =0D =0D -DWard, Alain Durand =0D =0D bcc: l1vpn@ietf.org, ccamp@ietf.org, mpls@ietf.org, idr@ietf.org, =0D isis-wg@ietf.org, l3vpn@ietf.org, ospf@ietf.org =0D Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Aug 2008 17:02:01 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Tue, 12 Aug 2008 17:59:47 +0100 Subject: Re: [mpls-tp] MPLS over OTN From: Ben Niven-Jenkins To: , , CC: , Message-ID: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RzhHZYPvGZHKQvSW9uyhF8h+KQAAEiUwAZVUm78= Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Catching up on mails... On 04/08/2008 16:48, "julien.meuric@orange-ftgroup.com" wrote: > Hi Francesco. > > I guess I understand your concern. I believe the original intention was > to say implicitely "It MUST be possible to operate and configure the > MPLS-TP data (transport) plane without any IP functionality *in the data > plane*." My interpretation of these requirements is indeed that they > apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment, > nor the MPLS-TP control plane... Correct. > Anyway you're right, this could be confusing and it deserves a small > rewording. I have reworded to: "It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality in the MPLS-TP data plane." Ben Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Aug 2008 08:53:35 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Aug 2008 08:39:53 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.C245D28C198@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-01.txt Pages : 11 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072257.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Aug 2008 20:26:58 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=D1RtXxhE9YF7aoPoxjy/3xv2o0bcTJpjf2daOWEfxP5ofGiAIKCDSqMfz5RU/HaA1f9Xh7wnYqTopgQRwj3AwSqJZU0U72rlR59+bkKYGugxYQQKbw3C4m4f2bWW2/X4OLh0mTb8N4RCLw3kvdY7aBZAusZ9Q+bYVz8jovCBfFM=; Date: Mon, 11 Aug 2008 13:25:39 -0700 (PDT) From: Igor Bryskin Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' To: adrian@olddog.co.uk, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org, danli@huawei.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2020219236-1218486339=:64307" Message-ID: <226870.64307.qm@web36803.mail.mud.yahoo.com> --0-2020219236-1218486339=:64307 Content-Type: text/plain; charset=us-ascii Hi, Please, see my comment in line. Look for IB>> Cheers, Igor ----- Original Message ---- From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com Sent: Monday, August 11, 2008 1:24:50 PM Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Hi, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. [Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale. I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. [Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. [Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. [Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do. Could you please let me know if the above is within the current scope? I believe that these are important. [Adrian] Very much in scope! Cheers, Adrian --0-2020219236-1218486339=:64307 Content-Type: text/html; charset=us-ascii
Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <adrian@olddog.co.uk>
To: Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org; danli@huawei.com
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,
I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
 
Cheers,
Adrian


--0-2020219236-1218486339=:64307-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Aug 2008 17:42:57 +0000 Date: Mon, 11 Aug 2008 15:33:01 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" Cc: "Ccamp (E-mail)" Message-id: <00d701c8fb84$7c2f2b20$394d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)" This is a multi-part message in MIME format. --Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, I copied the original text here for easy read. See my comments below. ===== Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. ===== Thanks, Dan --Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,

I copied the original text here for easy read. See my comments below.
=====
Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.
=====

Thanks,
 
Dan
--Boundary_(ID_5PjSSN4hC0APVtmjRd4l2A)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Aug 2008 17:37:45 +0000 From: Anders Gavler To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Mon, 11 Aug 2008 14:10:18 +0200 Subject: RE: Poll for RWA Info model as WG I-D Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GcsKP1xvGVaFTj6vtGImL2XKXAEkWXsA Message-ID: <73B74934786FBB4F951B5F99724CEB601D43B6A3C1@acreoexc01.ad.acreo.se> Accept-Language: sv-SE, en-US Content-Language: en-US acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Yes. Regards, Anders > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behal= f > Of Adrian Farrel > Sent: den 5 augusti 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed > to > be pretty mature. > > Note that despite the file name, the content of this document is > consistent > with its title: "Routing and Wavelength Assignment Information Model for > Wavelength Switched Optical Networks." That is, the scope is limited to > the > information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Aug 2008 17:25:58 +0000 Message-Id: <200808111724.m7BHOoX1026357@mta5.iomartmail.com> Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 From: Adrian Farrel To: Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org, danli@huawei.com Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt' Reply-To: adrian@olddog.co.uk Date: Mon, 11 Aug 2008 18:24:50 +0100 =0D =0D
Hi,
=0D
=0D
I have the following comments on this draft. I was wondering what were= the objectives for the IGP evaluation. IMHO the evaluation from WSON persp= ective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON <= BR> [Dan] With the situation that TE information is alrea= dy be carried by IGP, it's nature to think that the wavelength information = can also be carried by IGP. I am not saying it should be, but it's worth to= look at.
[Bardalai, Snigdho] Do you see any particular = issues with using the IGP for this purpose ?
=0D
[Dan] From the result of the simulation, th= e OSPF convergency time takes a liitle bit longer when the entire netw= ork restarts. Because the WSON information is added in the OSPF LSA.&n= bsp;During the network running normally, the update of wavelength availabil= ity information doesn't impact the IGP performance obviously.
=0D
[Adrian] Certainly, from the point of view of so= meone coming at this without an implementation (I used to have one :-)= , the concern is that adding the RWA information to the IGP might mean that= there was simply too much information to be distributed. What Dan's draft = is trying to do is show the dimensions of the information and how dyna= mic it is. From this, we can quickly see how things will scale.=0D
I do not believe that ther= e is an issue with the interaction with IP routing, but I guess we should c= onsider that it is possible that the DCN will be a real IP network carrying= other traffic and that we need to not disrupt IGP convergence in that netw= ork. Mechanisms exist (or are being developed) to make that safe, and Dan's= I-D should be able to tell us how important it is to use them.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelen= gth information.
[Bardalai, Snigdho] Since the PCE is the locat= ion where path-computation takes place is it possible to limit LSA advertis= ements from PCC to PCE neighbors, instead of to every PCC neighbor?<= /DIV>=0D
[Dan] You are right, PCC which doesn't do the pa= th-computation doesn't need this kind of information.
=0D
[Adrian] This is an import= ant point which you raised in conversation with me in Dublin: it is possibl= e to consider using link-local scope flooding of RWA information from PCC t= o PCE so that it goes no further. But there is a clear trade-off... with ho= w many PCCs will a PCE be required to maintain an IGP association? There is= also a quesiton to be answered about the function required for restoration= - how much information does the head-end LSR need to perform rapid, "best-= effort" path computation to restore LSPs after a network failure? This info= rmation *does* need to be flooded. The informaiton model I-D is intended to= help with this question.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance= of IGP.
[Bardalai, Snigdho] Is it possible to limit re= freshing of static LSA? Ex. using the OSPF "do not age" concept?=0D
[Dan] Yes, it's possible to take this way to red= uce the protocol traffic. But we should consider the scenario when a node g= ets restart or goes down, so the HELLO message may still need to be kept.
=0D
[Adrian] Yes. You are both= right. We should treat "static" as truely static and not needing refresh. = We can handle node-down and link-down events without the need to time out t= he LSAs containing the static data if we link the behavior to the time-out = of other node/link information. But we *do* need to consider the amount of = information that will be held in LSA DBs and need to be flooded at start of= day and in node restart as below.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the = very large amount of data will be sent to the restarting node. We may consi= der the point to point data exchange instead of flooding the LSA updates. O= r slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I w= ould be interested to see if there is a clean solution.
=0D
[Adrian] An important point to consider (in OSPF= ) is what happens in a lossy environment if the LSA gets very large. In thi= s case it will be fragmented into very many IP packets and there will be a = good statistical likelihood of at least one packet being lost. That means t= hat the LSA might never get delivered whiled the DCN will get hammered. One= solution (thanks, Igor) is to break the information down into smaller LSAs= . Since the information is essentially lists or matrices, this is quite eas= y to do.
=0D

Could you please let me know if the above is within the current scop= e? I believe that these are important.
[Adrian] Very much in scope!
=0D
 
=0D
Cheers,
=0D
Adrian
=0D =0D
Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Aug 2008 16:27:03 +0000 Date: Mon, 11 Aug 2008 09:48:59 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" , "Ccamp (E-mail)" Message-id: <003c01c8fb54$6c656c70$394d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)" This is a multi-part message in MIME format. --Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, I copied the original text here for easy read. See my comments below. ===== Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ? [Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor? [Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept? [Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution. Could you please let me know if the above is within the current scope? I believe that these are important. Thanks, Snigdho --Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,

I copied the original text here for easy read. See my comments below.
=====
Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.

Could you please let me know if the above is within the current scope? I believe that these are important.
Thanks,
Snigdho
--Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Aug 2008 17:32:17 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808173001.AC8423A6CD3@core3.amsl.com> Date: Fri, 8 Aug 2008 10:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Pages : 11 Date : 2008-08-08 This document describes two technology independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08102841.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Aug 2008 15:43:44 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) Cc: ccamp@ops.ietf.org Reply-To: internet-drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Aug 2008 14:34:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F963.D441DBD9" Subject: IETF 72 Draft CCAMP Minutes Date: Fri, 8 Aug 2008 10:34:13 -0400 Message-ID: Thread-Topic: IETF 72 Draft CCAMP Minutes Thread-Index: Acj5Y9P1zDI7wLBFT1aYNi7bXeS4pQ== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F963.D441DBD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's the draft meeting minutes - please take a look and mail the chairs if there are changes (or additions/corrections on the names for folks at the mike): http://www.ietf.org/proceedings/08jul/minutes/ccamp.htm =20 Much thanks to our minute takers - Dan King, Dave Walters, and Wouter Tavernier! =20 Adrian and Deborah =20 ------_=_NextPart_001_01C8F963.D441DBD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here's = the draft=20 meeting minutes - please take a look and mail the chairs if there are = changes=20 (or additions/corrections on the names for folks at the=20 mike):
http://w= ww.ietf.org/proceedings/08jul/minutes/ccamp.htm
 
Much = thanks to our=20 minute takers - Dan King, Dave Walters, and Wouter=20 Tavernier!
 
Adrian = and=20 Deborah
 
------_=_NextPart_001_01C8F963.D441DBD9-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Aug 2008 14:32:02 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.BF6EE28C195@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-02.txt Pages : 17 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072254.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Aug 2008 14:31:54 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808143001.C245D28C198@core3.amsl.com> Date: Fri, 8 Aug 2008 07:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-01.txt Pages : 11 Date : 2008-08-08 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-08072257.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 11:09:37 +0000 Message-ID: <489AD6A6.4070604@lab.ntt.co.jp> Date: Thu, 07 Aug 2008 20:04:06 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Yes. I agree that the draft is ready to be adopted as a working group I-D. Kohei Adrian Farrel ă•ă‚“ă¯æ›¸ăă¾ă—ăŸ: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 07:35:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:35:04 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C595A5@ftrdmel2> Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GSqnGDEdvJJ9Q+KhIJRfVyBxhwBRnHVQ From: To: , Hi. In favor of WG topic. Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed to=20 be pretty mature. Note that despite the file name, the content of this document is = consistent=20 with its title: "Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks." That is, the scope is limited to = the=20 information model for RWA. Can we have your opinion, please, on whether this document is ready to = be=20 adopted as a working group I-D. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 07:23:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:19:15 +0200 Message-ID: Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQQ2caLEhnPbRJGPPSMvKLLMfABRNrtQ From: "Daniele Ceccarelli" To: I am in favor of this document being adopted. Cheers, Daniele -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Sent: marted=EC 5 agosto 2008 18.24 To: ccamp@ops.ietf.org Subject: Poll for RWA Info model as WG I-D Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed to=20 be pretty mature. Note that despite the file name, the content of this document is = consistent=20 with its title: "Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks." That is, the scope is limited to = the=20 information model for RWA. Can we have your opinion, please, on whether this document is ready to = be=20 adopted as a working group I-D. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 04:10:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F843.5BB78328" Subject: RE: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Date: Wed, 6 Aug 2008 23:09:16 -0500 Message-ID: Thread-Topic: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Thread-Index: Acjztl9VwpF8Jw4hQhGyKIB3iAEo2QEiVE8Q From: "Bardalai, Snigdho" To: "Dan Li" , "Ccamp (E-mail)" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F843.5BB78328 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan, =20 Please see my response below. =20 Thanks, Snigdho -----Original Message----- From: Dan Li [mailto:danli@huawei.com] Sent: Friday, August 01, 2008 4:10 AM To: Bardalai, Snigdho; Ccamp (E-mail) Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Snigdho, =20 Very good question! See my comments below. =20 Thanks, =20 Dan ----- Original Message -----=20 From: Bardalai, Snigdho =20 To: Ccamp (E-mail) =20 Sent: Friday, August 01, 2008 4:26 AM Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Adrian and Dan,=20 I have the following comments on this draft. I was wondering what were = the objectives for the IGP evaluation. IMHO the evaluation from WSON = perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for = WSON=20 [Dan] With the situation that TE information is already be carried by = IGP, it's nature to think that the wavelength information can also be = carried by IGP. I am not saying it should be, but it's worth to look at. [Bardalai, Snigdho] Do you see any particular issues with using the IGP = for this purpose ?=20 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. [Bardalai, Snigdho] Since the PCE is the location where path-computation = takes place is it possible to limit LSA advertisements from PCC to PCE = neighbors, instead of to every PCC neighbor? 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. [Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? = Ex. using the OSPF "do not age" concept? 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount = of data will be sent to the restarting node. We may consider the point = to point data exchange instead of flooding the LSA updates. Or slice the = big data packet into small pieces. [Bardalai, Snigdho] This is little tricky, I would be interested to see = if there is a clean solution. Could you please let me know if the above is within the current scope? I = believe that these are important.=20 Thanks,=20 Snigdho=20 ------_=_NextPart_001_01C8F843.5BB78328 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi=20 Dan,
 
Please=20 see my response below.
 
Thanks,
Snigdho
-----Original Message-----
From: Dan Li=20 [mailto:danli@huawei.com]
Sent: Friday, August 01, 2008 4:10 = AM
To: Bardalai, Snigdho; Ccamp (E-mail)
Subject: = Re:=20 Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Snigdho,
 
Very good question! See my comments below.
 
Thanks,
 
Dan
----- Original Message -----
From:=20 Bardalai, = Snigdho
Sent: Friday, August 01, 2008 = 4:26=20 AM
Subject: Comments on=20 "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Adrian and Dan,

I have the following comments on this = draft. I=20 was wondering what were the objectives for the IGP evaluation. IMHO = the=20 evaluation from WSON perspective should address the = following:

1. IGP usage in the context of = traditional=20 distributed solutions for WSON

[Dan] With the situation = that TE=20 information is already be carried by IGP, it's nature to think that = the=20 wavelength information can also be carried by IGP. I am not saying = it should=20 be, but it's worth to look at.
[Bardalai, Snigdho] Do you see=20 any particular issues with using the IGP for this purpose=20 ? 


2. = IGP usage in the=20 context of PCE solutions for WSON

[Dan] = It's a potential=20 way for PCE to get the wavelength information.
[Bardalai, = Snigdho] Since=20 the PCE is the location where path-computation takes place is it = possible to=20 limit LSA advertisements from PCC to PCE neighbors, instead of to = every PCC=20 neighbor?


3. = Flooding and=20 refresh of static and dynamic link state updates

[Dan] Try to figure out the = impact to=20 the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit = refreshing of=20 static LSA? Ex. using the OSPF "do not age"=20 concept?


4. Data base sync-up during node = restarts

[Dan] Yes, this should be=20 considered. Especially the very large = amount of=20 data will be sent to the restarting node. We may consider the point = to point=20 data exchange instead of flooding the LSA updates. Or slice the big = data=20 packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I = would be=20 interested to see if there is a clean=20 solution.

Could you please let me know if the = above is=20 within the current scope? I believe that these are important. =

Thanks,
Snigdho=20





------_=_NextPart_001_01C8F843.5BB78328-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 01:43:36 +0000 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D MIME-Version: 1.0 Message-ID: From: gao.feng1@zte.com.cn Date: Thu, 7 Aug 2008 09:44:43 +0800 Content-Type: multipart/related; boundary="=_related 00094E9C4825749E_=" This is a multipart message in MIME format. --=_related 00094E9C4825749E_= Content-Type: multipart/alternative; boundary="=_alternative 00094E9C4825749E_=" --=_alternative 00094E9C4825749E_= Content-Type: text/plain; charset="US-ASCII" Yes, I support this draft to be a WG I-D. Best regard, Feng Gao > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 06, 2008 1:24 AM > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00094E9C4825749E_= Content-Type: text/html; charset="US-ASCII"
Yes, I support this draft to be a WG I-D.

Best regard,
Feng Gao


> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Wednesday, August 06, 2008 1:24 AM
> To: ccamp@ops.ietf.org
> Subject: Poll for RWA Info model as WG I-D
>
> Hi,
>
> draft-bernstein-ccamp-wson-info-03.txt was discussed in
> Dublin and seemed to be pretty mature.
>
> Note that despite the file name, the content of this document
> is consistent with its title: "Routing and Wavelength
> Assignment Information Model for Wavelength Switched Optical
> Networks." That is, the scope is limited to the information
> model for RWA.
>
> Can we have your opinion, please, on whether this document is
> ready to be adopted as a working group I-D.
>
> Thanks,
> Adrian and Deborah
>
>
>
>
> 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00094E9C4825749E_=-- --=_related 00094E9C4825749E_= Content-Type: image/gif Content-ID: <_1_07AA7B1007AA78E800094E9A4825749E> Content-Transfer-Encoding: base64 R0lGODdhXAIIAXcAACH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAAXAIIAYf///8A Wq0AAAAASqVjUkJKOinv7/cpGRBjUjq1zt5zWkJza0r37/dCOhkZGQhjjM6MjJwxIRne3u+Ec1qU nJxKUlIxMRClvd5SSjqEc0qlpa3e3tYxIQhKSjEZUuZavea1jBBava1rnM7F3uaErc7FrYRaSjGc hFqllGsxc7UQGXOU5uZSEErmELUIWq3FxcUQWrVa7+a1jEJa760QjOYZUjHmWjq1WhnmGTrmnDqE WhnmWhDmGRDmnBDmnGPmWmPmGWPm3q17lM6EjISUvd5ajMWU762MhFq1raWMrd61hKUQSoTmEObm nITW3ubm3jrmQrXmlLXm3hDma7Xm3mO1EBmEEBkZUlK9va0Zc61CKRlKOjExKSFKGXulrdbe7+8x jOYQWoQQCBm9zu/mWoS95q3mGYQQSghSe6Vzc3NSUhDmlObmQua1vTqEvTrma+a1vRCEvRC1EEqE EEpSEBC9UqW9GaWUUqWUGaW9Unu9GXuUUnuUGXu9Us5KUu9SpVq9Gc5KGe+UUs5KUsWUGc5KGcVS zlpShBBSzhAZhFoZzloZhBAZzhC1nGvm1oS1nHsQAEpjWnO1MRmEMRkQlK0pveYpva2MvXsIveYI va2MvVpSOimchGs6jK3mvcXmvaVKjMVKGZxrGXvmve8IIVJalKUQISkhY7WUc1q1WlJrUpy17zqE 7zpahO+17xCE7xBCUnNSe71KOkq1MUqEMUqMWkopKUq9hGu9Uu+95ntrUu9SpXsp7+YZKZy9Ge9r Ge8ZKe8p762M73uEjCmEjO+UUu9rUsWUGe9rGcUZKcW1hO9SzntShDFSzjEZhHsZznsZhDEZzjGU zr1Se1pS71pSpRBS7xAZpVoZ71oZpRAZ7xC95loI7+YZCJwZCO8I762M71qEjAgZCMW1hM6UzpxS e3spGQBjY0prGZzv/85CUpRKOhlS73u1pe9SpTFS7zEZpXsZ73sZpTEZ7zGEjErm/0K9tWPv//9a nOZjUkoxUghCOikZSqUZCAAAY60ACAAI/wABCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnT p1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD Cx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hTq17NurXr17Bjy55N u7bt27hz697NG7EAAQ9/ExTeu7jxhMQZJgfwu/ny49DDOgeucXpzldazXze4nPjz6OC3av+vnv2n debeqYdfr7X794nvW45HON45+/tYv6tHv32g/YPxCdQfevztxx+BELmH3HkCGojfg1AFWGB/DBYU 4HT+ldcghglqCCCHHkIo4lISJpcedQNu+B+CCFKI4okiaXedhCPWGJSJK6rY4HAOeqihgiwGqZCM HPK4Io02JmmeekUyCCSP9Dm5X3pQNlRij0TmqOSWPun34os7Zsidg2FaOCWYYloJXH1YHkkml3Dy 5B6aLcJoZpRoArldigsGKZyXWSIZ56AvzTchjlqWOaaLVR765ph+ronlh4RW2lOROiL65pVnNnqg oASyuVCWlpYa15Ojbspnn6a2emqIQz7/Cqqirta6VoW25qrrrrz26itpR1L0KH1mrhrcScNaaaGy DiWbYaLDISfgr5ZNOS18ERlorbDIXqQts+COuiyx5FJbbbR7mhgpc8/6x26o47p74LvvUtjutN7V aSS+XxbrroLfsgvwtfXCKKm8BBNs74YMM5kvouYKRiaK8uZbsMJh0pmwwP92fC3FH1NMZb3/ghzw xSQLmWfIGDPJsssIf1wxxim7/HDMEfcV7LgwwxwtvT5vvObMINc8M74IFz20zOT2jLPSNNvMXcvF LpzyzyZ7zHHOhym959FAf03z0xMiXfbVUPv85Z9gPws10DyD/fbCUv9M79kOW5x2xbNy/w3XtnPL HXXS8ZqN7sZoUz243UUvnjjWgsMNOdwnSz650ZST7TdfgLMsudMtEm7345Zn7fnSn2vdOMqg3/14 66ibjvi2qbPO9Na4O7v5qzju+HaBYjauJaYDnqm2uhaXnrzG8Cr/3O9u2tn87PFazfb0Yhes++4P bj+V99yHHy5X4Itv/vnop6/++uy3775jCYhAwggIjSCEEPQf9EUSIiSQUPxEYEBCSJAEAyhkBEQo SAJGIAESkOACYyCCF0ZAwCQQQQIAGAH/HgCKIoigCB4EoQhBQUISGtAgDRTBGARCgiKAQgQiwB// LnCPgxiACCIo4PuUdMMYXuCEBLlHAv8eIAIifOEgFCwCCSQARIKMQQQP8B9CDBDDIyokigS5QArG MIIUBGAAYAyAGPH3wRSA8YxoPOMX0zgAEtTQIAa4AAwvQIQHFOECXzgiA+ynRCsWJIlCWOEOIWQ/ GATgFPkjyA2LgD+EfEEIRSBCExXZQik6MpILsR8J/liEMUQwAaAIgAtOMYBO0C8BKThFCvwxAFb6 wx8BgKUrY9nKL8IyBYk0SALul0uC7O8BjTSIED0YwEGu54kuaOUARGnJRQYTAAZIwAkNkARMJmQE SlyIAaypECEEIIZ2lCIJEiABIhDhfkTQ4gUM8gUEiiCZrmylK+e5Rhck4YCM7OVAopn/z/qRIId+ NGZvEhCLL9KSld8EAAPkSAIgRjMWA+jfExuqECJ0Upt3VAgqO1iEETAwnQCQwClWSE4AWDQFKSCB AOsHT3kq85XKJKELXjhJBSqxpgNJACMDOhA6WlSHAtUNKm35UpimQASxcEFHDWgAEpxCjAYNAEUH +ACcFkQI90yIAda4zFhcQAIjsGcCXJCFMcRifsk8ZApAIQSrxi8L8XwlPbMgBC+YtAgYTAgDSIDF gkhgDF9gABHO2kQDCMGrIhiAC4TA06DGRotRlWdczwjLQ4LiqcsU4zIVq8okfMEAEbygYUXAVAOY 9h4MMAAChUCEf+4Tmqc14COLsFYS/7hAjPwQpf3k54IFuqCya0xBAs4pgc/e44RjlWtRwZiF/hnQ C6Y0wHFNS13pAoCgDTUtBQ0aC5S6IAU/HOJRzVhLxU7Vsa8ZgxehOs/lytWgaJwsTL94imSCkawB 4KgIXYhSzS4zBZ1AKUpfKAJQCLiD321hWtlbXzGmIK3+cAFZb7tMpcJwv2FoL0znmwIQIvUUL9yv iD+oyhcuGKoofvBmxbhhMbrgvOhNzQhAEcbNbljDcZ0njmsZV6K2sYb3qCEJoApG4Ga2yJAEbooT wGQav7SWLAajCOwHgCH7Q5X9C7JqMavhAWThAiP4wnFr2MUEBPnMYz6tEGMhhN9uNv+M8IXlk1ss xlMkMManeSRRb+xSPu/Yzznusj3nZ9oL7DmetIwlQjVLVKgetQh9PmhM14nXKsPTi+sEwD0uq1xX poCnI4hffTe5kE0vE5bNpTGgO41oMAoXz6O5IYX/TGta9/nPLyYCeYvI5T67d84bVuYa/azMLJzT gBeYHyn9kYUG5hWaCSjyK4mwATh684yIXMgXIM3KiF73z8D2dQAqDWvPgNLGt/Y1sQGd7mCzsrcC aaoUddppya460O7tckevS79tljMLYDwFT28IUxdYNaTDZXIRDq5eRbMSFABILLjlumMXu7HcmjFs VFl9a3Z7XNrtVupBJCCCZUu2yO3/bre7NZwFUhMkrJFMQAuzbRAvFLkIb1yIRRNCcpS/0qMmv/HK Ux6AWFgS45RB5anDvW5bB5sSRQB4tz0d5sZWWcfKHAAl4qtyYPs5APqEJnkTGlKcOjCxYT8ICYTA 82CLkgQbEEEquzz0Fi8axkh3DBUPrW66gxvlXvafBAIQhrWKoBNEQIPVCSIB8royCwkQrPxsm++T 59ilWVipQbKg2cUmwB9F0Coons2QjMa7iWOdMqQDwHZoiiDDtsT3ujOLS8gU9gUbyDkANvCCxRtk A9VuyAl7bxEDvAALWBiB5h9ycM50cemr7nuXi92JcYoA8ntNgWgHQoI7L+StEZUm/ztJ0Amm27vL Aci0QYTw5M2SFiG7fMi283ePDyZyAwbE4TIzrWscexzrFlcTb2RADBRmBdhOYGVaCGiAYLWA2uVR EBiBI3BCDPBGFWh8wGeBGigQFQhN1daB0EQQIAiCWPAC+5QGafCBAkEBaaABCpVzIAhEFOCCmsaB OXdCG0CDGoAFr1WDL2iDQAhNFAABM5gGFGBAG/iDClWDJdiDNShAMJiEjZEEtxV7KSd0rZRhWegP HCUCutdUpHQKBSFHDtFU8KZRv8Vx8dRxrJQFRRAL3jcQquZSrZR225R2B3EBoScQNocGgiQQIxAA XkAEAwBxBnBbs+d0UDYAReB7Kf+xfAlwCjAwSpMoiWQFA0ZkiZaYApMIA1mAiV+AYqKYXwlxDmIg BkPQEC+wD7JAEBtQATyoVRRgggKxAUMAAbEITUMwBEjgEBSQiwqBBRQwEMsXEVgwBNM0BDToEBBA i6BBRZTldBUHU6fgPy/wfgPxBQX1XzknAeSWSeckAg3hBZfHanSHRh0FZvdwAVLHZ2flBbonEPH3 ECRgVzjkQv1DEKjEZP/kTX5nb1e4aANQjTYxAkqmZG30BVU4ipp1QVE1iilgVRXwG5GQEE1oAPvw G874Ar+RBgc3iwMhAcpIAW/0AhQwg/GmAUigAbTIeyZpABrgggyAfLWoAb9oQBL/QAHKCAAvQD8u GZPBx5NA6QXpUBBIAAGu+AIzGZRYUG05uIMG9AJDAJIAgAUrSYsG0JRXWZVQ2RjPp4bS2Ge9RWag wFMQ1UoEORBFcHQKYQAM8EwHBHJ1F2jBlkzz43O+1kqNWBD3sG9lCArPt0lEMG5mtke31V94qYYq 52615ALwSBMJQGRKJkbzAwNydpkoRgSByJBfBHHESBDn0JEiOBBYIAb7YECRIJor+But+JkEQZW7 14wQEHy/qJK7N5XCOAQm+AItqAHpYJtDiEEbAAE7eJIGMJxDgAUMQAG9qAG4qZMYdIwqOQRpQHq3 SQH4p3kouXvVaQDKKJ1VCQG6/wkAGoCLzmmCnlAOzOmcMemcwIgYY8V0YalhscBWF/VyX7RU+iiO D4FNDnEP2FSOKydf8TR65XdvYLSH+th6DrFLRMAPE4gGazSB63Vo9eYPGaaIAChlJxSPKLFSY8BV KKdZJKCQlLV0Z5QEg0dkaRSRCJGaApAGNsQFv5GKWPAbXHBCMCqjCQGbIpmDPOidEhCTIdWLK9iL UnlC7QkBJ/SLA+GkJnmkVYmMumiCzSgQUhl8mrcBOmmELUmlUZqkIRWLIGmLOIiMBpAG+bOT5DmM ijFkUfZ/txYGltdtyxSHApFYoDBJBhALjrh+bLkQ3CagXddp+eVFKddKaBAL8f+4TX9aECLwQwLR ThYEAA+Abox5oROnqd22pywxSdjkYS40S1JFRSAECq/0RW4IQh7FaKcgYqRmizo5lRSQkQIgCye5 izppQGnwG2KQe2IgAP9ggvdAowKwjK4JALBpixIQphSwnLGoWi/AnjzppuSJgtE6lTbpnMMYpeTJ g0SqUBDgCcN5QiJpnfuUg2lggt6pfLioi8rojFeKBUQ4gyx4nEOAQQxwpVVprYfhTXwnp/MFaC5Q fWqHpyyUVQ6xAQraEPdAAqBQCgDZdH1XYwSrfSEqfgTRWhDhjbrXQEIwn+6VoQF5ebVnE9EmZwHw hwCgkAjFnwKxoqzUsARxo4H/0hzsaqwyGpoCkIob0A/CGpQ++KTO+KMGAAFDCq4uKJJEeJQ8+AIQ sFI2CbXVdrQsWYK4V60r6IJYsIxDMAJmGm+zKYIaILRiupLMyoEmeYsGBJLleXwvELf4Spu0iAT+ Khg1BI2FWqgEqliQBBHY5KEK0X0R4QUkEKJZeFA6tqldlwXBd4ivWlgLBxEOtE/kxbfnV7GJGGwD iYct0QlElgK6Z5CaBbMZRGSmSxAacLM4KxBDgKP3AAGsqayzm6xEOxBpy5wUgEHMCQArORDEqbUC YZs2WaUDMQKj0K/Dq7QcOAT4N548ma8FQYQ1G7WxuZ28F7PjeaUvGW8mmLYM/wC94VoY27S3mjoA JEtxCBUGFhWo3aR+wje5D1F/yTawkaaFCOpxJ5tBWZBSVwW/DOFvIUkCUheQ8ll56gtsAcAP7ksS VhWId1cQJspKpgvBreSZBmGzrNuSzcGSvgoAE9mzCsEALBmSzsuTaWC9KOmcI+AJOumCUjkQROqd TwsBSLABWLCu0VttKCmMwLubukmvaVCUrqiMYMubzsiCJrhHaXDDWaqs2AkAtzgCJvmsaQsA7+q7 z0q+TlZrRYV1mZoFFKSwDeGfEJFsEUFliFpZk6VZl2djcdpjoOBJHKhaf5S6DIHGvgS6l/l4YWCF 0XeOixtXZxgTcGpLoCZL3v92vERGs6TZHCiYBra6DygIo/2QSCFMAF8QrGLwAgegkQehnc5oALsr hLTYhCQ8lXHLgzlImrQ4rVE5hFEshEyafDwZiyQcfCa5g0g7msgJARCQS8f4bCZJhME3nEGKBLeI BDi5xSScP8dHvgc6n4SXqWu4cF3kuQbxAGOQDljgCchXguF8fOFcghBADp7wAp+gzuGMBFZplZ4Q BOp8khQQCbBQDvcMC5FQDvtcDv6cz/gc0P3sz/iczwC9z2kAC2lQAkjQ0A1dAhTA0EhQDiVglQz9 CEjA0Bqd0RxNAeWA0RQA0kOgz3YKcCpUwHVneRPbt8w0tCYxSfdgRlDlyBL/4Gagx3gHtaeflUfD 56srtaMCkQ7BKgBJ/BtIuQ/7YJK/sQ+656GwKRHNF8oFsVJUXRBZaa5UGsoCtHzjO5peDRFRnRcG 0MXmO0sBaUoCEQtkzBD+iQKokAETUAsLsAC1ANd1XQtxPQFwPQETQA8ocAKA/dYZkAF1nQEn4NYZ QNcLcAScANiGfQQnwAmNzQmocAIZ8NaWbdkTcAKP8AiN4NaWDdeX3QglUAKPgAJ8/dZyrQALMAGo UNmf3QiNwAl8vdcnsNm4Pdd43dq1cA4I8NsLQA+woEREkA5JEFEBCsYqLVd/vJh06ALavBEHF5lu LEU5R7pfVMEoFmESNolS/7S6AnAAVsSzPDoCQCsAnoC7YuCm+SMLv3G3xaiszmgTy4mL9Gqk8f17 Rym0nZFzkIbAi7u3hLdEBrBtigVYxSUBCa7gDC4B+BdJG/DWE9DafF3hR4DbR2DXeT3Zga3Xrb0A t33hFI4KKPDXEz7hoo3iHz7Xc53ary3XCODbCnAOGUDZb70ACvDbOs7iC4AAra0AfN3jJuDjPU4A c+3bJtDaCDDkCDABCsDaBJABkVC2DNRAseCG2kenyn2hCHxrC5w/YQ0Sq+dgjVXTrtSwFoxQvyVG d8aRAvCrAgHUAOAJQz0CWHAOkZAPpkAAkYDn5xDCAsDnFZCKCFHCtisR+f+9hBQxkyeplA+Rk/Mt 1ZghcWApT1peqGFAQowESfQFQkQUQh50YaIeC6cgBENw4hO+CZugBk6O1Ei9CSbQAUue5Bbg6hZg AQ2wDyxuAg2A6xFw678eAfuAAATw2/sQAchuARHQAAugBSawCUs+AQ3AAQdwAOZQ7eag6yewABZw 7d5u7RZwACYQ1yYQ7uYQAdZ+AL/eAZvACZuA1OZw7bqOAMge7xYwAeeA4+fA12jQ72jASG/4YB1m 03NapyLbbCcxTZNaWWDkcoqO3YsMiNtdXgFwZzbrAFYUwuX9D7+xAb3KugKwBVbNgU+drIl+6DV0 8st38gyR6PFd1QiheTL/z4E0/9V9QQKJKbJPtrIKtFiPShDjBAAogNdwvQ/nzgUW8NtcYO+6fgTn sA8NkOy1juz7gNecYAJcoO4NgPRIbQGbwOL0bg69TvUEMO6bve/nvg9coA9d3+SPYALZ7uod4Opc 0NqPEO6vvg/vvglckOT4HvX7YOQI0O2/3vdGPteszdfMiXvpoHk431SlFD8gp2iaS2sOFuYfMZgs 5g9hZ+Z6yXiThUak5uZwDgByvgFDzaUgf6s9GukNwfIVAfMRAfsGQfuNQY6YW45hALFyNT9/BGIR sU0GkA5B3trv/uzlPuwLYAJ6PwGcgACvTuwLYOQEwOpN/u7Dfg5PLvgs/44KzG8CBFDsalD2ST7X JqAA+6AGJgD+S374E0AAHWACvq3j8z/90A/rMR7j6//966/jJhABAGEuwr59JhCYMEFAwQICCzhN GKIByYhRACwC+FKEBAAisUYY6DTAn8gBIkf6Q0kSZZiTLVUOKHLx3kWaNW3etGkAZ4oBAXrGrDlz hL8APkXQHFHUZxYSIpyKGGFRgwABphhYPEc1jcUN/ahuSENV7FiyVGXhBEDhxcWrFw2kawsgrkWd aC1eNVA3b925dnHOlGu3L87BftsC9ptY8WLGjR0/Rjsii0qXKS2jPFnki8UiAcLUpckzgWMiSQAg WTAh9cEM5wi8bjAwtf+JTZsObipIe98mE/kWLECA4Pfvc7QRItydHDfuCbkR7GO4bwvBfVwIcuFi ATuXBvsseLdgovgmAh2+W4hgoYF2C9/3NfR+wH1wBBYOvH/dcMKESLDUlRNCgw1oKkICACSYCSR/ UkCJwZcwGymAyygjSQjILrxoBBd6IooImWiSwAUJBzjqIgmU8gcom14Q65xIIuGCKi7SiKQCsUbY gAId0zhARx8pmNFHJNyqSS2cNoAANJuwWEuCDZ6EsiYsKNDJAAoGtImBBA34wpMRsMCisMICM0yw u9giDEM112SzTb8MSEHCCec8ySR/SNAIgAROCWCMDC8QAabHCgQAhf3/9tunHwuEI+A49GwzT772 2ksvAhMm4OScfQ4w54D0qNsngggkzW69fczhArhDEZjAvkojWK+7Bkqt9DwtDrj0nAU6/dQCLbjj wiDcOv2ON00tIFa8hho6IQ1TSCFFhTB6Gs0iIjaiyYABR0gAJDlNmtYyk+wcF6W13MQJLpoCTSmL muIayid/SrQoKZ8CUFHKsvYV61yLhhBAA5qmGkIxI+nyBMoRKPDkiydxpMnIKTXQgII0RojLAAjO TQeCwqb8UUeKaRrzprkKuycuxNBSEl2XX4Z5MRJKotAyliobaQAXihhNQxfy+kLDkgKIqjEJYjIA lQmUXmBW76BbwLVG/7NDoDiE8ltW1VPtO6DrTrszyLWqhRN7AQWgU20fTgpCgIDgXjPI7YPalrtR EzpACLfcjqPbBPu0K6g4BPQmqIPXGFJgghNkgQTaJR4X9CJC0UqgZsoqK3ckFwyMGafJIsT2phBH zNdeovKliUV+9/V3AzEEEONc12H3N0uLDgbgBR8hgGAIHSGgIKKBa8/xhbl0f4FiDSJSHssDX5AA iSHWYoBzuwDTMrGSyQzKppU7Bz/8Nokgl055Me9kMwDgPCWBPWNZChTUFSPhAgCw2O+EExCKevDn fmubCZ7GKgEepzbG6lTXuOa1rpkgA6uZgABxY7a88Y863YHO2QjyHf/rOC0C2QFhB0O4D8OFClXf Gdup9iGcg9jtHArQldJs0bho0WxeJEjAF64FgAtcoGUSAEXmypc5nEXue2yay0wuYJKiFO0m8RIJ vQBgr5LMjy6yWF1ZsGSAfYgFC1zxigDO4hfcrS9lAOiY9eKSPB0ZL3caaBkAfLeBF7xgCL2r4wta hgUBASBHAgtKW7ZnkTN2b3t8MRmaxLdIRiYmQZ8TorjMV631dYsIIiJCCo5CAi8MajOPUNx+8Ga2 Fe6DA5aawDnO8Zzu/IYA7ZFPdRAiH/k4QIF/45SlUnMqDnDBHAxhyGsmQACBoMcC5FnAqSqlBfc0 QFYEkRV6wGZAwJn/YAFqMGV6DoI3AXLhcDDcjynE4LglsIRmATjFCB5ggCCeoggiIIEQirChItaJ TkLcyCDbVISe+MSKJhLRSPJ1IjnNDzF1ZNILsCiACryASQ+ti42osg+ahIUqBCBkRiNWOz8yCQkQ ABOT4kLHNm5AAxB4mCfqggXh+bFicLwJBUCKhDa+K001ieMRSZaYODbSpz81GT/t2ZIwjGhOIvkM TmNBAicyoAg6tcsIjmIATJ3gIaKKgDksQICBNEA+E6jFKhmyn6oRQFfDMYECJaWdDmyQa1vdxCqD swCEcBM4K2zbXIGTEF3llW4tpE9C9hosu1XtNyYQFXVe2bXsWMA1/4jjxAIg8SxSQG5cPTmFO+lJ s5JI0iVZgORK6jmALKjvZYWcoguIIhKeJeACCSDCaAADxXkhpSg9AcUIRjAG9/kJJ5GgSsGyBFyx AJIrr6NKJNKhyIuUMS0QoBjzltcyDazlBb07qfQ2o7EpSYWPYBLdBmjqBQaYFKqJREtckkgT1ALV ve+N6uVcYlScEQVfNZEAJS1ygdAxxgse8oTijpBKDlDHILjSzf/M1pzYhKcWAoROGnDZtfsc527Z 4RR0xHo44MAtbxfMDjShCavzpAc9XAggpzzlWOFswlL7wOBuzpGe7sjmNTDMlCkatwQVLGGoJIkk SlzwucqkICPlCv+yQBdJvpMopScl+RlASWfbESnltinQyRGzIoCt2MSiVKmATSgwFln0NC0cra5c KICXJHEvzX5EAgOodCW65Gh9V0IplfA7JZDScXlDcN5j9DnI74Eme/BFdMwMcAok3/Oo/jhFf3FS BCcu5h6aAcAjjjBgVGxiUQg5Vl0HJ5C4IqBTBEmPABuQOFy2JzttJeF0KNypTVjVqpw4QSqJk5oB 05U2ouoOM6lDOLaZkD0FIYCnG2idTaiBNggYCHUQoIDX6AoFBIAEDcvZ2XpizgUJ4MmcKC2CcPmk sw8qiX7b1Jc4ieu2I0kBYmgrRSqu9skB6ARaiNvlmgBMRj2VqAD/9rGyuDg3zRqrEgWWOzCKGUBA JrUSvJRwD7XImQFTmssfseCFITDJpF8kk14+RBcMnexMiUZ5I5mMOUffjCQBMI1djvaYmd/DUIfS znEUMBC7gueUVbMwFwbCwrTahwueQjUHjdnqczziE58owSOsqrRDUX0CR8g1XQvCmwoGx9jWeQ+r XKUeaBeObVzAJm7oZjaHmGCyjhuAOelU3wHE4gshmdAAjJwApxQBFKB1gdzHheXwhbufVZZQlC0y OiWbKEJNVgrh2YsVrdzEADHiAkdlslCBFcbga7GSARjQMdBIgKVq4SMABCRn0HhCRxHBAgSQsDw6 p070a5aA5tPb/z2cntzMLEt58GH2BdUSsWb2LJcUcUIEDznGCxsJ8AQyMIH6XK04GAT1QAS41RWu Ujx+i8D/ji4p+TwHmn9rLODU8IgglCDqjUABCk4Qf/gbChVH4ATVzY9sAWYVcLZ5jvCQD7Crj8E5 DoKQoO4zKwJYGmwzBRWoLG6LpEYjidiSwJQIAB+CnxL5gg6UKgppvs4hgpzhLM5ylwwxNxLJlk5I wRLMN5yQKH6rCRjRvYvYAFngAqiSM08oEtAbAgYwgOsCjSnZAAOYkiAUGDvLELWgo4+qrugBDYej EtZDEpjaPdvhnuuZi98juZMTvi90jJl5tDEUF0nDiQcINJmJCv8kmD6yMqtUsptacCUTKDC2MbUC W5a7CQ++UiDs+I5kyyuhyzkBeo19mAAkKIH6i79FpL9HeAQUeAjVoL7i2BStQsCD8A7tu4/usA1l sRoENAFsKitqW4AjkIVxipYliLsgMz7M+BkSILJxOQVIIgHrsQghyII6OYWFc5OrkDcSYD5pYD4i EEbmi8JhZCqcCkZkZD77uYuVYSmQOpI0vIl74Ki5cC4s2IDRg4B0QJIwcQu8gJ7YIykKoAlPgACa aDOboKm8wII0WC45GxIAmInDaAwuVIy24EUw5EfHCJFuK6qWkKQqMoDz4op/sgsDwLRDmb7hSKaD UCUBCkC+eZr/U4KOZEPAfTiHv9kNFBKPhQjA91CaBxqOR8CCEpi/+EtJRoS/RjiB4aA+S8QrASKW 5Ggm3nAPCzCc7+iADtiCCFilx5Kht3ucojo+VjwJUDAAJkOyd9MZddOQJiMCfepH8GkvxcACNQIR CDCQQ8KCzWASJVHCO6PG9bGIdKiuQRoMdbmeLsxCJWHLv6jKuUSLETQJfpgQ+kK3O+GIsqSJ0qC5 o9gA6dsPukKPCNACTTEBgYiABbCO4ziH7FA1baKru3qPT+G/t0klCZoASOQETkABpTkCFPgELAhN VPjMlFxJ0Mw/1fiNUfIbSYGm5+iq3DiAUxKVBVig9OiwqAEl/y6goQg8SkdLiQFIp1jEDDsZCQvJ liLwB1CAN3xkDINsy2qEjEPSKHp0DKjSKapsSyXBx5IRT7QguMXYHkGiy/TMFkbLGX/Au3oySpSg tPURAuoUgkpbjATYCCyohUPZhFhqAIM4tX1QgwWIAN5oFK7am/hAgBLghA7YBLBLLMNKjel7G2vL NU4oAahDgSN4hBJAxPxDhRNABVSAxPnTH1xjGgaEtlgqCGlrD705lmEzUBgrlob4DVR4hAXQMXK6 wG5rtJFIgBFgzx87CdOiiQ0Yg5NQt5LzQvXsPe1hLsegSu9kjMLYx50ikyy9CC6VSyuF0i+snJOI tA3IRcsZgP+/SwEicJ688ItLk06bSAL7ubnp8w7dWIAIzQ23IawOKI4IwBu76YAFAKWHeKb2WKEF QIFHlDqDSA1UaATQLIEgSIcgeERInAD2QwKp+8wRxbWqGrDWBDr3WA61kybvOJtjCo6FSA0NBaVh YsBM5VFU7LG4qwyXG0OSOIovQM46SdPfO4WRiAXqTDlfTEgtvcKbitObErTrfNJjPRNizULfuwsv DdNrtYkg8ocwIAH1EaoJ6YRaTIEmTYwRYE7HEAEJSIdDUQ1Y2Y1LOabva47uS4g7lRoT0NDPtIcS 8I7YUDXhQIEg2AAHbRSHAM0PLQG4SAeocz8UQIIgKM2ok7///MO1UM21UAKg3XC25IC2YmGVTC0B LAiCIMAC+CuBAVmuT4gsh5AsGpqW+GyJ8yEizDmKMUUypvCLQBEJv8TWnvXZnwVaDJEAeKu0mXkQ ogEAUFC8DLHFm/gvyCiCIDyUu4KbqtlDt6nRvKnRADqHDV1UR3wEVKgVCLuUT4BY10yN+dvQdGDb 0RvZJnAEtsUCR3hYROzQFNWfq8s1pVmIwsEbNdBMk4RYknXESKQ2g8CUSX1VhhCDHZOWc/MskfCM yE1OPwkBCkmnxODVnjDDoPXczwXdzyUBFyCBliE+CCGJ0SCCB8ApFwhBnLjPx9iAo4gsSeSN3+AN e5UrcwBF/8Tiuqb7hEZ4BHuIP0esD6zCDWExARR4odTYDxRIWLgYvYU120/YAIUtTUcMUU6w2AHL tVxTCNtgQE7QXjB5hCGgxErsh2LKjk8Rj99IJVLQNludQMpFvufMC9U6ifTJz6JIgdAF4AAWYCh9 APy0CJt1iZjQz5og0qa1iclpDHOlqsJ8SOA4gFdCNrMyv7tBiKtVyeL92qiLTYHAm03JGladgEaw 3uWCC0p1YYWtVEvdD6zLOvhNDYe8upDFAk0LDjVAD3PgAAZiDwpzV0FkptylrG1LsuFUzpI4hQvg J52RPJnpiQG24ivG4veaXZz4AjFEMnjyrYsgAuXLCTJWjP8LIAJPqFDqkw3vmDFlaTGuC5bHxNcB W0ThRQF7eEROiM0M85tzcE1W1dG2VdgNoFRPqFS42ICn07Q2lERSXIjnxYJPQMTmYI+s4pS/cQ/o CJW/iQCzEqADCBYIs4XKUsXRSs7L8KycAQURYNPSdYyQkNYspuVatmXFSIBYuIAkKI3S2GXm8yz/ Bcb/IgIvmCdOKmZOej4v8IIkIAE0KOZrYWZp/i9lpmYieCcKwLoFOIFM7BSDsBT6WIA+dCze7YDC BE0UEF7hBVsHPRbG6gC6QeEjaIIgGL17ZltKvV57juGHcMjhyIeFeAQkKM1MiQ8GorAD6ICj60mJ 9A5gsQD/xFmlVEMIfeAxVQyXmRUiufuxAOAkEUiB+rnmZU7m/2rmjhgAcr3llWbplr4IERCCYr4A ky5mZuan0NKZWIjmaOYvEuDlYQRqbC4C5iPmnTbqovYCUBCCUNqPCKjDiKboej2PPbyP1DiHlfxQ R9xX9ysB5jWB7NCqhBCsG/6EtsVnT3BhQx69JniE4KDgSOYERByCPEUWczAHW2qPDlArXPk/guhY CNuEqHFIodNIEzDljN5WowoymY3cezFONCbqYURqmZ6ZznXpy8bsK36qqPIH9znTAMiCc3VLu+gh yBCCFyDRwhxEeOUr+NgbArjTCUic/FvURrDtqOPqht2l/1G5j4aIZBOoZ0RGIwYYWW8c2fbj0KiR 7Ud9xAjypbtmrA0iCAx+Gt1EQGcru9ooCMRhiLbmOQKAlloVPJvJVVWuk9t6XcWQn8xm7/YW4C9g XZlTSj0xCjSmiS9IAH3CIcgQAQpoyAjaG27iJuQIIMNJDxxNUXVe1NxmcFDaHwwrCN9InICVC4UV 2Er9hEdohFuIP9fcj+b+6u+INmtyXsR61wGHteToyXc1sOb9jUyxjx41ZVUsHyNNZZZzCVAQtKh1 7x73cZ81V7+Ip8XjGY4IQQbwofX5Ai8w4Fts8sQogsJUjQR9jaN7UQLwpYLoSUuRDVbBNeh1RAYX 8w6nxP9RsSZAPoKnS+RPaIINDd5auL8jkEOYbJTpRgjhsLVDIYADiDEuwJtRCY9Q8ZRgQcDwgKGA ThwehYTGdRwVoN8ftRwcR7L/fQwRUOkfx/RMTzn+8osi6IQsq4vYJZJ7EII4EW0CWdZsQYM2BCAL E+W7aSv5sBvqOFDV8NQ81nCubgT3c4TcznAUsGo9RTZFLWtPcIQFJ17ChN+l0SDhoDbhUJxPZerF hCY9/c94fZrvgDBZeqwFUwBbaFxUJIUwEAIvkAYROFNVlq/LiaT5DsNL1/R4l3dGWkpnRIuZsTua EHUDEIG6kIARSIEn53HH+II0YFdfM5y6+jCrEesAFI7/tC3eMN91MW9w+UslveHMXX/EqANNCv5M uQImt4n2i8U/kt+UQC+gAkpxCH3R3FUItrNq4DQFWIiEcoAuXjSABAiXoSIKju75o4Jpnr33Tpr3 ojf6RTLXJ+eI3fKJKeZxBhACvXMiB6aLIgDTxRuCEUUU+TDzooslBSA/x9K+HP1yijd73NbwyLrQ wSEI2/iN/gwraHdNVGCI4DiBR7Sqq7s/ptbNVNvr/hPxFzOxA18A3zD4YbIFW4iENIiIFxgBCRA9 yUHloxWip4KKx+D0o9f8zUeXpEeLC9gZPgkAStpsfiJd6XSqWU7SEz2BDEisfdCHyHSPUY42vy4w R83Q/9tG+wZPRDF/RLpy+6/NgNeoGtXYBB11P1DyG3MIbE692AzN+1SqFL3W5K/2FK2yFFjqmsY0 GwVInFSyhRkBHm1U17lICpZrReQTgZnYb8cIcs6H//h/jAQQAiR9YNLqDM7h9xcQqiyg+pwAiCIA BhIsaLAglhMnJnBCcGCfiYgEHkY0cW7fJhMING6ysG8fAgITTnBq9KhEoxIoVTZRWcKeS5X2Tqrk dK4BSE6PUCzYiODchCMoeJqIYE6MuQMHPCIYeWQC1BNHnmbYZ86Cx6X7uFggYGEpl30NimLFymVB vnMEFkyoZcJWhTQUNIzYIIFBQQMiBvjzx7cv4L98Bf8HFkGQxIWDig2OEbL4MeTIkidTrmz5MubM mjdz7uz5M2jQY0RIgDyCX4AUp0gM1Ftk8ABQBiQYgGygSO3LJU6ggrrPQkUCDk10iLiAw75zPc+F 3QRSJEmTKhulPAmzBE2X2V0uMGHBXASPXw+Y46A0qTkHSpWOT2phE1uo8icgAB8hbNgOW00ciIDz IwH3ffTRAgosQIACE5zTQQW2yPWCJwbgVdAIAQzWF2wY+qXhhgOksAFBSSSA2QiGhUaQAAYJsGJB Ka744mIvwlhZii3KeCOMOKooI4qe1djjZD8ONKONPNKoIpInWqZjZkIqeWICRXwRGQl+nTLCQPcU EQv/hlmMQEIAsYwIgIQAgDjQFyZatkFQUC2AkQkExGkBFxJFdAACPSGAgEdqdCDcSJygQJNJ0sVU QhPXIepSI91FsNR5SqlH3gEOcIFUpUupNx57+yQIVQZ8LuXfbx9tUqdWpvJZEUQEuKocKgTIcoUt FFDwAm0HSXAKYRv6yqFgndxTkBeJXTaCY0qyCCQAP7oomZNLPiYktZBV26yP10a27JDMdquZk+E+ eWSLTY775GhTUumXQAPFEoBfAVxgwClZjEmmASS4wBoAUWK2ASdubrTAAmqd41GcFnn3WwQgRRAR RgQL9Qh12EmXnSMlILEoFtc9IidXXGU6qVJnsFfp/3jqqfzVeMhp1MF6SuEUwX1Y7bMUTmOZwIWc ciaH4Fo2EQAXBBq8sEFuBn2Rha+9Xti0C1gWhBhmEqgJ2rOK1bg1tDFy2+yyRJY79rcxju1s2EaK 3a2zKH7NNtniav31jGLL3faQYfeIN9htv41t3NzanfW5oUWpLmRfuDBAJ62lMADkWQBwgYcHRemC AUS4sG/Skz0CVW8Qf2TCAg+rRTrNNAP3mwkYeGfgSEM1gsLs1D2ynUzalZBBRw1/BKmmnJ68KaQW TMqyVvwtNd5vSSkV1qjhZfRQBzSDFOda9FUgCyxDYDGCBMMqlsDTYcDbaxgdXj0QCfdWhuy40X7L 9f+2WgOJt/yAe5t/2YDTr7//vIUt/Amwf3zrH7P+9z8EKrBshHugA/PGwCT57X4SLFxokCU1KgUg AFIDBShS0AkXAEACLkhBESZEkCK4IAuQ6+C+zhQZA6BgIQvZCng4kBEuhCQi5ziACdTwEQREYAus 4gLohkI72t1uJibZzu1MgoLiiId0yFOZpFJmPJSBZUAY6cCekBce4HDhZB+xDwcioB/wfMUcGNlH cQhwAgQ0CBYQQMIL0sEAFRqkE4I5H7Ca5j72jYFEyVKW/ea3tiItcoEIfCS1brQjIkVLWwKkXwMP cq23Melsmpyk2grItUx6koGSjGApAYjBznypkJL/YQCYkiWCKRkAS/cQQQK8ID6CzIYI+opXAE4x SMV44ilBOQcHPPKRCeBkIwQ4x3BcZxEOVCQi72GLEgdFsds1cZtRLNSbBpQRkBWvnMiDY5yUEx+2 PMUhy+MK68CClZ1hJTxAvBnLgEOcjACFANuDBQWwMIa7PIYET/tL+g7aF34VRAQbrEwCGHoi+RGw fnMTnOA+qdFHki1wGXUbJ/eGyiS5TZX5M1LfLknBBNYtgA5s6QQNeD+YqnKVm5GAiCpDAsQkQAgX 4OMXOje+80EuapFBwhEWggoiXs8EE9DnOUjHn+JwpE4mkEVEqmcCVHBVULbb5hMptsShcMIEmzjr /4AU1gEuOGA8LAMQUKByhIAtRCiceJN7GiYeNcqMCw+zwBh/wyc6AZZnahHOOcraoEhQwAsbSAdk iNA0Df2labE5CGkw48v4bdSl1kpkTR1ZUwDyb7SZ1JbcBjjSjrKWoqKMqQXnZ8HTxtakcROpbDlq U8xkjgiWuUAKRACKAZzCt5WRgIX8UYQUeBAy90DBfCwwFjlB8wCuishTW/VMOilMItDcR1JRMZRb PGImFuPm7MQ6AVb9xyKu2kpYRvfM+QQFFZwQ1O1QsBGuANYjWrCAFn5XFuCAxTn78IoXN2EwtWRg Av68AmOPVqbFUG6yHZrsALLQudsIdTJUe1Jq9f9XWo5ujbas3d9nNVpimYKNpC0WMWhhfGL/mVil Ml7xSDFJShbDGMcH3O1mepoZImQhFi4Y0xe8MJAoybChLvDgPVLAjwR0eCAbgC5vFsBd40CkYBaZ wAH+hFiKSARk5gAPW8SrTeyopLzYieIjDkQcE4ilVT7ZiHLoO4EGM4QT5kVBBr6jRgJsQbq+e8/N aoYqiLyxKKPjpwJ+0hQHNygNRrMLZLxg4coGBjABcJ9eMiOEYX4mkjl6LSMxKmJVu6iTpl6bayXY 6rplzZFoO+kkNXnKFt+6pDbuG9pknDdWr9a2wy7prUUL5OOujzJfwldrStMvYx3ElwkoTb5SoGT/ xWAhAzaEJsEKRjDnPHMjD/NhRyByjqieh07hYcsJmPjEQ523FuuuZqvWHZ+kTkUq/haUSj5xAt71 4wBcSYpGftMALdTpNx5p2M4StjAL+EQiIQnJQvxpiyEYjaAFdVqHDsqXhwoZM1JaNspdnPKurbzl M3a5ymH+GC1VOTISaJdkviBtADy7IPfYwC4LUoIayqcW8imQczzSAATsxzgNiMC6YdYPOsHx4jcj HcUO1ZKXtPkIBHMV2Ak2kpGQRImCGspJHPGIsibluwMqI0QcDRzABnZhCOBCB4DzMComRyPZW0AF GsRxCUNmLxbedF9O0bngZgY3MgfyiGUe+ceD/5jy07J8ZDJ7GQYUIeiLIYEQTlGE0ty8X5K5MgpQ kdQBbSTSSflIAxbgxqx2BwGbMArVSdcdLrhHKVinN6Jo4qYJiH0C9kXBfdF+u4B/ImOc8EpSRHY9 U+njUYy2QPWU+UbyfAXiz/vKPg50DgUAZQEYgEWt6NJkxRgew4H0yyEBYFBQiBrz9r8//vOv/916 wbiXEcJDGYQBjMhrQE5xAcADSEAsBOBBeAJZoYKW1ZM5MB3ebUJInIM54J1GrBd7FMdPrNejuFFx /AZ5RAB8nADXcV156RlDKJF5lYAjNN8nfII9lBXvgQVV/QYXqIHt7cMW5J3vmdVDGBidGRxhFf9h f3XZ14nEgdgCQCHBKOgRH+VFJ7zfrwiGUZVQEVhI/FFGvuwfGIahGI4hGfZLF1LGBfgfZslL+w0A a5CA5qSAKy3GIygESRRFRYDRuXHZAajBM5mAA1xFvp3D7QViWAQHxHxHwdVJ0Jxdbxhf2eFOm92V EJ3HIV6XnEDMUkAMTgBWBuqHR2zC0pWKgV3E6ujHWgANWwBeBQAUFiANZBgUyIFcGGxQATYOZiQA A5YhL/aiL/4iaBgAKJCAF+xUMRKjMSYjMnqBCMQCMj5jMfIK5ASGEBDBlnRQChBjEigjMa4dVHCC fF2XPsnJAvDMgfgMHGUP09mMRqiT2BVMJpL/oFLUTKNpRIEQTC2co3c8ihFqoKStG0BGlVnBnehI X5yogXMcjDI5hwKE4hu5ioEEzdCQgi2UQylAgBBw4zGSwGu4H2XFSxH4Uv+5gD8Ek0gq4zGmpDEm QQpV3suF1mhBC0rhWszp1q4lkrJRxq51Uq6hGmaEC91glKkVCTAWjghU4wUkpVIu5VISQVISQQo4 5VImwHBV1oVADnMNQAeJQFMqJRbUYVKVTjWZopwUB/ENkXd9nXM4RzXtSc9cV1ZJRAfoB52ZiheN Tqk0QHxVE2KtBcEYCPkRjHLsiT32REYQh3bBB82IIkbwCaOdlToZCFtMZCSgAQQQ41MqpVSm/+GF AUYYWKU/tE8CJGVPbUixpGFmoqZqSqVTxgJnvWSMXYYlxWaKddbk+UgqQVICYQ1qRVBFedZtFuVl RFRmkAADtiGHXJiFSBRCIN9IEOJaXMRTMeK4nYxxLMAmcB+lBGKlpIfzOE/BqYdF9AN6nIdECNGe LEDMzN5cEkAHqAd6hCClJAU/dl9/dBdbhkeeAFYHIKQeQgQGqEGc3GN8nIMsbBwerZ9iDFenEQZf pIDSiIBfSA5mpMlrshTfsMgDZdTfiEuJfahqBVtK2SZIxdYoBRtN5tavydZHtVqJIklv9lhtVZJw PsltZEZjUEgSkOQsNqhyMSDtSAV9iJvtYf+gU3VH8tClez4PROjHXFLVWz7pgHQFncHMV/AXAfxM RdSHR8DTYZZj9BEWF+DHgPzHlBqFVR3Mesyec8zl9JSZRYSb8U1AHQ1ersTiVQaSG+bF40AOc1IG HF6oimKSrKGS3rSWauXWoRJqjJmYjsHNi5GosRXQBT1qoprWbcnooHZWjYLGqDVebdzG4iDeR2LI ALhmQTgg8nHCUhGf7ZHOWgDhgf1dVMUd+fXlBUanO9aeWrxjROSJWf3QmobfnyxAProK8SFWuC1r uF3gTywHYe6HAuTdR5QRxLHlwjRpBygAt2KTgxFNgtYcQYxAj05o5yjOX5DaDDkeiPGkouL/ViqF WIiqWG3Z5ClVFKNe6knN5E3apImuKIptaoZyUnB26vs0m4f5lhAolEdeGF+0D0EgQbwNRXfUpQnc 1T6kUUXER1HQJ/A8Sp5MQKL1R+rQzFWUbHiMaciABNVtBSHGl11mRNxlxGGiVWOeg729Klu+Uat0 xxf114DyB1fwR/gtQBp84wTIAimkwRAgwRjoUWQQAcN2CHMyAHO5AChM4WSUnEtiaL5u6KFOKqRS kqHWJGkN26IKLKViKomZzbsq0t+crdpuqtka7GY8wC7a3Oi9X684rKdp5YjcQx0qkWOm5+0hzJch KXiEhfZJV/g12D6ExxjppV6GzIDp1XgE/2uo9MQR3AwbjVF/xUykmKcJZIC4bQp6cIob/YRZYYRf WcCB1JPv3WM++oaDUAAS2IXWGoTU6qlfdEKHIYsI/Olk4O253M2/ju2MqhzhvK1n+Wu9vm0FQa+L 0Wi8zi3bli2kAien2m1nXMAZToYIaBrI+S1gOGwwGQCbkARJKNhCpBv2cGzKQoSkEQzrHhh2WkQ4 6purVCwGbERWEUjcvdEEZKCAImJbqpV+DAhQuIVV5Mdd0snrGYgfWlPDoGMDIMiyBowpwMKD1IVk LGyndZq6AoDmWcYI4FzXKurXulTYhtgoJa8LUy/3zrCmxm32Zm+Gzm3cxuj01vCPeW9nFP9B3ppG ERQB4nGa+QoGCSRE7NxVBhAATpAOUEBgT8jJnrhjKq7FrxKmc9xZpBlInqSiuAnHRhyBgJCggy0r 8blJXMWHm2RABkQVnm3ssj4rNNGZR4hEVPmMfvbEPmDAXxoIBEJCBQwBBGBBhOxuQQxXAKSPw6ZA zSUAwkoGLhVOamnoS2lyoQob2uIPsb0UsoHSUErvTD1vDpsW3cjwisXaix4bLMfyiAoxaFwA8UrG lkztEutpJwwd+9LHEIVsb3TEFjTFzhgFeZzZebTdU60Hp3wHefBhfzgPe6hnuBFH6cDsfcyvmCpd mX4EUDDdXWKEgeVJnpxKRlQscYCfcGj/cGB+ayQMwa3c6WMoTmcORhYgzkEQMYmoMC2vUsHS5uXF 5D8X9LLx83AWgR81zSOTaq8EE0PM1QmUma92X1MIhUOwzJi+XfZsBXcJUbU+hINBoD2B7gWnZ+mo xZmpDld8cdOpLnpMIFRA85nVdCCaQz/Ax1q0kcG5SnE4R3jMalrkAwGkwT7IQjxrABZIQDqIK5m4 0AjzRQmncGY8QAkbdGgEdN2CVBBjtVevUgI8QGaIABGcgu+Wr4PCgnw8xYAuQG9kKcTFnf5eYrkB 8M78BFu+yv364VxGRHjMJeyZG0hsQj+I7EPQ70bcTNxlqcHxLDrpHj7hHZmyTPm9CaS8/57P6PFz PBOCJG0FJDWuODUA2PNVZlgJc97OVcYFVPJXt7Zrv/ZmcGUuOtRnckhD+8UAQLKD9kUkNNgR9AYn sO99iVdwD4V8JJ8S/bIxQUU+wvHREd/4vWPRtTE0EWZTFEwGLLc6S1x6Et8SXif2/IQZF0xTFGmb VuseV8QXQ1P/siLTXppoewGDQs6DFnG/sPZj3IaCwjZ/97d/K8bNiTb7jUZy4XYn4NIGkEAVFrhV hoF8qJ6gRPgJzA5Z1RD7ZhNZsa+GC6mQygef9YZ9lZ1CcEJSycdCtElU3FeHz1VET0VwnzgL6ll8 HF/qefey8i+O52r2+FMaJHJdMPJASP8AKGxAC+0UWa9ragPqLf83kze5a4Ne1RSBQeF2AAAv7/ID bnOIOqzinsnViJsdSZD4xGK4cPMbiaf4iy8En82HQujZmhcfv8F4G48dqz7FcrfFnINKGzNrg725 ZN5jKpLfrYo3wVTAOTCW0RiAUwfqCOgzlSz5Y6QwkPNmv65tVgcl/wDlvpayLFMSphOlLDu5qK/Q VX+eCLCQP2TB6CnGF5CAhBJGOXT5NyrRTuwErdu6WBXKoJidiuOXdlQ48tVQhAe7oIR5cOtErd/O iwfK2WWTrSvEXIUXb9DXmruJ2AEmUZ8jGafixe0JVHy2XLxikhuEpB8Lu1bGbcyhTY3/mFZLC93u SKZm6m820Lz7pqWPun8LuaNPBhHPxr4fxJT/BSzgxFnpnl82a+tVt9/53Z6QH2FqRHruiTmzd08s R8U3PDSJsTvWgunKqdid+Fzd13A/RcCE/LC/OH7ZeoWfxE4EDKvK+XPHTtJGQrhHobj6FGZYNWZk JMppevRuhg9/VozG+/ISdI0VG747+QX489aKtRe6EF9YyPKYihnbiVlFhIAuMJ0VPKvUGcTIrIGt g1g0gDeLRQQkExudLAekUTKNShoBFtlnrHj0l80o3IAcMNgXfEYA8BYPphbfIwJEGmGW32fL8wuM wIRZDtNLBjPm4uJjUNBPlLxHqqTC/6Ru3hjl062LenLSizrPX8ZOoTtHMlcpUEAarBvYEQAGYIA/ yUkFyMpRzxkGPKl7vj5x9HUFFMeTnvcW+OBdqix8bUW1whd+NMzKUp0yraxf/UfLjmmh/f6A9P44 GxFeigUX5Aw8qQXN3wosKsZt2LdijIBsHEss/DvkTz6lC6WvpSjnh/qN+Ziv0Vilyn/n47uWlLpi FAH+K80CMsAGvABAUBgSqULBgrIOVpBlypZBhwoRyoqo0BTEgxExympIgNQ+hR8nJoxoSmLJkh0k VkBZ0hQkMS4hmWJIQJZHiSs7MDQhC2VPnj972sopa0uFSGmGaHghwQAAp0+dkiABlf9qVacGiiSw uvVqVq5fwYYVAFVA2bJOx4ZV+zQtWrZu3ZolOzfuWQBt28JFOzYtXqp4+ertG3htYcOHESdWvJhx 469fYo04LAGUhMNJUpQq8kJgmjSRQJ8LHWmaLVK2QBslOFp0JNGibdl67Zr27NkVSNV2/droa9FX ZOk+dw6W6IK7I9l6CYm5KdfFi1cgfs5ow+MGCRp16Dp2heJHKWBZms7qiCJNDQuZelhEEseJ8+bV +/4u3fr38f+1Lx9//K1937IvQL8EpM/AAxFMUEHGEijCMsMuKAKxWAbgBwsNKIBgCKQ825BDW65A zUMONyynxBMjuSKNclb0jEUXW/T/LA0VY3xRRhlZhAWWG3nkMUdSSDEFSFiO6lFG73o8SsnPmEwR tA4hUGoEAxioCiutDCNCBMTUW1Cs/eZLkEACq/IvzP4CTBPAuAZsk80zvYxTzjnpPCzCLw4jQYjD NkghgQ1GuJACDActlAIKllAHAnUO1YDQRg+NlFBFMXzUUEkPVSeNRy2NNNJITPQUggwFGtXUR8IA cshIhzA1Q1OXQGrUVoc4tNZbBaKAyFtr1UC8Daisyov1ChujFPQKI0HCOsv8y677+KNPLraebZas aq8FbNq7qt12W27je/ZbZskt19w4iTjPgHXZbdfde7Aiwt1559UT0Bde8AILLPTV/0DfF0pZohQs 0CjlBV+VQpjfC5Hw1QsK1LnQYSQurFhhgiGwWAMk+pV4YyTQyNjRkUkuGVEVwlgCjZJZ1mBRj1s2 mdFKHcUigRE2YMrdBED5ggF6gd4gljHgBZredM9NWumlmW7a6ae5IuKUIkSommoRrs66aiGKOCWW qh+oWuyxxy4ihRSKiCWWUtBYu+1SYkEjBX7aRoNuNNKuO2+8YykCDTQ6udvvuuNOW+244+ZHbb4H P3ztvtVJAfG/KYe7YMqzGGAJzcOg3HPPSwlD8s9J91ydLEhHvAiqWa/aha/JLttqq8+eXWuscb8a b2Sh7t3334EPXngA0gX2i3WPN/8geXaPv2cDUIj4+fjpla9eZwOEToCBnCXoXgLucw7fAC8c5L77 8L9HX4J0vz9fghHSDx/+EUpJoP0NwEc/ZxFIyBnn+d+3gVHg7HtF2NwABtA/Ai4QUBIgH/7mt4Ex AIqC/9uAF9CAswkOsH3YcxdkEsC8dTFlee2iTPSMRi8SgIJ3w3PhC2EYQxkeJl0tBIt5JFOsWNjw K15ZiwGOZZUqVUUIWKoSA+7hlCReBQAkwBIAhghFJEKRiilAoD+0ckQqahEAQvDCFrXIADGO8Wde ESMAkhjFqkiFPV/M0nlmGEc5zpGOwauhYcZQhByu5QIiUOMNi/DHrySBWGFJwJ7/uBJFElxgLSMI wAD8kYKwbGBZa2FjYSLEnkKqRVmCrOMnQRlKURooQntUSwJi8SBPrhGRltzkVwywwx/CMSxOXAsR 0HAKf6AhLEUsjHl4uJURxAJPhRFBK9cihC2NkpnNdOYzv4LKJ54SFKYEyz1EQASnrJIqPlQLEV5Z lSGKwJpbIQHR1FKEMUjgeIBcYliwMobCSCAyhTEA/wyDlXCeyyzYIte3xlWggO4lXAXNFrW0ZZd+ 8qWf0HQo08yjTR2Wkyvx+mURiglPYvJxn1RZpFpGsEy1CIGRrrQnKOS5FmwiMyzm6ai5olWuMaXp WmDSD1xmitO3kOlM8onpQ4FK/yesIPKdXxnmNMECwsIQgaVfAecsgwmVc6rFCxJt6QMK0yB7FsGq 8CzCS6vSIKQyLVrT8stPC2MmaH2FMIKxVn50Gler+PStcArqXeekrA3Mk6t8HStXurSWVK5FBCn9 Cgm6yhUHEfavVoHMg8JyjyK4US2UTCxYlEXRpfFnpmg9jFoB5E+a8tStN+0sZwsEV8/ilbUJugAo SqqWL3x1my2tp1qwotmwLpObTrkAWJtoWK6MAKunLG5YGOBNsDAAn2vJY2wn+QAhRFVpDbVWWxmz UIRSy66gnas/xzQYwdD1pjRt7XnjJIFjUhcqzJ1uI2/b0sqsRbkVpSVXbInZy/9uRY8mJSxwnxKh xkJliQ3ar9PK6q0DeRdNAAWTWc0brrWGSa0RRu+F5XSPzPZWqhiFr26p4gURFJUreUzmgKNy4Kdg hb1OYSofKwkWfSbLw7jlGojJ+tbQGojBpB2tedEEZLmSF66qxfCR49QgErTYKdKEL4ql2sreCkHF UEmASM0pXKtceSvAWnGNv8KAEcwXns0NyxfWuxYluxC13HqTmNxU5Pn4mExEXlN96lxXOSOZz44x QGYbSVuQFgG6XJFslZ8yWyaD2SrnJDFVfEkVVPbsKYFNany/QkkAA8DATvkCiL9w4xcmGM87FVO3 REvhVHvLuuA6KEFTS+Q+z5r/Pg0SQkZhqUzIfkUChMZtfbfy4lpStioaRjGLoWIAUAQABns0j1oY 8IBCb2W2095KKTldBBcMgKshpEqESPBoWo+b3OXO02Sn1JSoki8BX2Dn+tQjL3YB4J7E5orQcOyU /oKl14et8rCgMswiIutKZQaweQZcPQDMNgXKPMUjH4nAAbgAjiFdrLkxnnGNc0W9LjhFFs6WAhHo zCkWd0EAXJDyzCEQ5adwAQw6QeUULDksYyBzNO/LFREMeKpbkSyeRuCFEZBgACx9ai8BjMoLIO/d 7yOBCFLgAlB4wYr+kDgkIekPrQ8gFglQlrU3Hnaxk3uYLL+iC9AGim1j3R/8/7C61iEOyQBE3Opo W+SUttIgXJsTuIfELzqpUiW/S23ucx/AE3vd4qdb6Qtj8DrWtI32lE8e5Ve/+tu1nnm2+0NZJODw 2EEfevQmoBNst3zWUf/2rFsd4qqXeABOgTdQKPeOsNy3oS++Rq3w0JdWxHoA/LFHEYAdKkiDoteL AIqoR/z1hd+26reeeembPvoTv7XosZ99PjOACFVfffQxj/nNi7/6/mB+LEIsAvbmkcO/3UoSlCnS 6iWA4qDIQvVB8RRhf0XEno4F8wfgkcyP+lIP+qCvANkuDEhg7+JI1sorzhoDoFJNtVCtwlxtu2AN AzMQXLRF+0Kv+w4Q/FJvBP9FMPMEEIFEoIT+DKOqpwXnTSrcZQQc7wKIwAswIwHGYARGIAFoUEtA YeKm5AKi7uROzx9cQAhG4HiGaUq+wN3crQXXJwBK4ZgebvMKUPNKsPzID/pGLpTE5afA8D1ySs66 Jc7ES03cagzv7M5KywPHrvuuiPzG7/sQ0AClzmpWZ3XOJg/5kA9TIJLOJguqEAALr/IiDuVcwB9O 4RTO7hQ64Wwe8RHFZnXuMA+tJpcWce3ojvrkcAuv0BOtTgHzLYa+UAMZygzFha1sCq2wiy7OKj/U 0LR0rMhWyw0xzgBIzwDpUAtJUA596R6AERiT4DzgJRiB0TzizvB+z/y2DuL/Wq8XFTEFgimJ2Oid uO/hDBD4xg8U67ATxW8ATmEBmykwCCO84moN1aLH3Ow/2DHIYNEMZTEV6yIVJ9AWNa5BwkAAdZEX p68EE6jR1M+x0oUR9TEE2U4bsxDrXGDAiOsqqmS2AvAEDZAfww8UO/GKUkAamKwBSw0dg2xNfMxZ WA0wuqtMDOrHhoy79iIlzXHP7HHjJIAEVs4gL5ImwRHvqKL2HKsIQnAfCTAE5y4FZu+rkoAIaFDk lOVs1O6KupEpbfIpfxIUoOyTyHHCrBIkCaoeUfIqL7Ak3VEdKay0SMsjXxL7DCBd9vEpL9IF8Ibm 9C/nqMIAEpETrbAnCdDw/+Lu9U6PBH+yJvuyL2dur4CqKj0yp9gwHVdRyPaMLMHSyD7SwtyxLLNP B3ewMivzZiwTM29mM3VwM8fgAryNigAAZ3iNMzszMy/zNFPzNB2vNRPgNWXwZhxPNTmzNlFzNW9T M3NzBMTtmbDyI3+TLNMKHucqMdvwMd+sME0tJSWzOZ2zz36zK09xyORxLSQwDF9tAynwJLuyO0cy O58zPMVzPMmzPM3zPNEzPdVzPdmzPd3zPeEzPuVzPumzPu3zPvHToRaqFlXRJXmMP9vRJCcQQPOz QA00AhWEQOEjAjlLwvTsQCE0Qh3Ds6azAs+RK86iAzUwAxUM1TryAXdqP/8Hg9RMcR1Fix4VVEJV VPQo9AzR8TCvSznDEjjPcSxXUkZtlCtN9DBBEkZX9EdtcT9nsaesMkDbLEdj8StdcSWRM0fRUEkF SjGBdEpZVEDbMKGKtDjHS6EgU7uQMzLbKkm9FDJ11DGflErRNPso9Elf0T+/VDiz9E1/LM/MBDvZ 9Exn1E3TdE/LbU3F8kbtakB69Dh11DB5KkzlqkwvlDkdE0759FExTkjLq86qMk65iyQ19CqrE1NR UlK1S6E2lTvzrD9GFVJNNT9TNLswNEBPtVVdVVoG6tS00qdS9VVt9VbZrNVwdVd5tVd99VeBNViF dViJtViN9ViRNVmVdVm8mbVZnfVZoTVapXVaqbVarfVasTVbtXVbubVbvfVbwTVcxXVcybVczfVc 0TVd1XVd2bVd3fVd4TVe5XVe6bVe7fVe8TVf9XVf+bVf/fVfATZgBXZgCbZgDfZgETZhFXZhGbZh HfZhITZiJXZiKbZiLfZiMTZjNXZjObZjPfZjQTZkRXZkSbZkTfZkUTZlVXZlWbZlXfZlYTZmZXZm abZmbfZmcTZndXZnebZnffZngTZohXZoibZojRavAgIAOw== --=_related 00094E9C4825749E_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 00:37:14 +0000 Reply-To: From: "Itaru Nishioka" To: "'Adrian Farrel'" , Subject: RE: Poll for RWA Info model as WG I-D Date: Thu, 7 Aug 2008 09:36:24 +0900 Organization: nec Message-Id: <09ECBCBC089143AE8B596DDA8919317C@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acj3GM4nPLSe0Jw1Ti6CKwthFX9ZOwBDJj7g Yes, good. Itaru > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, August 06, 2008 1:24 AM > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 00:17:12 +0000 Date: Thu, 07 Aug 2008 08:16:33 +0800 From: Dan Li Subject: Re: Poll for RWA Info model as WG I-D To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <035101c8f822$d920ef90$394d460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Yes. Dan ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, August 06, 2008 12:24 AM Subject: Poll for RWA Info model as WG I-D > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to > be pretty mature. > > Note that despite the file name, the content of this document is consistent > with its title: "Routing and Wavelength Assignment Information Model for > Wavelength Switched Optical Networks." That is, the scope is limited to the > information model for RWA. > > Can we have your opinion, please, on whether this document is ready to be > adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Aug 2008 00:00:30 +0000 Message-ID: <489A3B00.4050209@nict.go.jp> Date: Thu, 07 Aug 2008 09:00:00 +0900 From: Sugang XU User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, In favor of the draft to be a WG draft. Best Regards, Sugang Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 23:55:02 +0000 Message-ID: <489A3937.9020101@kddilabs.jp> Date: Thu, 07 Aug 2008 08:52:23 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Adrian, I support this being adopted as a WG document. Regards, tomo Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81= =97=E3=81=9F: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and=20 > seemed to be pretty mature. > > Note that despite the file name, the content of this document is=20 > consistent with its title: "Routing and Wavelength Assignment=20 > Information Model for Wavelength Switched Optical Networks." That is,=20 > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to=20 > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 17:38:18 +0000 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Wed, 6 Aug 2008 19:36:33 +0200 Subject: RE: Poll for RWA Info model as WG I-D Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GcqVkyJoFlZ6SIeU+2nEtLqguQA0Qirw Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF4378721B6274C46@acreoexc01.ad.acreo.se> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Yes. Regards, Jonas > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: den 5 augusti 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D > > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in > Dublin and seemed to be pretty mature. > > Note that despite the file name, the content of this document > is consistent with its title: "Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical > Networks." That is, the scope is limited to the information > model for RWA. > > Can we have your opinion, please, on whether this document is > ready to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 15:14:10 +0000 Message-ID: <4899BED1.3090800@lab.ntt.co.jp> Date: Thu, 07 Aug 2008 00:10:09 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Yes Tomonori Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 14:46:52 +0000 From: Dirk Schroetter To: "Adrian Farrel" Subject: Re: Poll for RWA Info model as WG I-D Message-Id: <347BCAC2-A789-4329-814C-C34A54DCFD49@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 6 Aug 2008 16:45:36 +0200 Cc: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=701; t=1218033938; x=1218897938; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dschroet@cisco.com; z=From:=20Dirk=20Schroetter=20 |Subject:=20Re=3A=20Poll=20for=20RWA=20Info=20model=20as=20 WG=20I-D |Sender:=20; bh=TFtYPAqTcfNW7yWooQymkvssOFPwIm+G8FuZFC3ZDYA=; b=KVIgekcMKhCjImTY8k8vwYgYfDBrW/dg/0NMf2qXHNL9pRWdKCSWCM+XYF fngEv9lSLbeGo1uVqcidQPpLv7IXASB7DOMSDtiFgqdtUh1qtyL5ARfpgF+Q fwbEH+VmyS; Authentication-Results: ams-dkim-2; header.From=dschroet@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); I am in favor of this document being adopted as a working group I-D. Best Regards, /Dirk Am 05.08.2008 um 18:24 schrieb Adrian Farrel: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That > is, the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready > to be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 12:53:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Wed, 6 Aug 2008 14:51:10 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1403C39271@esealmw118.eemea.ericsson.se> Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQPt8l8Mwfb5R1moyhWZDGgskwAqgt/g From: "Howard Green" To: "Adrian Farrel" , yes > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 05 August 2008 18:24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D >=20 > Hi, >=20 > draft-bernstein-ccamp-wson-info-03.txt was discussed in=20 > Dublin and seemed to be pretty mature. >=20 > Note that despite the file name, the content of this document=20 > is consistent with its title: "Routing and Wavelength=20 > Assignment Information Model for Wavelength Switched Optical=20 > Networks." That is, the scope is limited to the information=20 > model for RWA. >=20 > Can we have your opinion, please, on whether this document is=20 > ready to be adopted as a working group I-D. >=20 > Thanks, > Adrian and Deborah >=20 >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 09:06:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-rhodes-rsvp-recovery-signaling-00 Date: Wed, 6 Aug 2008 10:04:59 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB106094C41@enfimail2.datcon.co.uk> Thread-Topic: draft-rhodes-rsvp-recovery-signaling-00 thread-index: Acj3o4DOGW3WZ0v5Q3eH38o4DzTYjw== From: "David McWalter" To: Cc: "Andrew Rhodes" , "Nic Neate" Dear all, We would welcome comments on this draft. Andrew Rhodes, Nic Neate, David McWalter. http://www.ietf.org/internet-drafts/draft-rhodes-rsvp-recovery-signaling -00.txt Title: Problems observed with RSVP recovery signaling Abstract: Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Aug 2008 06:48:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for RWA Info model as WG I-D Date: Wed, 6 Aug 2008 08:46:16 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF68401A0C3F5@esealmw110.eemea.ericsson.se> Thread-Topic: Poll for RWA Info model as WG I-D Thread-Index: Acj3GQRJe34KZVp2TAasG/Y59QRqeQAdw4pg From: "Diego Caviglia" To: "Adrian Farrel" , Hi all, Yes (from a contributor). BR Ciao Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: marted=EC 5 agosto 2008 18.24 > To: ccamp@ops.ietf.org > Subject: Poll for RWA Info model as WG I-D >=20 > Hi, >=20 > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and = seemed > to > be pretty mature. >=20 > Note that despite the file name, the content of this document is > consistent > with its title: "Routing and Wavelength Assignment Information Model = for > Wavelength Switched Optical Networks." That is, the scope is limited = to > the > information model for RWA. >=20 > Can we have your opinion, please, on whether this document is ready to = be > adopted as a working group I-D. >=20 > Thanks, > Adrian and Deborah >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 18:32:30 +0000 Date: Tue, 05 Aug 2008 13:31:13 -0500 From: Young Lee Subject: RE: Poll for RWA Info model as WG I-D To: ccamp@ops.ietf.org Message-id: <001201c8f729$713c34b0$4a0c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acj3GKDaCQlkF3tuQJ6CuHJEqe89awAELqog In favor of the draft to be WG draft. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 05, 2008 11:24 AM To: ccamp@ops.ietf.org Subject: Poll for RWA Info model as WG I-D Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to be pretty mature. Note that despite the file name, the content of this document is consistent with its title: "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks." That is, the scope is limited to the information model for RWA. Can we have your opinion, please, on whether this document is ready to be adopted as a working group I-D. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 16:47:03 +0000 Message-ID: <489883E0.7020503@grotto-networking.com> Date: Tue, 05 Aug 2008 09:46:24 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Poll for RWA Info model as WG I-D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes. (from one of the authors). Regards Greg B. Adrian Farrel wrote: > Hi, > > draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and > seemed to be pretty mature. > > Note that despite the file name, the content of this document is > consistent with its title: "Routing and Wavelength Assignment > Information Model for Wavelength Switched Optical Networks." That is, > the scope is limited to the information model for RWA. > > Can we have your opinion, please, on whether this document is ready to > be adopted as a working group I-D. > > Thanks, > Adrian and Deborah > > > > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 16:30:10 +0000 Message-ID: <014101c8f718$51e07740$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Poll for RWA Info model as WG I-D Date: Tue, 5 Aug 2008 17:24:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, draft-bernstein-ccamp-wson-info-03.txt was discussed in Dublin and seemed to be pretty mature. Note that despite the file name, the content of this document is consistent with its title: "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks." That is, the scope is limited to the information model for RWA. Can we have your opinion, please, on whether this document is ready to be adopted as a working group I-D. Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 09:33:30 +0000 Message-ID: <035b01c8f6d9$9b054890$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Maarten Vissers" , "'Diego Caviglia'" , "'Italo Busi'" , "'Francesco Fondelli'" , Cc: , Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Date: Tue, 5 Aug 2008 09:54:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit Maarten, I think you need to get off this OSI thing. Nothing the IETF does will require the use of IP in the DCN for an MPLS-TP stack. However, the IETF will only work on DCN protocols that are based on IP. It will remain possible to manage MPLS-TP functionality using a DCN based on OSI, SNA, PNNI, or bluetak. Since IP stacks are freely available and pretty small, and since it has already been established that IP forwarding is not necessarily required in the NEs, I don't know why this thread continues. A ----- Original Message ----- From: "Maarten Vissers" To: "'Diego Caviglia'" ; "'Italo Busi'" ; "'Francesco Fondelli'" ; Cc: ; Sent: Tuesday, August 05, 2008 9:23 AM Subject: Re: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Diego, The MPLS-TP functionality may be in equipment with e.g. SDH and OTN functions. If such equipment uses MS-DCC to connect to the DCN, then it is very likely that OSI is used. The MPLS-TP functions in this equipment should **not** require that this equipment has to be equipped with two more DCN connections supporting IP. I.e. it should be posible to manage MPLS-TP functionality in equipment also via an OSI type DCN connection. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Diego Caviglia Sent: 05 August 2008 09:38 To: Italo Busi; Francesco Fondelli; julien.meuric@orange-ftgroup.com Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] mpls-tp Dual stack DCN? (was MPLS over OTN) Hi all, So we are at the point where we agreed that Ip forwarding is not needed in the data plane nevertheless Ip is needed for sure for GMPLS protocols (if used). Now in this thread we mentioned several times the DCN, are there any requirement about the protocol to be used for the DCN? Do we think that the DCN should support both OSI and Ip? Given that we are in IETF I think the answer is that the DCN and configuration protocol must be Ip based, but may be could be useful state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is the right place. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Italo Busi > Sent: luned́ 4 agosto 2008 20.14 > To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN > > I think that Julien's proposed rephrase better describes the > requirement so I support it. > > It is worth noticing that in case of static configuration and OSI > based DCN, the MPLS-TP data (transport) plane is actually configured > without any IP functionality. > > However I think that DCN requirements should be described in > draft-gray-mpls-tp-nm-req-00.txt. > > For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I > think that it is more appropriate to rephrase the requirement as > proposed by Julien. > > Italo > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > > Sent: Monday, August 04, 2008 6:00 PM > > To: julien.meuric@orange-ftgroup.com > > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] MPLS over OTN > > > > On Mon, Aug 4, 2008 at 5:48 PM, > > wrote: > > > Hi Francesco. > > > > Hi Julien, > > > > > I guess I understand your concern. I believe the original > > intention was > > > to say implicitely "It MUST be possible to operate and configure > > > the MPLS-TP data (transport) plane without any IP functionality > > *in the data > > > plane*." My interpretation of these requirements is indeed that > > > they apply to the MPLS-TP data plane only, not the > > MPLS-TP-capable equipment, > > > nor the MPLS-TP control plane... > > > > > > Anyway you're right, this could be confusing and it deserves a > > > small rewording. > > > > Nice, thanks a lot. > > > > > Regards, > > > > > > Julien > > > > Ciao > > FF > > _______________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 09:17:51 +0000 Message-ID: <03a201c8f6db$df138bd0$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Maarten Vissers" , "'Howard Green'" , Cc: Subject: Nit in Maarten's definition of the DCN Date: Tue, 5 Aug 2008 10:15:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Maarten had... > A transport network element is connected to the DCN via two or more > interfaces. This needs to read "one or more". A Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Aug 2008 07:43:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over OTN) Date: Tue, 5 Aug 2008 09:38:04 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D92D9@esealmw110.eemea.ericsson.se> Thread-Topic: mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over OTN) Thread-Index: Acj2SyOUHLaTSfOxR92M5/JXYSVBKwAEb4AwABvnXaA= From: "Diego Caviglia" To: "Italo Busi" , "Francesco Fondelli" , Cc: , Hi all, So we are at the point where we agreed that Ip forwarding is not = needed in the data plane nevertheless Ip is needed for sure for GMPLS = protocols (if used). Now in this thread we mentioned several times the DCN, are there any = requirement about the protocol to be used for the DCN? Do we think that = the DCN should support both OSI and Ip? Given that we are in IETF I think the answer is that the DCN and = configuration protocol must be Ip based, but may be could be useful = state that somewhere; I agree that draft-gray-mpls-tp-nm-req-00.txt is = the right place. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Italo Busi > Sent: luned=EC 4 agosto 2008 20.14 > To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > I think that Julien's proposed rephrase better describes the = requirement > so I > support it. >=20 > It is worth noticing that in case of static configuration and OSI = based > DCN, the > MPLS-TP data (transport) plane is actually configured without any IP > functionality. >=20 > However I think that DCN requirements should be described in > draft-gray-mpls-tp-nm-req-00.txt. >=20 > For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I = think > that it > is more appropriate to rephrase the requirement as proposed by Julien. >=20 > Italo >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > > Sent: Monday, August 04, 2008 6:00 PM > > To: julien.meuric@orange-ftgroup.com > > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > > Subject: Re: [mpls-tp] MPLS over OTN > > > > On Mon, Aug 4, 2008 at 5:48 PM, > > wrote: > > > Hi Francesco. > > > > Hi Julien, > > > > > I guess I understand your concern. I believe the original > > intention was > > > to say implicitely "It MUST be possible to operate and configure = the > > > MPLS-TP data (transport) plane without any IP functionality > > *in the data > > > plane*." My interpretation of these requirements is indeed that = they > > > apply to the MPLS-TP data plane only, not the > > MPLS-TP-capable equipment, > > > nor the MPLS-TP control plane... > > > > > > Anyway you're right, this could be confusing and it deserves a = small > > > rewording. > > > > Nice, thanks a lot. > > > > > Regards, > > > > > > Julien > > > > Ciao > > FF > > _______________________________________________ > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 21:31:33 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080804213001.3F2503A6A35@core3.amsl.com> Date: Mon, 4 Aug 2008 14:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS Author(s) : T. Nadeau Filename : draft-ietf-ccamp-gmpls-ted-mib-04.txt Pages : 26 Date : 2008-8-4 This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ted-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-4141916.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 18:32:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 13:31:24 -0500 Message-ID: Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2SyOUHLaTSfOxR92M5/JXYSVBKwAEb4AwAACvwtA= From: "Lam, Hing-Kam \(Kam\)" To: "Italo Busi" , "Francesco Fondelli" , Cc: , Dear all, Julien's proposed rephrase is good. By the way, DCN requirements (more specifically Management Communication Network (MCN) requirements) are already described in draft-gray-mpls-tp-nm-req-00.txt. Of course comments for improvement are always welcome. Regards, Kam -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Italo Busi Sent: Monday, August 04, 2008 2:14 PM To: 'Francesco Fondelli'; julien.meuric@orange-ftgroup.com Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] MPLS over OTN I think that Julien's proposed rephrase better describes the requirement so I support it. It is worth noticing that in case of static configuration and OSI based DCN, the MPLS-TP data (transport) plane is actually configured without any IP functionality. However I think that DCN requirements should be described in draft-gray-mpls-tp-nm-req-00.txt. For the scope of draft-jenkins-mpls-mpls-tp-requirements-00.txt, I think that it is more appropriate to rephrase the requirement as proposed by Julien. Italo > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli > Sent: Monday, August 04, 2008 6:00 PM > To: julien.meuric@orange-ftgroup.com > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 5:48 PM, =20 > wrote: > > Hi Francesco. >=20 > Hi Julien, >=20 > > I guess I understand your concern. I believe the original=20 > intention was > > to say implicitely "It MUST be possible to operate and configure the > > MPLS-TP data (transport) plane without any IP functionality=20 > *in the data > > plane*." My interpretation of these requirements is indeed that they > > apply to the MPLS-TP data plane only, not the=20 > MPLS-TP-capable equipment, > > nor the MPLS-TP control plane... > > > > Anyway you're right, this could be confusing and it deserves a small > > rewording. >=20 > Nice, thanks a lot. >=20 > > Regards, > > > > Julien >=20 > Ciao > FF > _______________________________________________ > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 18:08:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: NomCom-volunteer Date: Mon, 4 Aug 2008 14:07:28 -0400 Message-ID: Thread-Topic: NomCom-volunteer thread-index: Acj2TEKPEHtwOvNCSfG6nt/b+J+rWQAEFYaQ From: "BRUNGARD, DEBORAH A, ATTLABS" To: Volunteers needed...=20 -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Sunday, August 03, 2008 10:43 AM To: Working Group Chairs Subject: Please ask your WG...=20 To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: = https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: = https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 16:35:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:reply-to:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:from; bh=s7XvcKbH/HbHVNbJr4zZ3p3OqlNpApJMzlC0NMrOL8s=; b=Jftj2usD2aePsVGoJDxkGouEEzDLkYnl751Pj+vxt4iFxQONxL3y6y60Wfjk8HF4nW KzR6BFu6tnNPTXqo35ooBpnJI/t/O8x9PfLDLRUzL/x4WqskUpCn+iSw6M1Obbc4z1zF ipOt1uOR1R8uaBiFeem4yE0/Vq2dAF/iCqHbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:reply-to:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:from; b=dpjYRhchio9bf2AvpC8OfhEqKV7+ewYfzdEdhaP4OONtuESpoc4vVYTP7xEQ6MMXPw mM6iAk/zwcg+A4a+3yTOXu1Qql7UaJ/u4A0FXahEvaeJ7/4elu5pzQnx45J/Rnti/spG ZFStraG68yUhSYIwuiw5IhXO4OdNLvdppW/W0= Message-ID: <48972F70.6090503@chello.nl> Date: Mon, 04 Aug 2008 18:33:52 +0200 Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francesco Fondelli CC: ccamp@ops.ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] MPLS over OTN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Huub van Helvoort Hi Francesco, You replied: >> This requirement defines that the MPLS-TP data (transport) plane operates in >> the absence of an IP data (transport) plane. This requirement does not say >> anything about the DCN, and the technologies deployed in this DCN. > > I agree with you, but I think that "and configure" should be removed. > > How can you *configure* MPLS-TP data plane without IP (or OSI)? > Am I the only one that feel uncomfortable with this piece of text? By using the same NMS that is used to configure the OTN node. Ciao, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 15:49:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:48:57 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605C591F9@ftrdmel2> Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RzhHZYPvGZHKQvSW9uyhF8h+KQAAEiUw From: To: , Cc: , Hi Francesco. I guess I understand your concern. I believe the original intention was to say implicitely "It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality *in the data plane*." My interpretation of these requirements is indeed that they apply to the MPLS-TP data plane only, not the MPLS-TP-capable equipment, nor the MPLS-TP control plane... Anyway you're right, this could be confusing and it deserves a small rewording. Regards, Julien -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Francesco Fondelli On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers wrote: > Francesco, Hi Maarten, > This requirement defines that the MPLS-TP data (transport) plane operates in > the absence of an IP data (transport) plane. This requirement does not say > anything about the DCN, and the technologies deployed in this DCN. I agree with you, but I think that "and configure" should be removed. How can you *configure* MPLS-TP data plane without IP (or OSI)? Am I the only one that feel uncomfortable with this piece of text? > Regards, > Maarten Ciao FF _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 15:36:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:35:37 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D9192@esealmw110.eemea.ericsson.se> Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2RziBN94FSrJJRDqmhVwarGF9HQAACsaQ From: "Diego Caviglia" To: "Francesco Fondelli" , "Maarten Vissers" Cc: , Opsss you are right! I've missed the term configure! I was focused on the fact that an = MPLS-TP equipment doesn't need to be able to perform IP forwarding at = the data plane. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Francesco Fondelli > Sent: luned=EC 4 agosto 2008 17.32 > To: Maarten Vissers > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 4:28 PM, Maarten Vissers > wrote: > > Francesco, >=20 > Hi Maarten, >=20 > > This requirement defines that the MPLS-TP data (transport) plane > operates in > > the absence of an IP data (transport) plane. This requirement does = not > say > > anything about the DCN, and the technologies deployed in this DCN. >=20 > I agree with you, but I think that "and configure" should be removed. >=20 > How can you *configure* MPLS-TP data plane without IP (or OSI)? > Am I the only one that feel uncomfortable with this piece of text? >=20 > > Regards, > > Maarten >=20 > Ciao > FF > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 15:26:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] MPLS over OTN Date: Mon, 4 Aug 2008 17:23:25 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684019D9179@esealmw110.eemea.ericsson.se> Thread-Topic: [mpls-tp] MPLS over OTN Thread-Index: Acj2NMQrRuV74AIWRc2/REYySSC6WwACPVDgAAIIopA= From: "Diego Caviglia" To: "Maarten Vissers" , "Francesco Fondelli" Cc: , Hi, I think that the Maarten interpretation is correct. BR Diego > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf > Of Maarten Vissers > Sent: luned=EC 4 agosto 2008 16.28 > To: 'Francesco Fondelli' > Cc: ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > Francesco, >=20 > This requirement defines that the MPLS-TP data (transport) plane = operates > in > the absence of an IP data (transport) plane. This requirement does not = say > anything about the DCN, and the technologies deployed in this DCN. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] > Sent: 04 August 2008 15:00 > To: Maarten Vissers > Cc: Adrian Farrel; Howard Green; ccamp@ops.ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] MPLS over OTN >=20 > On Mon, Aug 4, 2008 at 2:50 PM, Maarten Vissers > > wrote: > > Adrian, Howard, > > > > The transport network has a DCN, and this DCN inlcudes today a mix = of > > OSI and IP technologies. >=20 > Hi, >=20 > --- draft-jenkins-mpls-mpls-tp-requirements-00 >=20 > o It MUST be possible to operate and configure the MPLS-TP data > (transport) plane without any IP functionality. >=20 > --- >=20 > So what do you think about this requirement? >=20 > Ciao > FF >=20 >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 08:44:24 +0000 Message-ID: <02c201c8f60e$196c4480$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Howard Green" , Cc: Subject: Re: MPLS over OTN Date: Mon, 4 Aug 2008 09:42:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi again Howard, So, to pick apart the control plane in an MPLS network ( I think I am agreeing with you fully)... In band This could only happen using the sort of mechanisms being proposed for ACH. That is, each control plane message is packaged as an MPLS packet and labelled as for the LSP that it is controlling. The TTL is set to one (or more to allow non-adjacent signalling). A secondary label on the stack might be used to identify the control plane when the top-level label expires. We already have the Router Alert label defined. However, such a mechanism would only work for existing LSPs meaning that we could never set up new ones! Out of band in fibre (Bear in mind that the nature of MPLS means that this is very similar to in band except within the switching fabric) To make this work we simply need a reserved label to identify control plane traffic. The Router Alert label already provides this. However, we lack a mechanism for non-adjacent signalling. There are two use cases in GMPLS... 1. Hierarchical and stitched LSPs In this case, we can use the hierarchical or stitched LSP to carry the control traffic. For hierarchical, it is simple since we can put the Router Alert label second on the stack where it will be discovered when the top label is popped. For stitching, we must also set the TTL to expire at the end of the stitching segment. 2. Notify messages These messages may be exchanged between non-adjacent nodes. Normally they rely on IP routing, but there is an option to get them forwarded hop-by-hop by the control planes of the nodes along the LSP - this is NOT IP-based forwarding, but relies on each node on the path of an LSP knowing the next control plane node in each direction (something that is required by RSVP-TE anyway). An alternative is to use the LSP that is being notified, and to set the TTL as necessary also using a Router Alert label just as for stitching. A further alternative (sufficient but not necessary) approach would be to set up a mesh of LSPs to support the control plane. Out of band out of fibre I am inclined to agree that there may often be good reasons to operate this way. Using an IP network as a DCN makes a lot of sense and it should be noted that this does not require that the NEs have IP forwarding capabilities. Cheers, Adrian ----- Original Message ----- From: "Howard Green" To: "Adrian Farrel" ; Cc: Sent: Monday, August 04, 2008 9:23 AM Subject: RE: MPLS over OTN Adrian Thanks (for the homily as well!) My apologies for some lack of clarity. As you say, GMPLS control of OTN is what it is. The use of a G-PID describing an MPLS payload does, presumably, allow an OTN path to be advertised (with suitable policy constraints) as an MPLS forwarding adjacency. In the MPLS layer above this OTN, it is not so obvious how to carry IP "in band", and therefore the GMPLS mechanics seem to be required. As you say, the control plane could be "OOB but in fiber" (or here, in OTN path) or out of fibre. Thus there would seem to be utility in an optional associated channel mechanism for the control plane. I wonder whether there may be a requirement of the reverse kind (maximum diversity between data plane and control plane) in some circumstances. /Howard > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 01 August 2008 10:53 > To: Howard Green; ccamp@ops.ietf.org > Cc: mpls-tp@ietf.org > Subject: Re: MPLS over OTN > > Hi Howard, > > [adding MPLS-TP mailing list] > > Accurate representation of our conversation. > That is, in GMPLS we have label type, switching type, > encoding type, and G-PID. > G-PID identifies the payload and re-uses the Ethertype > codepoints. Thus we can carry MPLS. > If GFP is used for framing, it must also identify the payload > and, as you point out, GFP has an MPLS codepoint. > > That the GFP codepoint for MPLS is the same as that for > "T-MPLS" is good for Option 1 (which is where we are) since > there is no practical difference between MPLS and MPLS-TP. > > Now, the operation of MPLS over OTN that you describe is > actually the operation of an OTN. So the issues of control > channels in OTN are exactly as you describe, but have nothing > to do with the payload protocol. This is simply GMPLS control > of OTN. Period. > > GMPLS control of MPLS-TP is a different kettle of ball games. > Here the switching type is PSC: the same switching type as > for MPLS. A feature of GMPLS is that there is *logical* > separation of control plane and data plane. > This means that the control plane can be in-band (MPLS-TE), > out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre. > > MPLS-TP requirements say that it must be possible to operate > the network "in the absence of IP." I have taken this to mean > "in the absence of IP routing and forwarding" (but this is my > opinion and there is no explicit evidence in the requirements > I-D). With this view... > - We can use IP identifiers (addresses) in the data plane and > the control plane > - We can use IP-based control protocols (GMPLS) > - We can use an IP-based control network if available, but we cannot > mandate it > - Control entities that need to communicate must be allowed to be > IP-adjacent so that there is no requirement for > IP-forwarding in the > network > > I believe we can do all of the above, and often do in GMPLS networks. > The crunch questions are: > 1. What is the physical technology for the data links in the > control plane? > 2. How do we identify control plane traffic when it arrives at a node? > 3. How do we exchange control plane messages between nodes that > do not have a common data link in the control plane? > > Answers are: > 1. We don't care :-) > But a possible answer in MPLS-TP is an LSP (e.g. a > reserved label) 2. From the data link (since there is no need > to disambiguate the control > plane traffic from any other traffic on the data link) 3. > This is a more tricky question. However nearly all of the messages > are exchanged only between data-plane-adjacent nodes. This can be > the case in the IGP-TE protocols, and is true for all messages in > RSVP-TE with a couple of exceptions (below). It is also > the case for > LMP. So IP forwarding is not required in the control plane. > The tricky cases are: > - echo response in LSP Ping (we are rebuilding the OAM) > - Notify message in RSVP-TE (we are considering OAM approaches > for the uses of Notify where IP forwarding is not available) > - "Targeted Path messages" used in hierarchical LSPs (and LSP > stitching). In these cases we are effectively building a virtual > data plane adjacency and should build a parallel virtual control > plane link between the end points (e.g. an LSP). > > We should note that the output of the JWT *appears* to be > that "GMPLS meets the requirements of a control plane for MPLS-TP." > > We should also note that management plane operation of > MPLS-TP is a requirement, and we must assume that management > plane messages may need to be exchanged between management > stations and network nodes using some protocol and connectivity. > > > > Adrian > ----- Original Message ----- > From: "Howard Green" > To: > Sent: Thursday, July 31, 2008 5:55 PM > Subject: MPLS over OTN > > > Just to record for the list a chat with Adrian and Lou Berger. I > discover from reading G.7041 Amendment 2 that there is a codepoint > defined to allow unicast MPLS frames to be carried over OTN (ODUx) > channels by way of GFP encoding. Reading RFC 4328, there is > an encoding > type for ODUx, and the switching type is TDM. There is no > specific G-PID > value defined for the MPLS codepoint (which was probably defined > concurrently with the writing of RFC 4328). Adrian and Lou > took the view > that in this situation, the use of the unicast MPLS ethertype (#8847) > would define for signalling this bearer type (as described in > RFC 3471). > > This is relevant partly because G.7041 amendment 2 defines > the codepoint > to be for "MPLS or T-MPLS". I assume that this usage carries over to > MPLS-TP. In this situation,interestingly, there is no > prospect of inband > IP control, and so GMPLS is the only control plane option. > Is this correct? > Regards Howard > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Aug 2008 08:27:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: MPLS over OTN Date: Mon, 4 Aug 2008 10:23:54 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1403BEB9C2@esealmw118.eemea.ericsson.se> Thread-Topic: MPLS over OTN Thread-Index: AcjztBjHyt6w6stjR36S7lGwsWPkiQCVYblw From: "Howard Green" To: "Adrian Farrel" , Cc: Adrian Thanks (for the homily as well!) My apologies for some lack of clarity. As you say, GMPLS control of OTN is what it is. The use of a G-PID describing an MPLS payload does, presumably, allow an OTN path to be advertised (with suitable policy constraints) as an MPLS forwarding adjacency. In the MPLS layer above this OTN, it is not so obvious how to carry IP "in band", and therefore the GMPLS mechanics seem to be required. As you say, the control plane could be "OOB but in fiber" (or here, in OTN path) or out of fibre. Thus there would seem to be utility in an optional associated channel mechanism for the control plane. I wonder whether there may be a requirement of the reverse kind (maximum diversity between data plane and control plane) in some circumstances. /Howard > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: 01 August 2008 10:53 > To: Howard Green; ccamp@ops.ietf.org > Cc: mpls-tp@ietf.org > Subject: Re: MPLS over OTN >=20 > Hi Howard, >=20 > [adding MPLS-TP mailing list] >=20 > Accurate representation of our conversation. > That is, in GMPLS we have label type, switching type,=20 > encoding type, and G-PID. > G-PID identifies the payload and re-uses the Ethertype=20 > codepoints. Thus we can carry MPLS. > If GFP is used for framing, it must also identify the payload=20 > and, as you point out, GFP has an MPLS codepoint. >=20 > That the GFP codepoint for MPLS is the same as that for=20 > "T-MPLS" is good for Option 1 (which is where we are) since=20 > there is no practical difference between MPLS and MPLS-TP. >=20 > Now, the operation of MPLS over OTN that you describe is=20 > actually the operation of an OTN. So the issues of control=20 > channels in OTN are exactly as you describe, but have nothing=20 > to do with the payload protocol. This is simply GMPLS control=20 > of OTN. Period. >=20 > GMPLS control of MPLS-TP is a different kettle of ball games.=20 > Here the switching type is PSC: the same switching type as=20 > for MPLS. A feature of GMPLS is that there is *logical*=20 > separation of control plane and data plane.=20 > This means that the control plane can be in-band (MPLS-TE),=20 > out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre. >=20 > MPLS-TP requirements say that it must be possible to operate=20 > the network "in the absence of IP." I have taken this to mean=20 > "in the absence of IP routing and forwarding" (but this is my=20 > opinion and there is no explicit evidence in the requirements=20 > I-D). With this view... > - We can use IP identifiers (addresses) in the data plane and=20 > the control plane > - We can use IP-based control protocols (GMPLS) > - We can use an IP-based control network if available, but we cannot > mandate it > - Control entities that need to communicate must be allowed to be > IP-adjacent so that there is no requirement for=20 > IP-forwarding in the > network >=20 > I believe we can do all of the above, and often do in GMPLS networks. > The crunch questions are: > 1. What is the physical technology for the data links in the=20 > control plane? > 2. How do we identify control plane traffic when it arrives at a node? > 3. How do we exchange control plane messages between nodes that > do not have a common data link in the control plane? >=20 > Answers are: > 1. We don't care :-) > But a possible answer in MPLS-TP is an LSP (e.g. a=20 > reserved label) 2. From the data link (since there is no need=20 > to disambiguate the control > plane traffic from any other traffic on the data link) 3.=20 > This is a more tricky question. However nearly all of the messages > are exchanged only between data-plane-adjacent nodes. This can be > the case in the IGP-TE protocols, and is true for all messages in > RSVP-TE with a couple of exceptions (below). It is also=20 > the case for > LMP. So IP forwarding is not required in the control plane. > The tricky cases are: > - echo response in LSP Ping (we are rebuilding the OAM) > - Notify message in RSVP-TE (we are considering OAM approaches > for the uses of Notify where IP forwarding is not available) > - "Targeted Path messages" used in hierarchical LSPs (and LSP > stitching). In these cases we are effectively building a virtual > data plane adjacency and should build a parallel virtual control > plane link between the end points (e.g. an LSP). >=20 > We should note that the output of the JWT *appears* to be=20 > that "GMPLS meets the requirements of a control plane for MPLS-TP." >=20 > We should also note that management plane operation of=20 > MPLS-TP is a requirement, and we must assume that management=20 > plane messages may need to be exchanged between management=20 > stations and network nodes using some protocol and connectivity. >=20 > >=20 > Adrian > ----- Original Message ----- > From: "Howard Green" > To: > Sent: Thursday, July 31, 2008 5:55 PM > Subject: MPLS over OTN >=20 >=20 > Just to record for the list a chat with Adrian and Lou Berger. I > discover from reading G.7041 Amendment 2 that there is a codepoint > defined to allow unicast MPLS frames to be carried over OTN (ODUx) > channels by way of GFP encoding. Reading RFC 4328, there is=20 > an encoding > type for ODUx, and the switching type is TDM. There is no=20 > specific G-PID > value defined for the MPLS codepoint (which was probably defined > concurrently with the writing of RFC 4328). Adrian and Lou=20 > took the view > that in this situation, the use of the unicast MPLS ethertype (#8847) > would define for signalling this bearer type (as described in=20 > RFC 3471). >=20 > This is relevant partly because G.7041 amendment 2 defines=20 > the codepoint > to be for "MPLS or T-MPLS". I assume that this usage carries over to > MPLS-TP. In this situation,interestingly, there is no=20 > prospect of inband > IP control, and so GMPLS is the only control plane option. > Is this correct? > Regards Howard >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Aug 2008 09:09:37 +0000 Date: Fri, 01 Aug 2008 17:09:57 +0800 From: Dan Li Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" To: "Bardalai, Snigdho" , "Ccamp (E-mail)" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)" This is a multi-part message in MIME format. --Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho, Very good question! See my comments below. Thanks, Dan ----- Original Message ----- From: Bardalai, Snigdho To: Ccamp (E-mail) Sent: Friday, August 01, 2008 4:26 AM Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt" Hi Adrian and Dan, I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following: 1. IGP usage in the context of traditional distributed solutions for WSON [Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at. 2. IGP usage in the context of PCE solutions for WSON [Dan] It's a potential way for PCE to get the wavelength information. 3. Flooding and refresh of static and dynamic link state updates [Dan] Try to figure out the impact to the performance of IGP. 4. Data base sync-up during node restarts [Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces. Could you please let me know if the above is within the current scope? I believe that these are important. Thanks, Snigdho --Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Hi Snigdho,
 
Very good question! See my comments below.
 
Thanks,
 
Dan
----- Original Message -----
Sent: Friday, August 01, 2008 4:26 AM
Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Hi Adrian and Dan,

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:

1. IGP usage in the context of traditional distributed solutions for WSON

[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.


2. IGP usage in the context of PCE solutions for WSON

[Dan] It's a potential way for PCE to get the wavelength information.

 
3. Flooding and refresh of static and dynamic link state updates

[Dan] Try to figure out the impact to the performance of IGP.

 
4. Data base sync-up during node restarts

[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.

Could you please let me know if the above is within the current scope? I believe that these are important.

Thanks,
Snigdho





--Boundary_(ID_hU39AcFMy7w3+H6c7ZRWLw)-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Aug 2008 08:55:01 +0000 Message-ID: <01be01c8f3b4$10a3eb20$91168182@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Howard Green" , Cc: Subject: Re: MPLS over OTN Date: Fri, 1 Aug 2008 09:53:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Howard, [adding MPLS-TP mailing list] Accurate representation of our conversation. That is, in GMPLS we have label type, switching type, encoding type, and G-PID. G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we can carry MPLS. If GFP is used for framing, it must also identify the payload and, as you point out, GFP has an MPLS codepoint. That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for Option 1 (which is where we are) since there is no practical difference between MPLS and MPLS-TP. Now, the operation of MPLS over OTN that you describe is actually the operation of an OTN. So the issues of control channels in OTN are exactly as you describe, but have nothing to do with the payload protocol. This is simply GMPLS control of OTN. Period. GMPLS control of MPLS-TP is a different kettle of ball games. Here the switching type is PSC: the same switching type as for MPLS. A feature of GMPLS is that there is *logical* separation of control plane and data plane. This means that the control plane can be in-band (MPLS-TE), out-of-band but in-fibre (SONET/SDH or OSC), or out-of-fibre. MPLS-TP requirements say that it must be possible to operate the network "in the absence of IP." I have taken this to mean "in the absence of IP routing and forwarding" (but this is my opinion and there is no explicit evidence in the requirements I-D). With this view... - We can use IP identifiers (addresses) in the data plane and the control plane - We can use IP-based control protocols (GMPLS) - We can use an IP-based control network if available, but we cannot mandate it - Control entities that need to communicate must be allowed to be IP-adjacent so that there is no requirement for IP-forwarding in the network I believe we can do all of the above, and often do in GMPLS networks. The crunch questions are: 1. What is the physical technology for the data links in the control plane? 2. How do we identify control plane traffic when it arrives at a node? 3. How do we exchange control plane messages between nodes that do not have a common data link in the control plane? Answers are: 1. We don't care :-) But a possible answer in MPLS-TP is an LSP (e.g. a reserved label) 2. From the data link (since there is no need to disambiguate the control plane traffic from any other traffic on the data link) 3. This is a more tricky question. However nearly all of the messages are exchanged only between data-plane-adjacent nodes. This can be the case in the IGP-TE protocols, and is true for all messages in RSVP-TE with a couple of exceptions (below). It is also the case for LMP. So IP forwarding is not required in the control plane. The tricky cases are: - echo response in LSP Ping (we are rebuilding the OAM) - Notify message in RSVP-TE (we are considering OAM approaches for the uses of Notify where IP forwarding is not available) - "Targeted Path messages" used in hierarchical LSPs (and LSP stitching). In these cases we are effectively building a virtual data plane adjacency and should build a parallel virtual control plane link between the end points (e.g. an LSP). We should note that the output of the JWT *appears* to be that "GMPLS meets the requirements of a control plane for MPLS-TP." We should also note that management plane operation of MPLS-TP is a requirement, and we must assume that management plane messages may need to be exchanged between management stations and network nodes using some protocol and connectivity. Adrian ----- Original Message ----- From: "Howard Green" To: Sent: Thursday, July 31, 2008 5:55 PM Subject: MPLS over OTN Just to record for the list a chat with Adrian and Lou Berger. I discover from reading G.7041 Amendment 2 that there is a codepoint defined to allow unicast MPLS frames to be carried over OTN (ODUx) channels by way of GFP encoding. Reading RFC 4328, there is an encoding type for ODUx, and the switching type is TDM. There is no specific G-PID value defined for the MPLS codepoint (which was probably defined concurrently with the writing of RFC 4328). Adrian and Lou took the view that in this situation, the use of the unicast MPLS ethertype (#8847) would define for signalling this bearer type (as described in RFC 3471). This is relevant partly because G.7041 amendment 2 defines the codepoint to be for "MPLS or T-MPLS". I assume that this usage carries over to MPLS-TP. In this situation,interestingly, there is no prospect of inband IP control, and so GMPLS is the only control plane option. Is this correct? Regards Howard Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Aug 2008 07:36:40 +0000 Message-ID: <4892BC91.7010606@pi.nu> Date: Fri, 01 Aug 2008 09:34:41 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Attila Takacs CC: ccamp Subject: some comments on I-D Action:draft-takacs-ccamp-revertive-ps-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attila, I have planned respond to this for same time, but did not really had time to get around to it. Attila Takacs wrote: > Hi Loa, > > I assume a part of your comment/question relates to problems with > reversion if LSP setup and holding priorities are mismatched. that would be one case, but not really what i was thinking of > In this > case the worker may be already deleted before the reversion would take > place. This is certainly an interesting question... sure > > ...at a first thought an explicit revertive bit may be used to override > the priorities for LSPs with revertive protection. I've two questions: 1. If revertiveness is the normal procedure, wouldn't it be better to let indicate LSPs that *shouldn't* revert? 2. What I really thought about was, how does revertiveness work with traffic placement policies? Assume that you have a policy that that says you want to optimize the chances to successfully set up an LSP that make a maximum share of some constraints. It could be any constraints, but thinking of it as bw wouldn't wrong. Assume also that you have three different routes form A to B, through C, D and E respectively. Assume that each of the nodes C, D and E has interfaces with constraint of 100. This is of course a very simplified model just to illustrate my point. In order the follow your policy you place traffic on C and E, and leave D free, if there is a request for an LSP that requires 100. So the situation could be: C = 40 occupied, 60 free D = 100 free E = 40 occupied, 60 free now if C fails it makes sense to move the traffic to E: C = failed D = 100 free E = 80 occupied, 20 free If the failure takes some time to repair, there might be a request for a LSP that requires 60, the only possibility is to place on D: C = failed D = 60 occupied, 40 free E = 80 occupied, 20 free Now C comes back up: C = 100 free D = 60 occupied, 40 free E = 80 occupied, 20 free This situation is in accordance with your policy, but if you revert you loose the ability to place any LSPs which requires more than 60 C = 40 occupied, 60 free D = 60 occupied, 40 free E = 40 occupied, 60 free Why would you want to revert in this case? Now there might be some optimization program working in the background, that might move traffic from any of nodes to any of the other, possibly from C to E. I seems to me that running an optimization program is more efficient. /Loa > > Best regards, > Attila > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu