From gregb@grotto-networking.com Mon Jan 3 08:53:55 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53313A67C0 for ; Mon, 3 Jan 2011 08:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbLQgLlqQ1Nv for ; Mon, 3 Jan 2011 08:53:54 -0800 (PST) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id B28AE3A68C9 for ; Mon, 3 Jan 2011 08:53:50 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p03GtrqH001883; Mon, 3 Jan 2011 16:55:55 GMT Message-ID: <4D21FF94.8090205@grotto-networking.com> Date: Mon, 03 Jan 2011 08:55:48 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "PELOSO, PIERRE (PIERRE)" References: <4D07B635.1030503@grotto-networking.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050509050307010405010309" X-CSC: 0 X-CHA: v=1.1 cv=p6LJilDI9yL6Te5GsYdCX7gUnVKLIZwbSeqBs+RSYhU= c=1 sm=1 a=_4VyIEzS4mEA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=bDzJ-RKyH7FSVeu4ryAA:9 a=iopHcOGiVb4AOhvkj3IA:7 a=jHc8F59cWXY5Ra4MPDC5CrAEOykA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=lZB815dzVvQA:10 a=hjIzpPt6dqJR4AZS:21 a=WiVsEqZopmPK_i0L:21 a=gxZvrgisAAAA:8 a=EeZnZbW5bV_Fo1q0dLQA:9 a=Lt0CPDToBeqWTNkKXaIA:7 a=-O_3MDDWAonBnbEQs1XUzzfFekoA:4 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:53:56 -0000 This is a multi-part message in MIME format. --------------050509050307010405010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint: "*/The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router/*. Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV." So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances? Other opinions? Best Regards Greg On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: > Hi Greg, > To start with, I am pretty in-line with the part related to the link > TLV, which was already agreed. > Regarding the node related information, I am happy to see that you > consider splitting its information over 2 top-level TLVs, which we > have been proning in order to ease the scalability and the information > organisation. > I do encourage you to adopt even more the concepts proned in > draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in > a way that allows to have multiple instance of it, one for each > conistent entity of ressoruces. > To detail my point of view, considering that I bet you would keep > inside the node attribute top-level TLV the connectivity matrix > object, and transfer the informations concerning the OEO ressources to > the new top-level TLV that you suggest to name Node Property. I have > no hard convinctions on any name, and this one can fit with me, it is > not the important thing anyway. > I insist that, what seems more important to me is really to benefit > fully from the advantages brought by introducing a new top-level TLV > (which was apparently one of the thinks you were reluctant to do), > namely the capability to have one instance of this type per pool. Here > a pool, being a consistent bunch of OEO resources, sharing the fact > that updating the usage of one of them will have consequences on the > accessibility of the others. Which is to my mind the smallest > information entity that will need a single update on the modification > of usage of one of its members, hence the most compliant with scalability. > To summarize, once the cost of introducing a new top-level TLV is > accepted, let's use the advantages of the concepts introduced in our > solution to their full extent, and then use a layout of information > compliant with that. Does this sems reasonnable for you, and for the WG ? > - pierre > P.S. Let's keep aside right now the discussions concerning the > administrative group, and TE metric sub-TLVs. > ------------------------------------------------------------------------ > *De :* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *De la > part de* Greg Bernstein > *Envoyé :* mardi 14 décembre 2010 19:24 > *À :* CCAMP > *Objet :* [CCAMP] Top Level TLVs for WSON and General Constraint > Extensions to OSPF (long) > > Hi all two weeks ago we updated > draft-ietf-ccamp-general-constraint-encode and > draft-ietf-ccamp-rwa-wson-encode based on comments from the list > and the Beijing meeting. These changes were editorial in nature > and consisted of removing some informational text. > To move things forward in general we need to reach agreement on > the top level TLVs to be used to carry this information. We have > two main types of information: (a) link related, and (b) node > related. In addition, depending on the complexity of the system > we may want to split the information for a particular node or link > into multiple LSAs to keep the size of the LSA below a particular > limit or to separate rapidly changing node or link information > from relatively static. In general multiple TE LSA instances > provide a mechanism for this. > > *For Link information* *RFC3630* defines the "Traffic Engineering > LSA". This has area scope. > "One new LSA is defined, the Traffic Engineering LSA. This LSA > describes routers, point-to-point links, and connections to > multi-access networks (similar to a Router LSA)." > > Multiple instances can exist from a single source: > "The Instance field is an arbitrary value used to maintain > multiple Traffic Engineering LSAs. A maximum of 16777216 Traffic > Engineering LSAs may be sourced by a single system." > > Two top level TLVs are defined: Router Address TLV (section 2.4.1) > and Link TLV (section 2.4.2). The router address is just as it > says. The link TLV is the generally useful one for us: > "The Link TLV describes a single link. It is constructed of a set > of sub-TLVs. There are no ordering requirements for the sub-TLVs. > Only one Link TLV shall be carried in each LSA, allowing for fine > granularity changes in topology." > > There does not appear to be any constraints on breaking up > information about a single link into multiple LSAs. For WSON use > we may want to keep static information (port wavelength > constraints) separate from dynamic information (wavelength > availability). > > *For Node Level information* (such as connectivity matrices, > resource block information, resource block usage state) it seemed > like *RFC 5786* which has extensions for advertising a routers > local addresses in TE extensions would be useful. It defines the > OSPF TE LSA Node TLV and they state: > "It is anticipated that the Node Attribute TLV will also prove > more generally useful." > However in section 4.2 (Operation) they state: > "*/The Node Attribute TLV MUST NOT appear in more than one TE LSA > originated by a router/*. Furthermore, such an LSA MUST NOT > include more than one Node Attribute TLV." > > The first of these restrictions on use seems to preclude us from > separating traffic matrices, resource block descriptions, and > resource block utilization status into separate LSA instances > using this TLV. Unless this rule can be changed it seems that we > will need a new top level "node properties" TLV for use in both > WSON specific and General constraint extensions to OSPF. Pierre > and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to > define a new top level TLV for the resource block information, > however it seems that we probably should ask for a general "node > properties" (or whatever better name we can think of) top level > TLV that could be applied to the general constraint node > information (connectivity matrices) as well as the various > resource related quantities. > > Pierre and Giovanni does this sound like a reasonable way forward? > Or do you have a different suggestion. Comments and suggestions > from all are welcome. > > Best Regards > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050509050307010405010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint:
    "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:
Hi Greg,
 
To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.
 
Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information organisation.
I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.
 
To detail my point of view, considering that I bet you would keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.
I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, being a consistent bunch of OEO resources, sharing the fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind the smallest information entity that will need a single update on the modification of usage of one of its members, hence the most compliant with scalability.
 
To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG ?
 
- pierre
 
P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoyé : mardi 14 décembre 2010 19:24
À : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a set of sub-TLVs.  There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology."

There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).

For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more generally useful."
However in section 4.2 (Operation) they state:
"The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments and suggestions from all are welcome.

Best Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050509050307010405010309-- From acee.lindem@ericsson.com Thu Jan 6 09:22:47 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1058D3A6E36 for ; Thu, 6 Jan 2011 09:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Hr6LeDfGjV for ; Thu, 6 Jan 2011 09:22:45 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id BCCFE3A6C9B for ; Thu, 6 Jan 2011 09:22:44 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p06I117n018303; Thu, 6 Jan 2011 12:01:03 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 6 Jan 2011 12:24:45 -0500 From: Acee Lindem To: Greg Bernstein Date: Thu, 6 Jan 2011 12:24:41 -0500 Thread-Topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-Index: AcutxpxpyXylMEL5TQWoF72BtITcgQ== Message-ID: References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> In-Reply-To: <4D21FF94.8090205@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-31-347385821"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:22:47 -0000 --Apple-Mail-31-347385821 Content-Type: multipart/alternative; boundary=Apple-Mail-30-347385806 --Apple-Mail-30-347385806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Greg,=20 I think it is better to get 1 or 2 new top-level TE TLVs than to = overload the TE Node Attribute TLV" with the optical capabilities = information.=20 Thanks, Acee=20 On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: > Hi Pierre, do you think we should still try to use the "node attribute = top level TLV" from RFC5786? A complete node description may require = multiple connectivity matrices and these could potentially become large. = RFC5786 has the constraint:=20 > "The Node Attribute TLV MUST NOT appear in more than one TE LSA = originated by a router. Furthermore, such an LSA MUST NOT include more = than one Node Attribute TLV."=20 >=20 > So we couldn't split them up for MTU purposes. It seems that one new = top level TLV for a node without the RFC5786 constraints would suffice. = Do you think we need two? How would we justify two new top level TLVs to = the OSPF WG when we have the ability to use multiple instances? >=20 > Other opinions? >=20 > Best Regards >=20 > Greg=20 > On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: >>=20 >> Hi Greg, >> =20 >> To start with, I am pretty in-line with the part related to the link = TLV, which was already agreed. >> =20 >> Regarding the node related information, I am happy to see that you = consider splitting its information over 2 top-level TLVs, which we have = been proning in order to ease the scalability and the information = organisation. >> I do encourage you to adopt even more the concepts proned in = draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a = way that allows to have multiple instance of it, one for each conistent = entity of ressoruces. >> =20 >> To detail my point of view, considering that I bet you would keep = inside the node attribute top-level TLV the connectivity matrix object, = and transfer the informations concerning the OEO ressources to the new = top-level TLV that you suggest to name Node Property. I have no hard = convinctions on any name, and this one can fit with me, it is not the = important thing anyway. >> I insist that, what seems more important to me is really to benefit = fully from the advantages brought by introducing a new top-level TLV = (which was apparently one of the thinks you were reluctant to do), = namely the capability to have one instance of this type per pool. Here a = pool, being a consistent bunch of OEO resources, sharing the fact that = updating the usage of one of them will have consequences on the = accessibility of the others. Which is to my mind the smallest = information entity that will need a single update on the modification of = usage of one of its members, hence the most compliant with scalability. >> =20 >> To summarize, once the cost of introducing a new top-level TLV is = accepted, let's use the advantages of the concepts introduced in our = solution to their full extent, and then use a layout of information = compliant with that. Does this sems reasonnable for you, and for the WG = ? >> =20 >> - pierre >> =20 >> P.S. Let's keep aside right now the discussions concerning the = administrative group, and TE metric sub-TLVs. >> De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la = part de Greg Bernstein >> Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 >> =C0 : CCAMP >> Objet : [CCAMP] Top Level TLVs for WSON and General Constraint = Extensions to OSPF (long) >>=20 >> Hi all two weeks ago we updated = draft-ietf-ccamp-general-constraint-encode and = draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the = Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text.=20 >> To move things forward in general we need to reach agreement on the = top level TLVs to be used to carry this information. We have two main = types of information: (a) link related, and (b) node related. In = addition, depending on the complexity of the system we may want to split = the information for a particular node or link into multiple LSAs to = keep the size of the LSA below a particular limit or to separate rapidly = changing node or link information from relatively static. In general = multiple TE LSA instances provide a mechanism for this. >>=20 >> For Link information RFC3630 defines the "Traffic Engineering LSA". = This has area scope. >> "One new LSA is defined, the Traffic Engineering LSA. This LSA = describes routers, point-to-point links, and connections to multi-access = networks (similar to a Router LSA)." >>=20 >> Multiple instances can exist from a single source: >> "The Instance field is an arbitrary value used to maintain multiple = Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering = LSAs may be sourced by a single system." >>=20 >> Two top level TLVs are defined: Router Address TLV (section 2.4.1) = and Link TLV (section 2.4.2). The router address is just as it says. The = link TLV is the generally useful one for us: >> "The Link TLV describes a single link. It is constructed of a set of = sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one = Link TLV shall be carried in each LSA, allowing for fine granularity = changes in topology." >>=20 >> There does not appear to be any constraints on breaking up = information about a single link into multiple LSAs. For WSON use we may = want to keep static information (port wavelength constraints) separate = from dynamic information (wavelength availability). >>=20 >> For Node Level information (such as connectivity matrices, resource = block information, resource block usage state) it seemed like RFC 5786 = which has extensions for advertising a routers local addresses in TE = extensions would be useful. It defines the OSPF TE LSA Node TLV and they = state: >> "It is anticipated that the Node Attribute TLV will also prove more = generally useful." >> However in section 4.2 (Operation) they state: >> "The Node Attribute TLV MUST NOT appear in more than one TE LSA = originated by a router. Furthermore, such an LSA MUST NOT include more = than one Node Attribute TLV." >>=20 >> The first of these restrictions on use seems to preclude us from = separating traffic matrices, resource block descriptions, and resource = block utilization status into separate LSA instances using this TLV. = Unless this rule can be changed it seems that we will need a new top = level "node properties" TLV for use in both WSON specific and General = constraint extensions to OSPF. Pierre and Giovanni in = draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level = TLV for the resource block information, however it seems that we = probably should ask for a general "node properties" (or whatever better = name we can think of) top level TLV that could be applied to the general = constraint node information (connectivity matrices) as well as the = various resource related quantities. =20 >>=20 >> Pierre and Giovanni does this sound like a reasonable way forward? Or = do you have a different suggestion. Comments and suggestions from all = are welcome. >>=20 >> Best Regards >>=20 >> Greg B. >>=20 >> --=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 > --Apple-Mail-30-347385806 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Greg, 
I think it is better to get 1 or 2 new top-level TE TLVs = than to overload the TE Node Attribute TLV" with the optical = capabilities = information. 
Thanks,
Acee 
On = Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:

Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint:
    "The Node Attribute TLV MUST NOT appear in = more than one TE LSA originated by a router.  Furthermore, such = an LSA MUST NOT include more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:
=20 =20
Hi Greg,
 
To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.
 
Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information = organisation.
I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.
 
To detail my point of view, considering that = I bet you would = keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.
I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, = being a consistent bunch of OEO resources, sharing the fact = that updating the usage of one of them will have consequences on the accessibility of the others. = Which is to my mind the smallest information entity that will = need a single update on the modification of usage of one of its members, hence the most compliant with = scalability.
 
To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG = ?
 
- pierre
 
P.S. Let's keep aside right now the discussions concerning the administrative = group, and TE metric sub-TLVs.
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] = De la part de Greg Bernstein
Envoy=E9 : mardi 14 d=E9cembre 2010 19:24
=C0 : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and = General Constraint Extensions to OSPF (long)

Hi all two = weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  = We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of = the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the = LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This = LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
"The Link TLV describes a single link.  It is constructed = of a set of sub-TLVs.  There are no ordering requirements for = the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology."

There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).

For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more generally useful."
However in section 4.2 (Operation) they state:
"The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, = such an LSA MUST NOT include more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  = Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments = and suggestions from all are welcome.

Best Regards

Greg B.

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237




--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
= <ATT00001..txt>

= --Apple-Mail-30-347385806-- --Apple-Mail-31-347385821 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEwNjE3MjQ0MlowIwYJKoZI hvcNAQkEMRYEFFzOexHwUkSIAlmt5qE1tY7dl0fcMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDs6ufEixsTvXN3Yv8/uCJMVaszkGJDosGccaOZMOsZRE7WM7OcfxMMPehhhqkua jxP57stb5LCqDSyYxOvMbiCAYXRSbGYlw5k3Ts+UmF/jhQHBWM3bKbXW69rwirdw7at0HZwyUEi6 EYODreb+L9VOqGpJtbVM3zZPlU3+s12BAAAAAAAA --Apple-Mail-31-347385821-- From gregb@grotto-networking.com Thu Jan 6 10:15:19 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA523A6CED for ; Thu, 6 Jan 2011 10:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwfpy3ydWmQv for ; Thu, 6 Jan 2011 10:15:17 -0800 (PST) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id 2FCA83A6CD7 for ; Thu, 6 Jan 2011 10:15:17 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p06IHGaO017264; Thu, 6 Jan 2011 18:17:17 GMT Message-ID: <4D26072B.8040902@grotto-networking.com> Date: Thu, 06 Jan 2011 10:17:15 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Acee Lindem References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010901050507060804040102" X-CSC: 0 X-CHA: v=1.1 cv=p6LJilDI9yL6Te5GsYdCX7gUnVKLIZwbSeqBs+RSYhU= c=1 sm=1 a=_4VyIEzS4mEA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=IWGwN66EzPFECwj7Fb8A:9 a=P7J5IJtj6qdN6KxCS74A:7 a=U4-hBLe8ygq23iR6xzjv1nMDImoA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=lZB815dzVvQA:10 a=fwq8-P2W0jM00oG5:21 a=fgCXeKfJc3wu7wBx:21 a=0FD05c-RAAAA:8 a=gxZvrgisAAAA:8 a=bM6nUTjvsD2E0XukzVoA:9 a=1h40oNvwFI-ivFzo39gA:7 a=9mnMGAfiJDIkjzN7_57ZSgagDJ4A:4 a=f7GxY0FH8QIA:10 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:15:19 -0000 This is a multi-part message in MIME format. --------------010901050507060804040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks Acee. Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? What would be the justification for two new Top level TLVs for node related information? We've talked before about static versus dynamic information, but for link information we seemed to have settled on using multiple LSA instances for this purpose, i.e., keep the static stuff in LSA instances different from the dynamic stuff (e.g. wavelength availability). Hence I don't see the need for two top level TLVs. Greg On 1/6/2011 9:24 AM, Acee Lindem wrote: > Hi Greg, > I think it is better to get 1 or 2 new top-level TE TLVs than to > overload the TE Node Attribute TLV" with the optical capabilities > information. > Thanks, > Acee > On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: > >> Hi Pierre, do you think we should still try to use the "node >> attribute top level TLV" from RFC5786? A complete node description >> may require multiple connectivity matrices and these could >> potentially become large. RFC5786 has the constraint: >> "*/The Node Attribute TLV MUST NOT appear in more than one TE LSA >> originated by a router/*. Furthermore, such an LSA MUST NOT include >> more than one Node Attribute TLV." >> >> So we couldn't split them up for MTU purposes. It seems that one new >> top level TLV for a node without the RFC5786 constraints would >> suffice. Do you think we need two? How would we justify two new top >> level TLVs to the OSPF WG when we have the ability to use multiple >> instances? >> >> Other opinions? >> >> Best Regards >> >> Greg >> On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: >>> Hi Greg, >>> To start with, I am pretty in-line with the part related to the link >>> TLV, which was already agreed. >>> Regarding the node related information, I am happy to see that you >>> consider splitting its information over 2 top-level TLVs, which we >>> have been proning in order to ease the scalability and the >>> information organisation. >>> I do encourage you to adopt even more the concepts proned in >>> draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV >>> in a way that allows to have multiple instance of it, one for each >>> conistent entity of ressoruces. >>> To detail my point of view, considering that I bet you would keep >>> inside the node attribute top-level TLV the connectivity matrix >>> object, and transfer the informations concerning the OEO ressources >>> to the new top-level TLV that you suggest to name Node Property. I >>> have no hard convinctions on any name, and this one can fit with me, >>> it is not the important thing anyway. >>> I insist that, what seems more important to me is really to benefit >>> fully from the advantages brought by introducing a new top-level TLV >>> (which was apparently one of the thinks you were reluctant to do), >>> namely the capability to have one instance of this type per pool. >>> Here a pool, being a consistent bunch of OEO resources, sharing the >>> fact that updating the usage of one of them will have >>> consequences on the accessibility of the others. Which is to my mind >>> the smallest information entity that will need a single update on >>> the modification of usage of one of its members, hence the most >>> compliant with scalability. >>> To summarize, once the cost of introducing a new top-level TLV is >>> accepted, let's use the advantages of the concepts introduced in our >>> solution to their full extent, and then use a layout of information >>> compliant with that. Does this sems reasonnable for you, and for the >>> WG ? >>> - pierre >>> P.S. Let's keep aside right now the discussions concerning the >>> administrative group, and TE metric sub-TLVs. >>> ------------------------------------------------------------------------ >>> *De :* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *De la >>> part de* Greg Bernstein >>> *Envoyé :* mardi 14 décembre 2010 19:24 >>> *À :* CCAMP >>> *Objet :* [CCAMP] Top Level TLVs for WSON and General Constraint >>> Extensions to OSPF (long) >>> >>> Hi all two weeks ago we updated >>> draft-ietf-ccamp-general-constraint-encode and >>> draft-ietf-ccamp-rwa-wson-encode based on comments from the list >>> and the Beijing meeting. These changes were editorial in nature >>> and consisted of removing some informational text. >>> To move things forward in general we need to reach agreement on >>> the top level TLVs to be used to carry this information. We >>> have two main types of information: (a) link related, and (b) >>> node related. In addition, depending on the complexity of the >>> system we may want to split the information for a particular >>> node or link into multiple LSAs to keep the size of the LSA >>> below a particular limit or to separate rapidly changing node or >>> link information from relatively static. In general multiple TE >>> LSA instances provide a mechanism for this. >>> >>> *For Link information* *RFC3630* defines the "Traffic >>> Engineering LSA". This has area scope. >>> "One new LSA is defined, the Traffic Engineering LSA. This LSA >>> describes routers, point-to-point links, and connections to >>> multi-access networks (similar to a Router LSA)." >>> >>> Multiple instances can exist from a single source: >>> "The Instance field is an arbitrary value used to maintain >>> multiple Traffic Engineering LSAs. A maximum of 16777216 >>> Traffic Engineering LSAs may be sourced by a single system." >>> >>> Two top level TLVs are defined: Router Address TLV (section >>> 2.4.1) and Link TLV (section 2.4.2). The router address is just >>> as it says. The link TLV is the generally useful one for us: >>> "The Link TLV describes a single link. It is constructed of a >>> set of sub-TLVs. There are no ordering requirements for the >>> sub-TLVs. Only one Link TLV shall be carried in each LSA, >>> allowing for fine granularity changes in topology." >>> >>> There does not appear to be any constraints on breaking up >>> information about a single link into multiple LSAs. For WSON use >>> we may want to keep static information (port wavelength >>> constraints) separate from dynamic information (wavelength >>> availability). >>> >>> *For Node Level information* (such as connectivity matrices, >>> resource block information, resource block usage state) it >>> seemed like *RFC 5786* which has extensions for advertising a >>> routers local addresses in TE extensions would be useful. It >>> defines the OSPF TE LSA Node TLV and they state: >>> "It is anticipated that the Node Attribute TLV will also prove >>> more generally useful." >>> However in section 4.2 (Operation) they state: >>> "*/The Node Attribute TLV MUST NOT appear in more than one TE >>> LSA originated by a router/*. Furthermore, such an LSA MUST NOT >>> include more than one Node Attribute TLV." >>> >>> The first of these restrictions on use seems to preclude us from >>> separating traffic matrices, resource block descriptions, and >>> resource block utilization status into separate LSA instances >>> using this TLV. Unless this rule can be changed it seems that we >>> will need a new top level "node properties" TLV for use in both >>> WSON specific and General constraint extensions to OSPF. Pierre >>> and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted >>> to define a new top level TLV for the resource block >>> information, however it seems that we probably should ask for a >>> general "node properties" (or whatever better name we can think >>> of) top level TLV that could be applied to the general >>> constraint node information (connectivity matrices) as well as >>> the various resource related quantities. >>> >>> Pierre and Giovanni does this sound like a reasonable way >>> forward? Or do you have a different suggestion. Comments and >>> suggestions from all are welcome. >>> >>> Best Regards >>> >>> Greg B. >>> >>> -- >>> =================================================== >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>> >>> >> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------010901050507060804040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Acee. 
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two?  What would be the justification for two new Top level TLVs for node related information? 
We've talked before about static versus dynamic information, but for link information we seemed to have settled on using multiple LSA instances for this purpose, i.e., keep the static stuff in LSA instances different from the dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs. 

Greg


On 1/6/2011 9:24 AM, Acee Lindem wrote:
Hi Greg, 
I think it is better to get 1 or 2 new top-level TE TLVs than to overload the TE Node Attribute TLV" with the optical capabilities information. 
Thanks,
Acee 
On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:

Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint:
    "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:
Hi Greg,
 
To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.
 
Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information organisation.
I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.
 
To detail my point of view, considering that I bet you would keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.
I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, being a consistent bunch of OEO resources, sharing the fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind the smallest information entity that will need a single update on the modification of usage of one of its members, hence the most compliant with scalability.
 
To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG ?
 
- pierre
 
P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoyé : mardi 14 décembre 2010 19:24
À : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a set of sub-TLVs.  There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology."

There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).

For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more generally useful."
However in section 4.2 (Operation) they state:
"The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments and suggestions from all are welcome.

Best Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
<ATT00001..txt>



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------010901050507060804040102-- From pierre.peloso@alcatel-lucent.com Fri Jan 7 09:11:30 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F463A692B for ; Fri, 7 Jan 2011 09:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ZkEUaL756LON for ; Fri, 7 Jan 2011 09:11:16 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 900D43A6925 for ; Fri, 7 Jan 2011 09:11:13 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07HDDle026622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 18:13:15 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 7 Jan 2011 18:13:13 +0100 From: "PELOSO, PIERRE (PIERRE)" To: Greg Bernstein , Acee Lindem Date: Fri, 7 Jan 2011 18:13:12 +0100 Thread-Topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-Index: AcutzfdL/c2FcPZZTOGh/KqPGT7N9gAhrdwA Message-ID: References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> In-Reply-To: <4D26072B.8040902@grotto-networking.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CCBFBB7025DF984494DEC3285C0581521269FA5E69FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:11:31 -0000 --_000_CCBFBB7025DF984494DEC3285C0581521269FA5E69FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Acee and Every CCAMPers, My answer is definitively two, Acee mentions there is no issue implementing= one or two regarding OSPF, hence I really see no blocking point against tw= o new Top level TLV. On top of ensuring the split between static and dynamic information. It als= o provides an intrinsic structure of information organization. One type of LSA is structured around the connectivity constraints of the no= des. Another type of LSA is structured around the resources in the node. One ins= tance per ressource block. Hence one LSA of this type updated only at each = time. This feature is achieved with no extra-cost on the overall information to b= e conveyed, while the one to be updated is intrinsically placed in independ= ant LSA. To conclude I am all the more convinced that we need to benefit of the inhe= rent organization of information spread over multiple type of LSAs. It prov= ides an inherent solution to address static and dynamic information inside = nodes, which is altogether efficient regarding the amount of information to= be updated, while providing a clear layout of information for OSPF-TE. Pierre ________________________________ De : Greg Bernstein [mailto:gregb@grotto-networking.com] Envoy=E9 : jeudi 6 janvier 2011 19:17 =C0 : Acee Lindem Cc : PELOSO, PIERRE (PIERRE); CCAMP Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensio= ns to OSPF (long) Thanks Acee. Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? What= would be the justification for two new Top level TLVs for node related inf= ormation? We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability). Hence I don't see the need = for two top level TLVs. Greg On 1/6/2011 9:24 AM, Acee Lindem wrote: Hi Greg, I think it is better to get 1 or 2 new top-level TE TLVs than to overload t= he TE Node Attribute TLV" with the optical capabilities information. Thanks, Acee On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: Hi Pierre, do you think we should still try to use the "node attribute top = level TLV" from RFC5786? A complete node description may require multiple c= onnectivity matrices and these could potentially become large. RFC5786 has = the constraint: "The Node Attribute TLV MUST NOT appear in more than one TE LSA origina= ted by a router. Furthermore, such an LSA MUST NOT include more than one N= ode Attribute TLV." So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances? Other opinions? Best Regards Greg On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: Hi Greg, To start with, I am pretty in-line with the part related to the link TLV, w= hich was already agreed. Regarding the node related information, I am happy to see that you consider= splitting its information over 2 top-level TLVs, which we have been pronin= g in order to ease the scalability and the information organisation. I do encourage you to adopt even more the concepts proned in draft-peloso-c= camp-won-ospf-oeo, by defining this new top-level TLV in a way that allows = to have multiple instance of it, one for each conistent entity of ressoruce= s. To detail my point of view, considering that I bet you would keep inside th= e node attribute top-level TLV the connectivity matrix object, and transfer= the informations concerning the OEO ressources to the new top-level TLV th= at you suggest to name Node Property. I have no hard convinctions on any na= me, and this one can fit with me, it is not the important thing anyway. I insist that, what seems more important to me is really to benefit fully f= rom the advantages brought by introducing a new top-level TLV (which was ap= parently one of the thinks you were reluctant to do), namely the capability= to have one instance of this type per pool. Here a pool, being a consisten= t bunch of OEO resources, sharing the fact that updating the usage of one o= f them will have consequences on the accessibility of the others. Which is = to my mind the smallest information entity that will need a single update o= n the modification of usage of one of its members, hence the most compliant= with scalability. To summarize, once the cost of introducing a new top-level TLV is accepted,= let's use the advantages of the concepts introduced in our solution to the= ir full extent, and then use a layout of information compliant with that. D= oes this sems reasonnable for you, and for the WG ? - pierre P.S. Let's keep aside right now the discussions concerning the administrati= ve group, and TE metric sub-TLVs. ________________________________ De : ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] De la part de Greg Bernstein Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 =C0 : CCAMP Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions t= o OSPF (long) Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode = and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and th= e Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text. To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information. We have two main types of in= formation: (a) link related, and (b) node related. In addition, depending = on the complexity of the system we may want to split the information for a = particular node or link into multiple LSAs to keep the size of the LSA bel= ow a particular limit or to separate rapidly changing node or link informat= ion from relatively static. In general multiple TE LSA instances provide a = mechanism for this. For Link information RFC3630 defines the "Traffic Engineering LSA". This ha= s area scope. "One new LSA is defined, the Traffic Engineering LSA. This LSA describes r= outers, point-to-point links, and connections to multi-access networks (sim= ilar to a Router LSA)." Multiple instances can exist from a single source: "The Instance field is an arbitrary value used to maintain multiple Traffic= Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be s= ourced by a single system." Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us: "The Link TLV describes a single link. It is constructed of a set of sub-T= LVs. There are no ordering requirements for the sub-TLVs. Only one Link TL= V shall be carried in each LSA, allowing for fine granularity changes in to= pology." There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability). For Node Level information (such as connectivity matrices, resource block i= nformation, resource block usage state) it seemed like RFC 5786 which has e= xtensions for advertising a routers local addresses in TE extensions would = be useful. It defines the OSPF TE LSA Node TLV and they state: "It is anticipated that the Node Attribute TLV will also prove more general= ly useful." However in section 4.2 (Operation) they state: "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated = by a router. Furthermore, such an LSA MUST NOT include more than one Node = Attribute TLV." The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TL= V for use in both WSON specific and General constraint extensions to OSPF. = Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to d= efine a new top level TLV for the resource block information, however it se= ems that we probably should ask for a general "node properties" (or whateve= r better name we can think of) top level TLV that could be applied to the g= eneral constraint node information (connectivity matrices) as well as the v= arious resource related quantities. Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion. Comments and suggestions from all are welco= me. Best Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 --_000_CCBFBB7025DF984494DEC3285C0581521269FA5E69FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg, Acee and Every CCAMPers,
 
My answer is definitively two, Acee mentions there= is no=20 issue implementing one or two regarding OSPF, hence I really see no blockin= g=20 point against two new Top level TLV.
On top of ensuring the split between static and dy= namic=20 information. It also provides an intrinsic structure of information=20 organization.
One type of LSA is structured around the connectiv= ity=20 constraints of the nodes.
Another type of LSA is structured around the resou= rces in=20 the node. One instance per ressource block. Hence one LSA of this type upda= ted=20 only at each time.
This feature is achieved with no extra-cost on t= he=20 overall information to be conveyed, while the one to be updated is intrinsi= cally=20 placed in independant LSA.
<= FONT=20 color=3D#0000ff>To conclude= I=20 am all the more convinced that we need to benefit of the inh= erent=20 organization of information spread over multiple type of LSAs. It provides = an=20 inherent solution to address static and dynamic information inside nodes, w= hich=20 is altogether efficient regarding the amount of information to be updated, = while=20 providing a clear layout of information for=20 OSPF-TE.
 
Pierre

De : Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Envoy=E9 : jeudi 6 j= anvier=20 2011 19:17
=C0 : Acee Lindem
Cc : PELOSO, P= IERRE=20 (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSO= N and=20 General Constraint Extensions to OSPF (long)

Thanks Acee. 
Okay CCAMPers (Fatai and Pierre in=20 particular) do we need one or two?  What would be the justification = for=20 two new Top level TLVs for node related information? 
We've talk= ed=20 before about static versus dynamic information, but for link information = we=20 seemed to have settled on using multiple LSA instances for this purpose, = i.e.,=20 keep the static stuff in LSA instances different from the dynamic stuff (= e.g.=20 wavelength availability).  Hence I don't see the need for two top le= vel=20 TLVs. 

Greg


On 1/6/2011 9:24 AM, Acee Lindem wrot= e:=20
Hi Greg, =20
I think it is better to get 1 or 2 new top-level TE TLVs than to=20 overload the TE Node Attribute TLV" with the optical capabilities=20 information. 
Thanks,
Acee 
On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:
Hi Pierre, do you think we = should=20 still try to use the "node attribute top level TLV" from RFC5786? A=20 complete node description may require multiple connectivity matrices = and=20 these could potentially become large. RFC5786 has the constraint:=20
    "The Node Attribute TLV MUST NOT appear = in=20 more than one TE LSA originated by a router.  Furthermor= e,=20 such an LSA MUST NOT include more than one Node Attribute TLV."
<= BR>So=20 we couldn't split them up for MTU purposes. It seems that one new top= =20 level TLV for a node without the RFC5786 constraints would suffice. D= o you=20 think we need two? How would we justify two new top level TLVs to the= OSPF=20 WG when we have the ability to use multiple instances?

Other=20 opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM,= =20 PELOSO, PIERRE (PIERRE) wrote:=20
Hi Greg,
 
To start with, I am pretty in-line with th= e part=20 related to the link TLV, which was already agreed.
 = ;
Regarding the node related= =20 information, I am happy to see that you consider splitting its=20 information over 2 top-level TLVs, which we have been proning in or= der=20 to ease the scalability and the information=20 organisation.
I do encourage you to adop= t even more=20 the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining= this=20 new top-level TLV in a way that allows to have multiple instance of= it,=20 one for each conistent entity of ressoruces.
 = ;
To detail my point of view= ,=20 considering that I bet you would keep inside the node attribute top-l= evel=20 TLV the connectivity matrix object, and transfer the informations=20 concerning the OEO ressources to the new top-level TLV that you sug= gest=20 to name Node Property. I have no hard convinctions on any name, and= this=20 one can fit with me, it is not the important thing=20 anyway.
I insist that, what seems = more=20 important to me is really to benefit fully from the advantages brou= ght=20 by introducing a new top-level TLV (which was apparently one of the= =20 thinks you were reluctant to do), namely the capability to have one= =20 instance of this type per pool. Here a pool, being a=20 consistent bunch of OEO resources, sharing the fact that updat= ing=20 the usage of one of them will have consequences on the=20 accessibility of the others. Which is to my mind the smallest=20 information entity that will need a single update on the=20 modification of usage of one of its members, hence the most complia= nt=20 with scalability.
 
To summar= ize, once=20 the cost of introducing a new top-level TLV is accepted, let's use = the=20 advantages of the concepts introduced in our solution to their full= =20 extent, and then use a layout of information compliant with that. D= oes=20 this sems reasonnable for you, and for the WG=20 ?
 
- pierre
 
P.S. Let's keep aside right now the discussions conce= rning=20 the administrative group, and TE metric sub-TLVs.
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De l= a part=20 de Greg Bernstein
Envoy=E9 : mardi 14 d=E9cembre= 2010=20 19:24
=C0 : CCAMP
Objet : [CCAMP] Top= Level=20 TLVs for WSON and General Constraint Extensions to OSPF=20 (long)

Hi all two weeks = ago we=20 updated draft-ietf-ccamp-general-constraint-encode and=20 draft-ietf-ccamp-rwa-wson-encode based on comments from the list = and=20 the Beijing meeting. These changes were editorial in nature and=20 consisted of removing some informational text.
To move things= =20 forward in general we need to reach agreement on the top level TL= Vs to=20 be used to carry this information.  We have two main types o= f=20 information: (a) link related, and (b) node related.  In=20 addition, depending on the complexity of the system we may want t= o=20 split the information for a particular node or link into multiple= =20 LSAs  to keep the size of the LSA below a particular limit o= r to=20 separate rapidly changing node or link information from relativel= y=20 static. In general multiple TE LSA instances provide a mechanism = for=20 this.

For Link information RFC3630 defines t= he=20 "Traffic Engineering LSA". This has area scope.
"One new LSA i= s=20 defined, the Traffic Engineering LSA.  This LSA describes=20 routers, point-to-point links, and connections to multi-access=20 networks (similar to a Router LSA)."

Multiple instances ca= n=20 exist from a single source:
"The Instance field is an arbitrar= y=20 value used to maintain multiple Traffic Engineering LSAs.  A= =20 maximum of 16777216 Traffic Engineering LSAs may be sourced by a= =20 single system."

Two top level TLVs are defined: Router Add= ress=20 TLV (section 2.4.1) and Link TLV (section 2.4.2). The router addr= ess=20 is just as it says. The link TLV is the generally useful one for= =20 us:
"The Link TLV describes a single link.  It is constru= cted=20 of a set of sub-TLVs.  There are no ordering requirements fo= r the=20 sub-TLVs. Only one Link TLV shall be carried in each LSA, allowin= g for=20 fine granularity changes in topology."

There does not appe= ar to=20 be any constraints on breaking up information about a single link= into=20 multiple LSAs. For WSON use we may want to keep static informatio= n=20 (port wavelength constraints) separate from dynamic information=20 (wavelength availability).

For Node Level information=20 (such as connectivity matrices, resource block information, resou= rce=20 block usage state) it seemed like RFC 5786 which has exten= sions=20 for advertising a routers local addresses in TE extensions would = be=20 useful. It defines the OSPF TE LSA Node TLV and they state:
"I= t is=20 anticipated that the Node Attribute TLV will also prove more gene= rally=20 useful."
However in section 4.2 (Operation) they=20 state:
"The Node Attribute TLV MUST NOT appear in more t= han=20 one TE LSA originated by a router.  Furthermore, suc= h an=20 LSA MUST NOT include more than one Node Attribute TLV."

Th= e=20 first of these restrictions on use seems to preclude us from=20 separating traffic matrices, resource block descriptions, and res= ource=20 block utilization status into separate LSA instances using this T= LV.=20 Unless this rule can be changed it seems that we will need a new = top=20 level "node properties" TLV for use in both WSON specific and Gen= eral=20 constraint extensions to OSPF.  Pierre and Giovanni in=20 draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new to= p=20 level TLV for the resource block information, however it seems th= at we=20 probably should ask for a general "node properties" (or whatever= =20 better name we can think of) top level TLV that could be applied = to=20 the general constraint node information (connectivity matrices) a= s=20 well as the various resource related quantities. 

Pi= erre=20 and Giovanni does this sound like a reasonable way forward? Or do= you=20 have a different suggestion.  Comments and suggestions from = all=20 are welcome.

Best Regards

Greg B.

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237




--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
<ATT00001..txt>

= 

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--_000_CCBFBB7025DF984494DEC3285C0581521269FA5E69FRMRSSXCHMBSA_-- From leeyoung@huawei.com Fri Jan 7 11:24:57 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671853A6935 for ; Fri, 7 Jan 2011 11:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 EWyvw5sh-8cS for ; Fri, 7 Jan 2011 11:24:55 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 03C033A68EA for ; Fri, 7 Jan 2011 11:24:55 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEO00C5R3D0ES@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 07 Jan 2011 13:27:00 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LEO00JWV3CYBZ@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 07 Jan 2011 13:27:00 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 07 Jan 2011 11:26:51 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0218.012; Fri, 07 Jan 2011 11:26:57 -0800 Date: Fri, 07 Jan 2011 19:26:57 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.124.12.79] To: "PELOSO, PIERRE (PIERRE)" , Greg Bernstein , Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736A23A@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_S1DeVFsPbnk4jmuFgElabw)" Content-language: en-US Accept-Language: en-US Thread-topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-index: AcutxpxpyXylMEL5TQWoF72BtITcgQASmO2AADAN9AAADIBXMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> X-Mailman-Approved-At: Fri, 07 Jan 2011 11:32:11 -0800 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:30:18 -0000 --Boundary_(ID_S1DeVFsPbnk4jmuFgElabw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, Before we jump to discussing how many Top Level Node TLV we need for WSON i= mplementation, I have a question on the restriction of Node Attribute TLV n= ot allowing more than one TE LSA in RFC 5786. Greg quoted the following clause from RFC 5786, section 4.2 (Operation) in = his previous email: "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated = by a router. Furthermore, such an LSA MUST NOT include more than one Node = Attribute TLV." Can anyone explain the rational for this restriction? In addition, in what = context such an appeared-to-be unreasonable restriction have come along? It may be worth exploring lifting up this restriction as an alternative. Pe= rhaps the authors of RFC 5786 give us the original intent of this restricti= on. If there is a strong reason not to lift-up this restriction, I am fine with= exploring the thread of discussion on top level TLV issue. Thanks. Young ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of P= ELOSO, PIERRE (PIERRE) Sent: Friday, January 07, 2011 11:13 AM To: Greg Bernstein; Acee Lindem Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensi= ons to OSPF (long) Hi Greg, Acee and Every CCAMPers, My answer is definitively two, Acee mentions there is no issue implementing= one or two regarding OSPF, hence I really see no blocking point against tw= o new Top level TLV. On top of ensuring the split between static and dynamic information. It als= o provides an intrinsic structure of information organization. One type of LSA is structured around the connectivity constraints of the no= des. Another type of LSA is structured around the resources in the node. One ins= tance per ressource block. Hence one LSA of this type updated only at each = time. This feature is achieved with no extra-cost on the overall information to b= e conveyed, while the one to be updated is intrinsically placed in independ= ant LSA. To conclude I am all the more convinced that we need to benefit of the inhe= rent organization of information spread over multiple type of LSAs. It prov= ides an inherent solution to address static and dynamic information inside = nodes, which is altogether efficient regarding the amount of information to= be updated, while providing a clear layout of information for OSPF-TE. Pierre ________________________________ De : Greg Bernstein [mailto:gregb@grotto-networking.com] Envoy=E9 : jeudi 6 janvier 2011 19:17 =C0 : Acee Lindem Cc : PELOSO, PIERRE (PIERRE); CCAMP Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensio= ns to OSPF (long) Thanks Acee. Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? What= would be the justification for two new Top level TLVs for node related inf= ormation? We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability). Hence I don't see the need = for two top level TLVs. Greg On 1/6/2011 9:24 AM, Acee Lindem wrote: Hi Greg, I think it is better to get 1 or 2 new top-level TE TLVs than to overload t= he TE Node Attribute TLV" with the optical capabilities information. Thanks, Acee On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: Hi Pierre, do you think we should still try to use the "node attribute top = level TLV" from RFC5786? A complete node description may require multiple c= onnectivity matrices and these could potentially become large. RFC5786 has = the constraint: "The Node Attribute TLV MUST NOT appear in more than one TE LSA origina= ted by a router. Furthermore, such an LSA MUST NOT include more than one N= ode Attribute TLV." So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances? Other opinions? Best Regards Greg On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: Hi Greg, To start with, I am pretty in-line with the part related to the link TLV, w= hich was already agreed. Regarding the node related information, I am happy to see that you consider= splitting its information over 2 top-level TLVs, which we have been pronin= g in order to ease the scalability and the information organisation. I do encourage you to adopt even more the concepts proned in draft-peloso-c= camp-won-ospf-oeo, by defining this new top-level TLV in a way that allows = to have multiple instance of it, one for each conistent entity of ressoruce= s. To detail my point of view, considering that I bet you would keep inside th= e node attribute top-level TLV the connectivity matrix object, and transfer= the informations concerning the OEO ressources to the new top-level TLV th= at you suggest to name Node Property. I have no hard convinctions on any na= me, and this one can fit with me, it is not the important thing anyway. I insist that, what seems more important to me is really to benefit fully f= rom the advantages brought by introducing a new top-level TLV (which was ap= parently one of the thinks you were reluctant to do), namely the capability= to have one instance of this type per pool. Here a pool, being a consisten= t bunch of OEO resources, sharing the fact that updating the usage of one o= f them will have consequences on the accessibility of the others. Which is = to my mind the smallest information entity that will need a single update o= n the modification of usage of one of its members, hence the most compliant= with scalability. To summarize, once the cost of introducing a new top-level TLV is accepted,= let's use the advantages of the concepts introduced in our solution to the= ir full extent, and then use a layout of information compliant with that. D= oes this sems reasonnable for you, and for the WG ? - pierre P.S. Let's keep aside right now the discussions concerning the administrati= ve group, and TE metric sub-TLVs. ________________________________ De : ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] De la part de Greg Bernstein Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 =C0 : CCAMP Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions t= o OSPF (long) Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode = and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and th= e Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text. To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information. We have two main types of in= formation: (a) link related, and (b) node related. In addition, depending = on the complexity of the system we may want to split the information for a = particular node or link into multiple LSAs to keep the size of the LSA bel= ow a particular limit or to separate rapidly changing node or link informat= ion from relatively static. In general multiple TE LSA instances provide a = mechanism for this. For Link information RFC3630 defines the "Traffic Engineering LSA". This ha= s area scope. "One new LSA is defined, the Traffic Engineering LSA. This LSA describes r= outers, point-to-point links, and connections to multi-access networks (sim= ilar to a Router LSA)." Multiple instances can exist from a single source: "The Instance field is an arbitrary value used to maintain multiple Traffic= Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be s= ourced by a single system." Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us: "The Link TLV describes a single link. It is constructed of a set of sub-T= LVs. There are no ordering requirements for the sub-TLVs. Only one Link TL= V shall be carried in each LSA, allowing for fine granularity changes in to= pology." There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability). For Node Level information (such as connectivity matrices, resource block i= nformation, resource block usage state) it seemed like RFC 5786 which has e= xtensions for advertising a routers local addresses in TE extensions would = be useful. It defines the OSPF TE LSA Node TLV and they state: "It is anticipated that the Node Attribute TLV will also prove more general= ly useful." However in section 4.2 (Operation) they state: "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated = by a router. Furthermore, such an LSA MUST NOT include more than one Node = Attribute TLV." The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TL= V for use in both WSON specific and General constraint extensions to OSPF. = Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to d= efine a new top level TLV for the resource block information, however it se= ems that we probably should ask for a general "node properties" (or whateve= r better name we can think of) top level TLV that could be applied to the g= eneral constraint node information (connectivity matrices) as well as the v= arious resource related quantities. Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion. Comments and suggestions from all are welco= me. Best Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 --Boundary_(ID_S1DeVFsPbnk4jmuFgElabw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi,

 

Before we jump to discussing how man= y Top Level Node TLV we need for WSON implementation, I have a question on = the restriction of Node Attribute TLV not allowing more than one TE LSA in RFC 5786.

Greg quoted the following clause fro= m RFC 5786, section 4.2 (Operation) in his previous email:

 

"The Node Attribute TLV MUST NOT appear in more than one TE LSA orig= inated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV= ."

 

Can anyone explain the rational for = this restriction? In addition, in what context such an appeared-to-be unrea= sonable restriction have come along?

 

It may be worth exploring lifting up= this restriction as an alternative. Perhaps the authors of RFC 5786 give u= s the original intent of this restriction.

 

If there is a strong reason not to l= ift-up this restriction, I am fine with exploring the thread of discussion = on top level TLV issue.

Thanks.

 

Young

 

 

= From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: Friday, January 07, 20= 11 11:13 AM
To: Greg Bernstein; Acee Lin= dem
Cc: CCAMP
Subject: Re: [CCAMP] Top Lev= el TLVs for WSON and General Constraint Extensions to OSPF (long)

 

Hi Greg, Acee and Every CCAMPers,

 

My answer is definitively two, Acee me= ntions there is no issue implementing one or two regarding OSPF, hence I re= ally see no blocking point against two new Top level TLV.

On top of ensuring the split between s= tatic and dynamic information. It also provides an intrinsic structure of i= nformation organization.

One type of LSA is structured around t= he connectivity constraints of the nodes.

Another type of LSA is structured arou= nd the resources in the node. One instance per ressource block. Hence one L= SA of this type updated only at each time.

This feature is achieved with no extra= -cost on the overall information to be conveyed, while the one to be update= d is intrinsically placed in independant LSA.

To conclude I am all the more con= vinced that we need to benefit of the inherent organization of in= formation spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic in= formation inside nodes, which is altogether efficient regarding the amount = of information to be updated, while providing a clear layout of information= for OSPF-TE.

 

Pierre

 

De : Greg Bernstein [mailto:gregb@grotto-networking.com]
Envoy=E9 : jeudi 6 janv= ier 2011 19:17
=C0 : Acee Lindem
Cc : PELOSO, PIERRE (PI= ERRE); CCAMP
Objet : Re: [CCAMP] Top= Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Thanks Acee. 
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? = What would be the justification for two new Top level TLVs for node relate= d information? 
We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs.&nb= sp;

Greg


On 1/6/2011 9:24 AM, Acee Lindem wrote:

Hi Greg, 

I think it is better to get 1 or 2 n= ew top-level TE TLVs than to overload the TE Node Attribute TLV" with = the optical capabilities information. 

Thanks,

Acee <= /p>

On Jan 3, 2011, at 11:55 AM, Greg Be= rnstein wrote:



Hi Pierre, do you think we should st= ill try to use the "node attribute top level TLV" from RFC5786? A= complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constra= int:
    "The Node Attribute TLV MUST NOT appear in more than one TE LSA origi= nated by a router.  Furthermore, such an LSA MUST NOT i= nclude more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:

Hi Greg,

 

To start with, I am pretty in-line wit= h the part related to the link TLV, which was already agreed.=

 

Regard= ing the node related information, I am happy to see that you consider split= ting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the inform= ation organisation.

I do e= ncourage you to adopt even more the concepts proned in draft-peloso-ccamp-w= on-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each con= istent entity of ressoruces.

 

To det= ail my point of view, considering that I bet you would keep inside the= node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the= new top-level TLV that you suggest to name Node Property. I have no hard c= onvinctions on any name, and this one can fit with me, it is not the import= ant thing anyway.

I insi= st that, what seems more important to me is really to benefit fully from th= e advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), nam= ely the capability to have one instance of this type per pool. Here a = pool, being a consistent bunch of OEO resources, sharing the fact that= updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind = the smallest information entity that will need a single update on the = modification of usage of one of its members, hence the most compliant with = scalability.

 

To sum= marize, once the cost of introducing a new top-level TLV is accepted, let's= use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information= compliant with that. Does this sems reasonnable for you, and for the WG ?<= /span>

 

- pierre<= /span>

 

P.S. Let's keep aside right now t= he discussions concerning the administrative group, and TE metric sub-TLVs.=

De : ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein=
Envoy=E9 : mardi 14 d= =E9cembre 2010 19:24
=C0 : CCAMP
Objet : [CCAMP] Top Lev= el TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi all two weeks ago we updated draf= t-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode= based on comments from the list and the Beijing= meeting. These changes were editorial in nature and consisted of removing = some informational text.
To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information.  We have two main types = of information: (a) link related, and (b) node related.  In addition, = depending on the complexity of the system we may want to split the information for a particular node or link into mu= ltiple LSAs  to keep the size of the LSA below a particular limit or t= o separate rapidly changing node or link information from relatively static= . In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic E= ngineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA d= escribes routers, point-to-point links, and connections to multi-access net= works (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Tr= affic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSA= s may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a se= t of sub-TLVs.  There are no ordering requirements for the sub-TLVs. O= nly one Link TLV shall be carried in each LSA, allowing for fine granularit= y changes in topology."

There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability).

For Node Level information (= such as connectivity matrices, resource block information, resource block u= sage state) it seemed like RFC 5786 which has extension= s for advertising a routers local addresses in TE extensions would be usefu= l. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more ge= nerally useful."
However in section 4.2 (Operation) they state:
"The Node Att= ribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than on= e Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TLV for use in both WSON = specific and General constraint extensions to OSPF.  Pierre and Giovan= ni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top le= vel TLV for the resource block information, however it seems that we probably should ask for a general "node properties&q= uot; (or whatever better name we can think of) top level TLV that could be = applied to the general constraint node information (connectivity matrices) = as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion.  Comments and suggestions from all are = welcome.

Best Regards

Greg B.


-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

<ATT00001..txt>

 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
--Boundary_(ID_S1DeVFsPbnk4jmuFgElabw)-- From db3546@att.com Fri Jan 7 12:41:15 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6499C3A6958 for ; Fri, 7 Jan 2011 12:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ReaRzk92O-1X for ; Fri, 7 Jan 2011 12:41:14 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 5DEDA3A6947 for ; Fri, 7 Jan 2011 12:41:14 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-10.tower-167.messagelabs.com!1294432999!26376898!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31836 invoked from network); 7 Jan 2011 20:43:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jan 2011 20:43:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p07KgViX015426 for ; Fri, 7 Jan 2011 15:42:31 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p07KgNi1015323 for ; Fri, 7 Jan 2011 15:42:26 -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 Date: Fri, 7 Jan 2011 15:42:05 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closed - WG Last Call on draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt Thread-Index: AcudWvD5GWk3bU1rQNydPTsXcmhgqQRTqdUA References: From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Subject: [CCAMP] Closed - WG Last Call on draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:41:15 -0000 This Last Call has ended. I have one comment on section 1.1 to clarify the sentence on the use of the ADSPEC object (1st paragraph, last sentence): s/allocated/available Authors, please address the comments and remember to run nits before submitting an updated draft. Thanks, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Thursday, December 16, 2010 2:54 PM To: CCAMP Subject: [CCAMP] WG Last Call ondraft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt All, This is to start a three-week (extended for the holidays) working group last call on draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-00.txt. This working group last call ends Jan. 6. Please send your comments to the CCAMP mailing list. Deborah (and Lou) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri Jan 7 12:44:34 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4426A3A694F for ; Fri, 7 Jan 2011 12:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 2or4aU2+Fuov for ; Fri, 7 Jan 2011 12:44:33 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 3C7933A6945 for ; Fri, 7 Jan 2011 12:44:33 -0800 (PST) Received: (qmail 18795 invoked by uid 0); 7 Jan 2011 20:46:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 7 Jan 2011 20:46:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Hrg/O6JttTp3K9CBd2lq1by0X2HbLQYTQ9iSuGEXkNfU5sBtw3W9uRtJmJRVkaHg6YZFi4zinEIXesHs/kuGON/cotbNmH+INEzLvZnGttL3rxG3D12zrv4BixLXbBQr; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PbJCo-0008LS-Ji; Fri, 07 Jan 2011 13:46:38 -0700 Message-ID: <4D277BB9.80708@labn.net> Date: Fri, 07 Jan 2011 15:46:49 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: PWE3 Subject: [CCAMP] Fwd: New Version Notification for draft-ietf-ccamp-mpls-tp-cp-framework-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:44:34 -0000 FYI -- This update has been made to address issues raised by the (other) CCAMP WG chair as part of the normal post WG Last Call process. The changes fix a couple of nits, and add some clarifications on when GMPLS protocols are used and when PW protocols are used. Lou (as document co-editor) -------- Original Message -------- Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-cp-framework-05 Date: Fri, 7 Jan 2011 12:35:54 -0800 (PST) From: IETF I-D Submission Tool To: lberger@labn.net CC: loa.andersson@ericsson.com,lufang@cisco.com,nabil.n.bitar@verizon.com,Eric.Gray@Ericsson.com,attila.takacs@ericsson.com,martin.vigoureux@alcatel-lucent.fr,elisa.bellagamba@ericsson.com A new version of I-D, draft-ietf-ccamp-mpls-tp-cp-framework-05.txt has been successfully submitted by Lou Berger and posted to the IETF repository. Filename: draft-ietf-ccamp-mpls-tp-cp-framework Revision: 05 Title: MPLS-TP Control Plane Framework Creation_date: 2011-01-07 WG ID: ccamp Number_of_pages: 54 Abstract: The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] The IETF Secretariat. From Internet-Drafts@ietf.org Fri Jan 7 12:45:04 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D418C3A6958; Fri, 7 Jan 2011 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 C3yPhNB52jMD; Fri, 7 Jan 2011 12:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5683A695A; Fri, 7 Jan 2011 12:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107204502.9474.63837.idtracker@localhost> Date: Fri, 07 Jan 2011 12:45:02 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:45:04 -0000 --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 : MPLS-TP Control Plane Framework Author(s) : L. Andersson, et al. Filename : draft-ietf-ccamp-mpls-tp-cp-framework-05.txt Pages : 54 Date : 2011-01-07 The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-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-mpls-tp-cp-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07123552.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sun Jan 9 12:45:07 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35313A684F; Sun, 9 Jan 2011 12:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 KUOajzJqXHRD; Sun, 9 Jan 2011 12:45:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40AC3A6845; Sun, 9 Jan 2011 12:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110109204501.2215.82864.idtracker@localhost> Date: Sun, 09 Jan 2011 12:45:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:45:07 -0000 --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 : Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE Author(s) : E. Bellagamba, et al. Filename : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-04.txt Pages : 19 Date : 2011-01-09 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a common set of TLVs that can be carried on RSVP-TE protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-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-rsvp-te-mpls-tp-oam-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-09124136.I-D@ietf.org> --NextPart-- From zhangfatai@huawei.com Sun Jan 9 17:56:59 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DD428C0D9 for ; Sun, 9 Jan 2011 17:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=1.996, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 12G1QVOSCvTR for ; Sun, 9 Jan 2011 17:56:57 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 48C7128C0E5 for ; Sun, 9 Jan 2011 17:56:56 -0800 (PST) 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 <0LES00L5XATVTY@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 09:58:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LES00JUYATVYO@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 09:58:43 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LES00LU3ATTCR@szxml06-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 09:58:43 +0800 (CST) Date: Mon, 10 Jan 2011 09:58:41 +0800 From: Fatai Zhang To: "PELOSO, PIERRE (PIERRE)" , Greg Bernstein , Acee Lindem Message-id: <745A5455E5D14361B3311D49116C8976@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_FIWtEYhB1lUmY93r8ZMbXg)" X-Priority: 3 X-MSMail-priority: Normal References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:56:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FIWtEYhB1lUmY93r8ZMbXg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgUGllcnJlIGFuZCBHcmVnLA0KDQpJIG5lZWQgdG8gcmVtaW5kIHlvdSBib3RoIHRoYXQgW09T UEYtR2VuXSAoImRyYWZ0LXpoYW5nLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi1leHQt MDAudHh0IikgaXMgZ2VuZXJhbCAobm90IHNwZWNpZmljIHRvIFdTT04pLiANCg0KIkNvbm5lY3Rp dml0eSBNYXRyaXgiIGRlZmluZWQgaW4gW09TUEYtR2VuXSBpcyBhIGtpbmQgb2Ygbm9kZSBhdHRy aWJ1dGUsIGFuZCBpdCBpcyBzdGF0aWMgbGlrZSAiSVB2NC92NiBMb2NhbCBBZGRyZXNzIiBkZWZp bmVkIGluIFJGQzU3ODYsIHNvIHdlIGNhbiByZXN1ZSAiTm9kZSBBdHRyaWJ1dGUiIHRvcCBUTFYg dG8gYWR2ZXJ0aXNlIENvbm5lY3Rpdml0eSBNYXRyaXggaW5mb3JtYXRpb24gd2l0aG91dCBicmVh a2luZyB0aGUgZXhpc3RpbmcgcnVsZXMvcmVzdHJpY3Rpb25zIGRlZmluZWQgaW4gUkZDNTc4Ni4N Cg0KRm9yIFdTT04gc3BlY2lmaWMgaW5mb3JtYXRpb24oaWUuLCBPRU8gc3R1ZmYpLCBJIHRoaW5r IHdlIHNob3VsZCBkZWZpbmUgYSBuZXcgdG9wIFRMViBpbiBvcmRlciB0byBjb21wbHkgd2l0aCB0 aGUgcnVsZXMgZGVmaW5lZCBpbiBSRkM1Nzg2IChvciB3ZSBtYXkgIGxpZmUtdXAgdGhpcyByZXN0 cmljdGlvbiBkZWZpbmVkIGluIFJGQzU3ODYgYXMgWW91bmcgc3VnZ2VzdGVkKS4NCg0KDQoNCg0K VGhhbmtzDQogDQpGYXRhaQ0KIA0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIExURC4NCkh1YXdl aSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywNClNoZW56aGVuIDUxODEyOSBQLlIuQ2hpbmENClRl bDogKzg2LTc1NS0yODk3MjkxMg0KRmF4OiArODYtNzU1LTI4OTcyOTM1DQoNCiAgLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogUEVMT1NPLCBQSUVSUkUgKFBJRVJSRSkgDQog IFRvOiBHcmVnIEJlcm5zdGVpbiA7IEFjZWUgTGluZGVtIA0KICBDYzogQ0NBTVAgDQogIFNlbnQ6 IFNhdHVyZGF5LCBKYW51YXJ5IDA4LCAyMDExIDE6MTMgQU0NCiAgU3ViamVjdDogUmU6IFtDQ0FN UF0gVG9wIExldmVsIFRMVnMgZm9yIFdTT04gYW5kIEdlbmVyYWwgQ29uc3RyYWludCBFeHRlbnNp b25zIHRvIE9TUEYgKGxvbmcpDQoNCg0KICBIaSBHcmVnLCBBY2VlIGFuZCBFdmVyeSBDQ0FNUGVy cywNCg0KICBNeSBhbnN3ZXIgaXMgZGVmaW5pdGl2ZWx5IHR3bywgQWNlZSBtZW50aW9ucyB0aGVy ZSBpcyBubyBpc3N1ZSBpbXBsZW1lbnRpbmcgb25lIG9yIHR3byByZWdhcmRpbmcgT1NQRiwgaGVu Y2UgSSByZWFsbHkgc2VlIG5vIGJsb2NraW5nIHBvaW50IGFnYWluc3QgdHdvIG5ldyBUb3AgbGV2 ZWwgVExWLg0KICBPbiB0b3Agb2YgZW5zdXJpbmcgdGhlIHNwbGl0IGJldHdlZW4gc3RhdGljIGFu ZCBkeW5hbWljIGluZm9ybWF0aW9uLiBJdCBhbHNvIHByb3ZpZGVzIGFuIGludHJpbnNpYyBzdHJ1 Y3R1cmUgb2YgaW5mb3JtYXRpb24gb3JnYW5pemF0aW9uLg0KICBPbmUgdHlwZSBvZiBMU0EgaXMg c3RydWN0dXJlZCBhcm91bmQgdGhlIGNvbm5lY3Rpdml0eSBjb25zdHJhaW50cyBvZiB0aGUgbm9k ZXMuDQogIEFub3RoZXIgdHlwZSBvZiBMU0EgaXMgc3RydWN0dXJlZCBhcm91bmQgdGhlIHJlc291 cmNlcyBpbiB0aGUgbm9kZS4gT25lIGluc3RhbmNlIHBlciByZXNzb3VyY2UgYmxvY2suIEhlbmNl IG9uZSBMU0Egb2YgdGhpcyB0eXBlIHVwZGF0ZWQgb25seSBhdCBlYWNoIHRpbWUuDQogIFRoaXMg ZmVhdHVyZSBpcyBhY2hpZXZlZCB3aXRoIG5vIGV4dHJhLWNvc3Qgb24gdGhlIG92ZXJhbGwgaW5m b3JtYXRpb24gdG8gYmUgY29udmV5ZWQsIHdoaWxlIHRoZSBvbmUgdG8gYmUgdXBkYXRlZCBpcyBp bnRyaW5zaWNhbGx5IHBsYWNlZCBpbiBpbmRlcGVuZGFudCBMU0EuDQogIFRvIGNvbmNsdWRlIEkg YW0gYWxsIHRoZSBtb3JlIGNvbnZpbmNlZCB0aGF0IHdlIG5lZWQgdG8gYmVuZWZpdCBvZiB0aGUg aW5oZXJlbnQgb3JnYW5pemF0aW9uIG9mIGluZm9ybWF0aW9uIHNwcmVhZCBvdmVyIG11bHRpcGxl IHR5cGUgb2YgTFNBcy4gSXQgcHJvdmlkZXMgYW4gaW5oZXJlbnQgc29sdXRpb24gdG8gYWRkcmVz cyBzdGF0aWMgYW5kIGR5bmFtaWMgaW5mb3JtYXRpb24gaW5zaWRlIG5vZGVzLCB3aGljaCBpcyBh bHRvZ2V0aGVyIGVmZmljaWVudCByZWdhcmRpbmcgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0 byBiZSB1cGRhdGVkLCB3aGlsZSBwcm92aWRpbmcgYSBjbGVhciBsYXlvdXQgb2YgaW5mb3JtYXRp b24gZm9yIE9TUEYtVEUuDQoNCiAgUGllcnJlDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgRGUgOiBHcmVnIEJlcm5zdGVpbiBbbWFpbHRvOmdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNv bV0gDQogICAgRW52b3npIDogamV1ZGkgNiBqYW52aWVyIDIwMTEgMTk6MTcNCiAgICDAIDogQWNl ZSBMaW5kZW0NCiAgICBDYyA6IFBFTE9TTywgUElFUlJFIChQSUVSUkUpOyBDQ0FNUA0KICAgIE9i amV0IDogUmU6IFtDQ0FNUF0gVG9wIExldmVsIFRMVnMgZm9yIFdTT04gYW5kIEdlbmVyYWwgQ29u c3RyYWludCBFeHRlbnNpb25zIHRvIE9TUEYgKGxvbmcpDQoNCg0KICAgIFRoYW5rcyBBY2VlLiAg DQogICAgT2theSBDQ0FNUGVycyAoRmF0YWkgYW5kIFBpZXJyZSBpbiBwYXJ0aWN1bGFyKSBkbyB3 ZSBuZWVkIG9uZSBvciB0d28/ICBXaGF0IHdvdWxkIGJlIHRoZSBqdXN0aWZpY2F0aW9uIGZvciB0 d28gbmV3IFRvcCBsZXZlbCBUTFZzIGZvciBub2RlIHJlbGF0ZWQgaW5mb3JtYXRpb24/ICANCiAg ICBXZSd2ZSB0YWxrZWQgYmVmb3JlIGFib3V0IHN0YXRpYyB2ZXJzdXMgZHluYW1pYyBpbmZvcm1h dGlvbiwgYnV0IGZvciBsaW5rIGluZm9ybWF0aW9uIHdlIHNlZW1lZCB0byBoYXZlIHNldHRsZWQg b24gdXNpbmcgbXVsdGlwbGUgTFNBIGluc3RhbmNlcyBmb3IgdGhpcyBwdXJwb3NlLCBpLmUuLCBr ZWVwIHRoZSBzdGF0aWMgc3R1ZmYgaW4gTFNBIGluc3RhbmNlcyBkaWZmZXJlbnQgZnJvbSB0aGUg ZHluYW1pYyBzdHVmZiAoZS5nLiB3YXZlbGVuZ3RoIGF2YWlsYWJpbGl0eSkuICBIZW5jZSBJIGRv bid0IHNlZSB0aGUgbmVlZCBmb3IgdHdvIHRvcCBsZXZlbCBUTFZzLiAgDQoNCiAgICBHcmVnDQoN Cg0KICAgIE9uIDEvNi8yMDExIDk6MjQgQU0sIEFjZWUgTGluZGVtIHdyb3RlOiANCiAgICAgIEhp IEdyZWcsICANCiAgICAgIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGdldCAxIG9yIDIgbmV3IHRv cC1sZXZlbCBURSBUTFZzIHRoYW4gdG8gb3ZlcmxvYWQgdGhlIFRFIE5vZGUgQXR0cmlidXRlIFRM ViIgd2l0aCB0aGUgb3B0aWNhbCBjYXBhYmlsaXRpZXMgaW5mb3JtYXRpb24uIA0KICAgICAgVGhh bmtzLA0KICAgICAgQWNlZSANCg0KICAgICAgT24gSmFuIDMsIDIwMTEsIGF0IDExOjU1IEFNLCBH cmVnIEJlcm5zdGVpbiB3cm90ZToNCg0KDQogICAgICAgIEhpIFBpZXJyZSwgZG8geW91IHRoaW5r IHdlIHNob3VsZCBzdGlsbCB0cnkgdG8gdXNlIHRoZSAibm9kZSBhdHRyaWJ1dGUgdG9wIGxldmVs IFRMViIgZnJvbSBSRkM1Nzg2PyBBIGNvbXBsZXRlIG5vZGUgZGVzY3JpcHRpb24gbWF5IHJlcXVp cmUgbXVsdGlwbGUgY29ubmVjdGl2aXR5IG1hdHJpY2VzIGFuZCB0aGVzZSBjb3VsZCBwb3RlbnRp YWxseSBiZWNvbWUgbGFyZ2UuIFJGQzU3ODYgaGFzIHRoZSBjb25zdHJhaW50OiANCiAgICAgICAg ICAgICJUaGUgTm9kZSBBdHRyaWJ1dGUgVExWIE1VU1QgTk9UIGFwcGVhciBpbiBtb3JlIHRoYW4g b25lIFRFIExTQSBvcmlnaW5hdGVkIGJ5IGEgcm91dGVyLiAgRnVydGhlcm1vcmUsIHN1Y2ggYW4g TFNBIE1VU1QgTk9UIGluY2x1ZGUgbW9yZSB0aGFuIG9uZSBOb2RlIEF0dHJpYnV0ZSBUTFYuIiAN Cg0KICAgICAgICBTbyB3ZSBjb3VsZG4ndCBzcGxpdCB0aGVtIHVwIGZvciBNVFUgcHVycG9zZXMu IEl0IHNlZW1zIHRoYXQgb25lIG5ldyB0b3AgbGV2ZWwgVExWIGZvciBhIG5vZGUgd2l0aG91dCB0 aGUgUkZDNTc4NiBjb25zdHJhaW50cyB3b3VsZCBzdWZmaWNlLiBEbyB5b3UgdGhpbmsgd2UgbmVl ZCB0d28/IEhvdyB3b3VsZCB3ZSBqdXN0aWZ5IHR3byBuZXcgdG9wIGxldmVsIFRMVnMgdG8gdGhl IE9TUEYgV0cgd2hlbiB3ZSBoYXZlIHRoZSBhYmlsaXR5IHRvIHVzZSBtdWx0aXBsZSBpbnN0YW5j ZXM/DQoNCiAgICAgICAgT3RoZXIgb3BpbmlvbnM/DQoNCiAgICAgICAgQmVzdCBSZWdhcmRzDQoN CiAgICAgICAgR3JlZyANCiAgICAgICAgT24gMTIvMjAvMjAxMCA0OjI3IEFNLCBQRUxPU08sIFBJ RVJSRSAoUElFUlJFKSB3cm90ZTogDQogICAgICAgICAgSGkgR3JlZywNCg0KICAgICAgICAgIFRv IHN0YXJ0IHdpdGgsIEkgYW0gcHJldHR5IGluLWxpbmUgd2l0aCB0aGUgcGFydCByZWxhdGVkIHRv IHRoZSBsaW5rIFRMViwgd2hpY2ggd2FzIGFscmVhZHkgYWdyZWVkLg0KDQogICAgICAgICAgUmVn YXJkaW5nIHRoZSBub2RlIHJlbGF0ZWQgaW5mb3JtYXRpb24sIEkgYW0gaGFwcHkgdG8gc2VlIHRo YXQgeW91IGNvbnNpZGVyIHNwbGl0dGluZyBpdHMgaW5mb3JtYXRpb24gb3ZlciAyIHRvcC1sZXZl bCBUTFZzLCB3aGljaCB3ZSBoYXZlIGJlZW4gcHJvbmluZyBpbiBvcmRlciB0byBlYXNlIHRoZSBz Y2FsYWJpbGl0eSBhbmQgdGhlIGluZm9ybWF0aW9uIG9yZ2FuaXNhdGlvbi4NCiAgICAgICAgICBJ IGRvIGVuY291cmFnZSB5b3UgdG8gYWRvcHQgZXZlbiBtb3JlIHRoZSBjb25jZXB0cyBwcm9uZWQg aW4gZHJhZnQtcGVsb3NvLWNjYW1wLXdvbi1vc3BmLW9lbywgYnkgZGVmaW5pbmcgdGhpcyBuZXcg dG9wLWxldmVsIFRMViBpbiBhIHdheSB0aGF0IGFsbG93cyB0byBoYXZlIG11bHRpcGxlIGluc3Rh bmNlIG9mIGl0LCBvbmUgZm9yIGVhY2ggY29uaXN0ZW50IGVudGl0eSBvZiByZXNzb3J1Y2VzLg0K DQogICAgICAgICAgVG8gZGV0YWlsIG15IHBvaW50IG9mIHZpZXcsIGNvbnNpZGVyaW5nIHRoYXQg SSBiZXQgeW91IHdvdWxkIGtlZXAgaW5zaWRlIHRoZSBub2RlIGF0dHJpYnV0ZSB0b3AtbGV2ZWwg VExWIHRoZSBjb25uZWN0aXZpdHkgbWF0cml4IG9iamVjdCwgYW5kIHRyYW5zZmVyIHRoZSBpbmZv cm1hdGlvbnMgY29uY2VybmluZyB0aGUgT0VPIHJlc3NvdXJjZXMgdG8gdGhlIG5ldyB0b3AtbGV2 ZWwgVExWIHRoYXQgeW91IHN1Z2dlc3QgdG8gbmFtZSBOb2RlIFByb3BlcnR5LiBJIGhhdmUgbm8g aGFyZCBjb252aW5jdGlvbnMgb24gYW55IG5hbWUsIGFuZCB0aGlzIG9uZSBjYW4gZml0IHdpdGgg bWUsIGl0IGlzIG5vdCB0aGUgaW1wb3J0YW50IHRoaW5nIGFueXdheS4NCiAgICAgICAgICBJIGlu c2lzdCB0aGF0LCB3aGF0IHNlZW1zIG1vcmUgaW1wb3J0YW50IHRvIG1lIGlzIHJlYWxseSB0byBi ZW5lZml0IGZ1bGx5IGZyb20gdGhlIGFkdmFudGFnZXMgYnJvdWdodCBieSBpbnRyb2R1Y2luZyBh IG5ldyB0b3AtbGV2ZWwgVExWICh3aGljaCB3YXMgYXBwYXJlbnRseSBvbmUgb2YgdGhlIHRoaW5r cyB5b3Ugd2VyZSByZWx1Y3RhbnQgdG8gZG8pLCBuYW1lbHkgdGhlIGNhcGFiaWxpdHkgdG8gaGF2 ZSBvbmUgaW5zdGFuY2Ugb2YgdGhpcyB0eXBlIHBlciBwb29sLiBIZXJlIGEgcG9vbCwgYmVpbmcg YSBjb25zaXN0ZW50IGJ1bmNoIG9mIE9FTyByZXNvdXJjZXMsIHNoYXJpbmcgdGhlIGZhY3QgdGhh dCB1cGRhdGluZyB0aGUgdXNhZ2Ugb2Ygb25lIG9mIHRoZW0gd2lsbCBoYXZlIGNvbnNlcXVlbmNl cyBvbiB0aGUgYWNjZXNzaWJpbGl0eSBvZiB0aGUgb3RoZXJzLiBXaGljaCBpcyB0byBteSBtaW5k IHRoZSBzbWFsbGVzdCBpbmZvcm1hdGlvbiBlbnRpdHkgdGhhdCB3aWxsIG5lZWQgYSBzaW5nbGUg dXBkYXRlIG9uIHRoZSBtb2RpZmljYXRpb24gb2YgdXNhZ2Ugb2Ygb25lIG9mIGl0cyBtZW1iZXJz LCBoZW5jZSB0aGUgbW9zdCBjb21wbGlhbnQgd2l0aCBzY2FsYWJpbGl0eS4NCg0KICAgICAgICAg IFRvIHN1bW1hcml6ZSwgb25jZSB0aGUgY29zdCBvZiBpbnRyb2R1Y2luZyBhIG5ldyB0b3AtbGV2 ZWwgVExWIGlzIGFjY2VwdGVkLCBsZXQncyB1c2UgdGhlIGFkdmFudGFnZXMgb2YgdGhlIGNvbmNl cHRzIGludHJvZHVjZWQgaW4gb3VyIHNvbHV0aW9uIHRvIHRoZWlyIGZ1bGwgZXh0ZW50LCBhbmQg dGhlbiB1c2UgYSBsYXlvdXQgb2YgaW5mb3JtYXRpb24gY29tcGxpYW50IHdpdGggdGhhdC4gRG9l cyB0aGlzIHNlbXMgcmVhc29ubmFibGUgZm9yIHlvdSwgYW5kIGZvciB0aGUgV0cgPw0KDQogICAg ICAgICAgLSBwaWVycmUNCg0KICAgICAgICAgIFAuUy4gTGV0J3Mga2VlcCBhc2lkZSByaWdodCBu b3cgdGhlIGRpc2N1c3Npb25zIGNvbmNlcm5pbmcgdGhlIGFkbWluaXN0cmF0aXZlIGdyb3VwLCBh bmQgVEUgbWV0cmljIHN1Yi1UTFZzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAgICAgICBEZSA6 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIEdyZWcgQmVybnN0ZWluDQogICAgICAgICAgRW52b3npIDogbWFyZGkgMTQg ZOljZW1icmUgMjAxMCAxOToyNA0KICAgICAgICAgIMAgOiBDQ0FNUA0KICAgICAgICAgIE9iamV0 IDogW0NDQU1QXSBUb3AgTGV2ZWwgVExWcyBmb3IgV1NPTiBhbmQgR2VuZXJhbCBDb25zdHJhaW50 IEV4dGVuc2lvbnMgdG8gT1NQRiAobG9uZykNCg0KDQogICAgICAgICAgICBIaSBhbGwgdHdvIHdl ZWtzIGFnbyB3ZSB1cGRhdGVkIGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVu Y29kZSBhbmQgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUgYmFzZWQgb24gY29tbWVu dHMgZnJvbSB0aGUgbGlzdCBhbmQgdGhlIEJlaWppbmcgbWVldGluZy4gVGhlc2UgY2hhbmdlcyB3 ZXJlIGVkaXRvcmlhbCBpbiBuYXR1cmUgYW5kIGNvbnNpc3RlZCBvZiByZW1vdmluZyBzb21lIGlu Zm9ybWF0aW9uYWwgdGV4dC4gDQogICAgICAgICAgICBUbyBtb3ZlIHRoaW5ncyBmb3J3YXJkIGlu IGdlbmVyYWwgd2UgbmVlZCB0byByZWFjaCBhZ3JlZW1lbnQgb24gdGhlIHRvcCBsZXZlbCBUTFZz IHRvIGJlIHVzZWQgdG8gY2FycnkgdGhpcyBpbmZvcm1hdGlvbi4gIFdlIGhhdmUgdHdvIG1haW4g dHlwZXMgb2YgaW5mb3JtYXRpb246IChhKSBsaW5rIHJlbGF0ZWQsIGFuZCAoYikgbm9kZSByZWxh dGVkLiAgSW4gYWRkaXRpb24sIGRlcGVuZGluZyBvbiB0aGUgY29tcGxleGl0eSBvZiB0aGUgc3lz dGVtIHdlIG1heSB3YW50IHRvIHNwbGl0IHRoZSBpbmZvcm1hdGlvbiBmb3IgYSBwYXJ0aWN1bGFy IG5vZGUgb3IgbGluayBpbnRvIG11bHRpcGxlIExTQXMgIHRvIGtlZXAgdGhlIHNpemUgb2YgdGhl IExTQSBiZWxvdyBhIHBhcnRpY3VsYXIgbGltaXQgb3IgdG8gc2VwYXJhdGUgcmFwaWRseSBjaGFu Z2luZyBub2RlIG9yIGxpbmsgaW5mb3JtYXRpb24gZnJvbSByZWxhdGl2ZWx5IHN0YXRpYy4gSW4g Z2VuZXJhbCBtdWx0aXBsZSBURSBMU0EgaW5zdGFuY2VzIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9y IHRoaXMuDQoNCiAgICAgICAgICAgIEZvciBMaW5rIGluZm9ybWF0aW9uIFJGQzM2MzAgZGVmaW5l cyB0aGUgIlRyYWZmaWMgRW5naW5lZXJpbmcgTFNBIi4gVGhpcyBoYXMgYXJlYSBzY29wZS4NCiAg ICAgICAgICAgICJPbmUgbmV3IExTQSBpcyBkZWZpbmVkLCB0aGUgVHJhZmZpYyBFbmdpbmVlcmlu ZyBMU0EuICBUaGlzIExTQSBkZXNjcmliZXMgcm91dGVycywgcG9pbnQtdG8tcG9pbnQgbGlua3Ms IGFuZCBjb25uZWN0aW9ucyB0byBtdWx0aS1hY2Nlc3MgbmV0d29ya3MgKHNpbWlsYXIgdG8gYSBS b3V0ZXIgTFNBKS4iDQoNCiAgICAgICAgICAgIE11bHRpcGxlIGluc3RhbmNlcyBjYW4gZXhpc3Qg ZnJvbSBhIHNpbmdsZSBzb3VyY2U6DQogICAgICAgICAgICAiVGhlIEluc3RhbmNlIGZpZWxkIGlz IGFuIGFyYml0cmFyeSB2YWx1ZSB1c2VkIHRvIG1haW50YWluIG11bHRpcGxlIFRyYWZmaWMgRW5n aW5lZXJpbmcgTFNBcy4gIEEgbWF4aW11bSBvZiAxNjc3NzIxNiBUcmFmZmljIEVuZ2luZWVyaW5n IExTQXMgbWF5IGJlIHNvdXJjZWQgYnkgYSBzaW5nbGUgc3lzdGVtLiINCg0KICAgICAgICAgICAg VHdvIHRvcCBsZXZlbCBUTFZzIGFyZSBkZWZpbmVkOiBSb3V0ZXIgQWRkcmVzcyBUTFYgKHNlY3Rp b24gMi40LjEpIGFuZCBMaW5rIFRMViAoc2VjdGlvbiAyLjQuMikuIFRoZSByb3V0ZXIgYWRkcmVz cyBpcyBqdXN0IGFzIGl0IHNheXMuIFRoZSBsaW5rIFRMViBpcyB0aGUgZ2VuZXJhbGx5IHVzZWZ1 bCBvbmUgZm9yIHVzOg0KICAgICAgICAgICAgIlRoZSBMaW5rIFRMViBkZXNjcmliZXMgYSBzaW5n bGUgbGluay4gIEl0IGlzIGNvbnN0cnVjdGVkIG9mIGEgc2V0IG9mIHN1Yi1UTFZzLiAgVGhlcmUg YXJlIG5vIG9yZGVyaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlIHN1Yi1UTFZzLiBPbmx5IG9uZSBM aW5rIFRMViBzaGFsbCBiZSBjYXJyaWVkIGluIGVhY2ggTFNBLCBhbGxvd2luZyBmb3IgZmluZSBn cmFudWxhcml0eSBjaGFuZ2VzIGluIHRvcG9sb2d5LiINCg0KICAgICAgICAgICAgVGhlcmUgZG9l cyBub3QgYXBwZWFyIHRvIGJlIGFueSBjb25zdHJhaW50cyBvbiBicmVha2luZyB1cCBpbmZvcm1h dGlvbiBhYm91dCBhIHNpbmdsZSBsaW5rIGludG8gbXVsdGlwbGUgTFNBcy4gRm9yIFdTT04gdXNl IHdlIG1heSB3YW50IHRvIGtlZXAgc3RhdGljIGluZm9ybWF0aW9uIChwb3J0IHdhdmVsZW5ndGgg Y29uc3RyYWludHMpIHNlcGFyYXRlIGZyb20gZHluYW1pYyBpbmZvcm1hdGlvbiAod2F2ZWxlbmd0 aCBhdmFpbGFiaWxpdHkpLg0KDQogICAgICAgICAgICBGb3IgTm9kZSBMZXZlbCBpbmZvcm1hdGlv biAoc3VjaCBhcyBjb25uZWN0aXZpdHkgbWF0cmljZXMsIHJlc291cmNlIGJsb2NrIGluZm9ybWF0 aW9uLCByZXNvdXJjZSBibG9jayB1c2FnZSBzdGF0ZSkgaXQgc2VlbWVkIGxpa2UgUkZDIDU3ODYg d2hpY2ggaGFzIGV4dGVuc2lvbnMgZm9yIGFkdmVydGlzaW5nIGEgcm91dGVycyBsb2NhbCBhZGRy ZXNzZXMgaW4gVEUgZXh0ZW5zaW9ucyB3b3VsZCBiZSB1c2VmdWwuIEl0IGRlZmluZXMgdGhlIE9T UEYgVEUgTFNBIE5vZGUgVExWIGFuZCB0aGV5IHN0YXRlOg0KICAgICAgICAgICAgIkl0IGlzIGFu dGljaXBhdGVkIHRoYXQgdGhlIE5vZGUgQXR0cmlidXRlIFRMViB3aWxsIGFsc28gcHJvdmUgbW9y ZSBnZW5lcmFsbHkgdXNlZnVsLiINCiAgICAgICAgICAgIEhvd2V2ZXIgaW4gc2VjdGlvbiA0LjIg KE9wZXJhdGlvbikgdGhleSBzdGF0ZToNCiAgICAgICAgICAgICJUaGUgTm9kZSBBdHRyaWJ1dGUg VExWIE1VU1QgTk9UIGFwcGVhciBpbiBtb3JlIHRoYW4gb25lIFRFIExTQSBvcmlnaW5hdGVkIGJ5 IGEgcm91dGVyLiAgRnVydGhlcm1vcmUsIHN1Y2ggYW4gTFNBIE1VU1QgTk9UIGluY2x1ZGUgbW9y ZSB0aGFuIG9uZSBOb2RlIEF0dHJpYnV0ZSBUTFYuIg0KDQogICAgICAgICAgICBUaGUgZmlyc3Qg b2YgdGhlc2UgcmVzdHJpY3Rpb25zIG9uIHVzZSBzZWVtcyB0byBwcmVjbHVkZSB1cyBmcm9tIHNl cGFyYXRpbmcgdHJhZmZpYyBtYXRyaWNlcywgcmVzb3VyY2UgYmxvY2sgZGVzY3JpcHRpb25zLCBh bmQgcmVzb3VyY2UgYmxvY2sgdXRpbGl6YXRpb24gc3RhdHVzIGludG8gc2VwYXJhdGUgTFNBIGlu c3RhbmNlcyB1c2luZyB0aGlzIFRMVi4gVW5sZXNzIHRoaXMgcnVsZSBjYW4gYmUgY2hhbmdlZCBp dCBzZWVtcyB0aGF0IHdlIHdpbGwgbmVlZCBhIG5ldyB0b3AgbGV2ZWwgIm5vZGUgcHJvcGVydGll cyIgVExWIGZvciB1c2UgaW4gYm90aCBXU09OIHNwZWNpZmljIGFuZCBHZW5lcmFsIGNvbnN0cmFp bnQgZXh0ZW5zaW9ucyB0byBPU1BGLiAgUGllcnJlIGFuZCBHaW92YW5uaSBpbiBkcmFmdC1wZWxv c28tY2NhbXAtd3Nvbi1vc3BmLW9lby0wMi50eHQgd2FudGVkIHRvIGRlZmluZSBhIG5ldyB0b3Ag bGV2ZWwgVExWIGZvciB0aGUgcmVzb3VyY2UgYmxvY2sgaW5mb3JtYXRpb24sIGhvd2V2ZXIgaXQg c2VlbXMgdGhhdCB3ZSBwcm9iYWJseSBzaG91bGQgYXNrIGZvciBhIGdlbmVyYWwgIm5vZGUgcHJv cGVydGllcyIgKG9yIHdoYXRldmVyIGJldHRlciBuYW1lIHdlIGNhbiB0aGluayBvZikgdG9wIGxl dmVsIFRMViB0aGF0IGNvdWxkIGJlIGFwcGxpZWQgdG8gdGhlIGdlbmVyYWwgY29uc3RyYWludCBu b2RlIGluZm9ybWF0aW9uIChjb25uZWN0aXZpdHkgbWF0cmljZXMpIGFzIHdlbGwgYXMgdGhlIHZh cmlvdXMgcmVzb3VyY2UgcmVsYXRlZCBxdWFudGl0aWVzLiAgDQoNCiAgICAgICAgICAgIFBpZXJy ZSBhbmQgR2lvdmFubmkgZG9lcyB0aGlzIHNvdW5kIGxpa2UgYSByZWFzb25hYmxlIHdheSBmb3J3 YXJkPyBPciBkbyB5b3UgaGF2ZSBhIGRpZmZlcmVudCBzdWdnZXN0aW9uLiAgQ29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGZyb20gYWxsIGFyZSB3ZWxjb21lLg0KDQogICAgICAgICAgICBCZXN0IFJl Z2FyZHMNCg0KICAgICAgICAgICAgR3JlZyBCLg0KDQoNCi0tIA0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEciBHcmVnIEJlcm5zdGVpbiwgR3Jv dHRvIE5ldHdvcmtpbmcgKDUxMCkgNTczLTIyMzcNCg0KDQoNCg0KLS0gDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRyIEdyZWcgQmVybnN0ZWlu LCBHcm90dG8gTmV0d29ya2luZyAoNTEwKSA1NzMtMjIzNw0KDQo8QVRUMDAwMDEuLnR4dD4NCg0K DQoNCg0KDQotLSANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KRHIgR3JlZyBCZXJuc3RlaW4sIEdyb3R0byBOZXR3b3JraW5nICg1MTApIDU3My0y MjM3DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogIENDQU1QIG1haWxpbmcgbGlzdA0KICBD Q0FNUEBpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wDQo= --Boundary_(ID_FIWtEYhB1lUmY93r8ZMbXg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC42MDM2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT1D YWxpYnJpIGNvbG9yPSMwMDAwODA+SGkgUGllcnJlIGFuZCBHcmVnLDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4MD5JIG5lZWQgdG8gcmVtaW5kIHlv dSBib3RoIHRoYXQgW09TUEYtR2VuXSANCigiZHJhZnQtemhhbmctY2NhbXAtZ2VuZXJhbC1jb25z dHJhaW50cy1vc3BmLWV4dC0wMC50eHQiKSBpcyBnZW5lcmFsIChub3QgDQpzcGVjaWZpYyB0byBX U09OKS4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4 MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAw MDgwPiJDb25uZWN0aXZpdHkgTWF0cml4IiBkZWZpbmVkIGluIA0KW09TUEYtR2VuXSBpcyBhIGtp bmQgb2Ygbm9kZSBhdHRyaWJ1dGUsIGFuZCBpdCBpcyBzdGF0aWMgbGlrZSAiSVB2NC92NiBMb2Nh bCANCkFkZHJlc3MiIGRlZmluZWQgaW4gUkZDNTc4Niwgc28gd2UgY2FuIHJlc3VlICJOb2RlIEF0 dHJpYnV0ZSIgdG9wIFRMViB0byANCmFkdmVydGlzZSBDb25uZWN0aXZpdHkgTWF0cml4IGluZm9y bWF0aW9uIHdpdGhvdXQgYnJlYWtpbmcgdGhlIGV4aXN0aW5nIA0KcnVsZXMvcmVzdHJpY3Rpb25z IGRlZmluZWQgaW4gUkZDNTc4Ni48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJy aSBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1DYWxp YnJpIGNvbG9yPSMwMDAwODA+Rm9yIFdTT04gc3BlY2lmaWMgaW5mb3JtYXRpb24oaWUuLCBPRU8g DQpzdHVmZiksIEkgdGhpbmsgd2Ugc2hvdWxkIGRlZmluZSBhIG5ldyB0b3AgVExWIGluIG9yZGVy IHRvIGNvbXBseSB3aXRoIHRoZSBydWxlcyANCmRlZmluZWQgaW4gUkZDNTc4NiAob3Igd2UmbmJz cDttYXkgJm5ic3A7bGlmZS11cCB0aGlzIHJlc3RyaWN0aW9uIGRlZmluZWQgaW4gDQpSRkM1Nzg2 IGFzIFlvdW5nIHN1Z2dlc3RlZCkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGli cmkgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2Fs aWJyaSBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1D YWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUNhbGlicmkgY29sb3I9IzAwMDA4MD48L0ZPTlQ+PEZPTlQgZmFjZT1DYWxpYnJpIA0KY29sb3I9 IzAwMDA4MD48L0ZPTlQ+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPjxC Uj48Rk9OVCANCmZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgwPlRoYW5rczxCUj4mbmJzcDs8QlI+ RmF0YWk8QlI+Jm5ic3A7PEJSPkh1YXdlaSANClRlY2hub2xvZ2llcyBDby4sIExURC48QlI+SHVh d2VpIEJhc2UsIEJhbnRpYW4sIExvbmdnYW5nLDxCUj5TaGVuemhlbiA1MTgxMjkgDQpQLlIuQ2hp bmE8QlI+VGVsOiArODYtNzU1LTI4OTcyOTEyPEJSPkZheDogKzg2LTc1NS0yODk3MjkzNTxCUj48 L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDA4MCAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxE SVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1waWVycmUucGVs b3NvQGFsY2F0ZWwtbHVjZW50LmNvbSANCiAgaHJlZj0ibWFpbHRvOnBpZXJyZS5wZWxvc29AYWxj YXRlbC1sdWNlbnQuY29tIj5QRUxPU08sIFBJRVJSRSAoUElFUlJFKTwvQT4gDQogIDwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0 aXRsZT1ncmVnYkBncm90dG8tbmV0d29ya2luZy5jb20gDQogIGhyZWY9Im1haWx0bzpncmVnYkBn cm90dG8tbmV0d29ya2luZy5jb20iPkdyZWcgQmVybnN0ZWluPC9BPiA7IDxBIA0KICB0aXRsZT1h Y2VlLmxpbmRlbUBlcmljc3Nvbi5jb20gaHJlZj0ibWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29u LmNvbSI+QWNlZSANCiAgTGluZGVtPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9Y2NhbXBAaWV0Zi5vcmcgDQog IGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Q0NBTVA8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFNhdHVyZGF5LCBK YW51YXJ5IDA4LCAyMDExIDE6MTMgDQpBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbQ0NBTVBdIFRvcCBMZXZlbCBU TFZzIGZvciBXU09OIA0KICBhbmQgR2VuZXJhbCBDb25zdHJhaW50IEV4dGVuc2lvbnMgdG8gT1NQ RiAobG9uZyk8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTI2MzQ0MjExMC0wNzAxMjAxMT48Rk9OVCBmYWNlPUFyaWFsIA0KICBj b2xvcj0jMDAwMGZmIHNpemU9Mj5IaSBHcmVnLCBBY2VlIGFuZCBFdmVyeSBDQ0FNUGVycyw8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0y NjM0NDIxMTAtMDcwMTIwMTE+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9MjYzNDQyMTEwLTA3MDEyMDExPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPk15IGFuc3dlciBpcyBkZWZpbml0aXZlbHkgdHdvLCBBY2VlIG1lbnRp b25zIHRoZXJlIGlzIG5vIA0KICBpc3N1ZSBpbXBsZW1lbnRpbmcgb25lIG9yIHR3byByZWdhcmRp bmcgT1NQRiwgaGVuY2UgSSByZWFsbHkgc2VlIG5vIGJsb2NraW5nIA0KICBwb2ludCBhZ2FpbnN0 IHR3byBuZXcgVG9wIGxldmVsIFRMVi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yNjM0NDIxMTAtMDcwMTIwMTE+PEZPTlQgZmFjZT1B cmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+T24gdG9wIG9mIGVuc3VyaW5nIHRoZSBzcGxp dCBiZXR3ZWVuIHN0YXRpYyBhbmQgZHluYW1pYyANCiAgaW5mb3JtYXRpb24uIEl0IGFsc28gcHJv dmlkZXMgYW4gaW50cmluc2ljIHN0cnVjdHVyZSBvZiBpbmZvcm1hdGlvbiANCiAgb3JnYW5pemF0 aW9uLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTI2MzQ0MjExMC0wNzAxMjAxMT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAw MGZmIHNpemU9Mj5PbmUgdHlwZSBvZiBMU0EgaXMgc3RydWN0dXJlZCBhcm91bmQgdGhlIGNvbm5l Y3Rpdml0eSANCiAgY29uc3RyYWludHMgb2YgdGhlIG5vZGVzLjwvRk9OVD48L1NQQU4+PC9ESVY+ DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTI2MzQ0MjExMC0wNzAxMjAx MT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5Bbm90aGVyIHR5cGUg b2YgTFNBIGlzIHN0cnVjdHVyZWQgYXJvdW5kIHRoZSByZXNvdXJjZXMgaW4gDQogIHRoZSBub2Rl LiBPbmUgaW5zdGFuY2UgcGVyIHJlc3NvdXJjZSBibG9jay4gSGVuY2Ugb25lIExTQSBvZiB0aGlz IHR5cGUgdXBkYXRlZCANCiAgb25seSBhdCBlYWNoIHRpbWUuPC9GT05UPjwvU1BBTj48L0RJVj48 U1BBTiBjbGFzcz0yNjM0NDIxMTAtMDcwMTIwMTE+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj48U1BBTiBjbGFzcz0yNjM0NDIxMTAtMDcwMTIw MTE+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29s b3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTI2MzQ0MjExMC0wNzAxMjAx MT5UaGlzIGZlYXR1cmUgaXMgYWNoaWV2ZWQgd2l0aCBubyANCiAgZXh0cmEtY29zdCBvbiB0aGUg b3ZlcmFsbCBpbmZvcm1hdGlvbiB0byBiZSBjb252ZXllZCwgd2hpbGUgdGhlIG9uZSB0byBiZSAN CiAgdXBkYXRlZCBpcyBpbnRyaW5zaWNhbGx5IHBsYWNlZCBpbiBpbmRlcGVuZGFudCANCiAgTFNB LjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICBzaXpl PTI+PFNQQU4gY2xhc3M9MjYzNDQyMTEwLTA3MDEyMDExPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv Rk9OVD48Rk9OVCANCiAgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9 Mj48U1BBTiBjbGFzcz0yNjM0NDIxMTAtMDcwMTIwMTE+VG8gDQogIGNvbmNsdWRlIEkgYW0mbmJz cDthbGwgdGhlIG1vcmUgY29udmluY2VkIHRoYXQgd2UgbmVlZCB0byZuYnNwO2JlbmVmaXQgb2Yg DQogIHRoZSZuYnNwO2luaGVyZW50IG9yZ2FuaXphdGlvbiBvZiBpbmZvcm1hdGlvbiBzcHJlYWQg b3ZlciBtdWx0aXBsZSB0eXBlIG9mIA0KICBMU0FzLiBJdCBwcm92aWRlcyBhbiBpbmhlcmVudCBz b2x1dGlvbiB0byBhZGRyZXNzIHN0YXRpYyBhbmQgZHluYW1pYyANCiAgaW5mb3JtYXRpb24gaW5z aWRlIG5vZGVzLCB3aGljaCBpcyBhbHRvZ2V0aGVyIGVmZmljaWVudCByZWdhcmRpbmcgdGhlIGFt b3VudCANCiAgb2YgaW5mb3JtYXRpb24gdG8gYmUgdXBkYXRlZCwgd2hpbGUgcHJvdmlkaW5nIGEg Y2xlYXIgbGF5b3V0IG9mIGluZm9ybWF0aW9uIA0KICBmb3IgT1NQRi1URS48L1NQQU4+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZh Y2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0yPjxTUEFOIA0KICBj bGFzcz0yNjM0NDIxMTAtMDcwMTIwMTE+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTI2MzQ0MjExMC0wNzAxMjAxMT5QaWVycmU8 L1NQQU4+PC9GT05UPjwvRElWPjxCUj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFS R0lOLVJJR0hUOiAwcHgiPg0KICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFu Zz1mciBkaXI9bHRyIGFsaWduPWxlZnQ+DQogICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05U IGZhY2U9VGFob21hIHNpemU9Mj48Qj5EZSZuYnNwOzo8L0I+IEdyZWcgQmVybnN0ZWluIA0KICAg IFttYWlsdG86Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tXSA8QlI+PEI+RW52b3npJm5ic3A7 OjwvQj4gamV1ZGkgNiANCiAgICBqYW52aWVyIDIwMTEgMTk6MTc8QlI+PEI+wCZuYnNwOzo8L0I+ IEFjZWUgTGluZGVtPEJSPjxCPkNjJm5ic3A7OjwvQj4gDQogICAgUEVMT1NPLCBQSUVSUkUgKFBJ RVJSRSk7IENDQU1QPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gUmU6IFtDQ0FNUF0gVG9wIExldmVs IA0KICAgIFRMVnMgZm9yIFdTT04gYW5kIEdlbmVyYWwgQ29uc3RyYWludCBFeHRlbnNpb25zIHRv IE9TUEYgDQogICAgKGxvbmcpPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogICAgPERJVj48L0RJVj5U aGFua3MgQWNlZS4mbmJzcDsgPEJSPk9rYXkgQ0NBTVBlcnMgKEZhdGFpIGFuZCBQaWVycmUgaW4g DQogICAgcGFydGljdWxhcikgZG8gd2UgbmVlZCBvbmUgb3IgdHdvPyZuYnNwOyBXaGF0IHdvdWxk IGJlIHRoZSBqdXN0aWZpY2F0aW9uIGZvciANCiAgICB0d28gbmV3IFRvcCBsZXZlbCBUTFZzIGZv ciBub2RlIHJlbGF0ZWQgaW5mb3JtYXRpb24/Jm5ic3A7IDxCUj5XZSd2ZSB0YWxrZWQgDQogICAg YmVmb3JlIGFib3V0IHN0YXRpYyB2ZXJzdXMgZHluYW1pYyBpbmZvcm1hdGlvbiwgYnV0IGZvciBs aW5rIGluZm9ybWF0aW9uIHdlIA0KICAgIHNlZW1lZCB0byBoYXZlIHNldHRsZWQgb24gdXNpbmcg bXVsdGlwbGUgTFNBIGluc3RhbmNlcyBmb3IgdGhpcyBwdXJwb3NlLCANCiAgICBpLmUuLCBrZWVw IHRoZSBzdGF0aWMgc3R1ZmYgaW4gTFNBIGluc3RhbmNlcyBkaWZmZXJlbnQgZnJvbSB0aGUgZHlu YW1pYyANCiAgICBzdHVmZiAoZS5nLiB3YXZlbGVuZ3RoIGF2YWlsYWJpbGl0eSkuJm5ic3A7IEhl bmNlIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkIGZvciANCiAgICB0d28gdG9wIGxldmVsIFRMVnMuJm5i c3A7IDxCUj48QlI+R3JlZzxCUj48QlI+PEJSPk9uIDEvNi8yMDExIDk6MjQgQU0sIEFjZWUgDQog ICAgTGluZGVtIHdyb3RlOiANCiAgICA8QkxPQ0tRVU9URSBjaXRlPW1pZDpGMEJCNzRBOS0wOEZD LTQ3NTEtQTcyQy0xODk5QTBDNzNDOUFAZXJpY3Nzb24uY29tIA0KICAgIHR5cGU9ImNpdGUiPkhp IEdyZWcsJm5ic3A7IA0KICAgICAgPERJVj5JIHRoaW5rIGl0IGlzIGJldHRlciB0byBnZXQgMSBv ciAyIG5ldyB0b3AtbGV2ZWwgVEUgVExWcyB0aGFuIHRvIA0KICAgICAgb3ZlcmxvYWQgdGhlIFRF IE5vZGUgQXR0cmlidXRlIFRMViIgd2l0aCB0aGUgb3B0aWNhbCBjYXBhYmlsaXRpZXMgDQogICAg ICBpbmZvcm1hdGlvbi4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+VGhhbmtzLDwvRElWPg0KICAg ICAgPERJVj5BY2VlJm5ic3A7PEJSPg0KICAgICAgPERJVj4NCiAgICAgIDxESVY+T24gSmFuIDMs IDIwMTEsIGF0IDExOjU1IEFNLCBHcmVnIEJlcm5zdGVpbiB3cm90ZTo8L0RJVj48QlIgDQogICAg ICBjbGFzcz1BcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lPg0KICAgICAgPEJMT0NLUVVPVEUgdHlw ZT0iY2l0ZSI+DQogICAgICAgIDxESVYgYmdjb2xvcj0iI2ZmZmZmZiIgdGV4dD0iIzAwMDAwMCI+ SGkgUGllcnJlLCBkbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIA0KICAgICAgICBzdGlsbCB0cnkgdG8g dXNlIHRoZSAibm9kZSBhdHRyaWJ1dGUgdG9wIGxldmVsIFRMViIgZnJvbSBSRkM1Nzg2PyBBIA0K ICAgICAgICBjb21wbGV0ZSBub2RlIGRlc2NyaXB0aW9uIG1heSByZXF1aXJlIG11bHRpcGxlIGNv bm5lY3Rpdml0eSBtYXRyaWNlcyBhbmQgDQogICAgICAgIHRoZXNlIGNvdWxkIHBvdGVudGlhbGx5 IGJlY29tZSBsYXJnZS4gUkZDNTc4NiBoYXMgdGhlIGNvbnN0cmFpbnQ6IA0KICAgICAgICA8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICI8Qj48ST5UaGUgTm9kZSBBdHRyaWJ1dGUgVExWIE1VU1QgTk9U IGFwcGVhciBpbiANCiAgICAgICAgbW9yZSB0aGFuIG9uZSBURSBMU0Egb3JpZ2luYXRlZCBieSBh IHJvdXRlcjwvST48L0I+LiZuYnNwOyBGdXJ0aGVybW9yZSwgDQogICAgICAgIHN1Y2ggYW4gTFNB IE1VU1QgTk9UIGluY2x1ZGUgbW9yZSB0aGFuIG9uZSBOb2RlIEF0dHJpYnV0ZSBUTFYuIiANCiAg ICAgICAgPEJSPjxCUj5TbyB3ZSBjb3VsZG4ndCBzcGxpdCB0aGVtIHVwIGZvciBNVFUgcHVycG9z ZXMuIEl0IHNlZW1zIHRoYXQgb25lIA0KICAgICAgICBuZXcgdG9wIGxldmVsIFRMViBmb3IgYSBu b2RlIHdpdGhvdXQgdGhlIFJGQzU3ODYgY29uc3RyYWludHMgd291bGQgDQogICAgICAgIHN1ZmZp Y2UuIERvIHlvdSB0aGluayB3ZSBuZWVkIHR3bz8gSG93IHdvdWxkIHdlIGp1c3RpZnkgdHdvIG5l dyB0b3AgDQogICAgICAgIGxldmVsIFRMVnMgdG8gdGhlIE9TUEYgV0cgd2hlbiB3ZSBoYXZlIHRo ZSBhYmlsaXR5IHRvIHVzZSBtdWx0aXBsZSANCiAgICAgICAgaW5zdGFuY2VzPzxCUj48QlI+T3Ro ZXIgb3BpbmlvbnM/PEJSPjxCUj5CZXN0IFJlZ2FyZHM8QlI+PEJSPkdyZWcgPEJSPk9uIA0KICAg ICAgICAxMi8yMC8yMDEwIDQ6MjcgQU0sIFBFTE9TTywgUElFUlJFIChQSUVSUkUpIHdyb3RlOiAN CiAgICAgICAgPEJMT0NLUVVPVEUgDQogICAgICAgIGNpdGU9bWlkOkNDQkZCQjcwMjVERjk4NDQ5 NERFQzMyODVDMDU4MTUyMTI2OUVEMTFEOUBGUk1SU1NYQ0hNQlNBMS5kYy1tLmFsY2F0ZWwtbHVj ZW50LmNvbSANCiAgICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgPERJViBkaXI9bHRyIGFs aWduPWxlZnQ+PFNQQU4gY2xhc3M9NzM2MjgwOTEwLTIwMTIyMDEwPjxGT05UIA0KICAgICAgICAg IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+SGkgR3JlZyw8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgICAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIA0KICAgICAgICAg IGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICAgICAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzM2MjgwOTEwLTIwMTIyMDEwPjxG T05UIA0KICAgICAgICAgIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+VG8gc3RhcnQg d2l0aCwgSSBhbSBwcmV0dHkgaW4tbGluZSANCiAgICAgICAgICB3aXRoIHRoZSBwYXJ0IHJlbGF0 ZWQgdG8gdGhlIGxpbmsgVExWLCB3aGljaCB3YXMgYWxyZWFkeSANCiAgICAgICAgICBhZ3JlZWQu PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz03MzYyODA5MTAtMjAxMjIwMTA+PEZPTlQgDQogICAgICAgICAgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBsYW5nPUZSPjwvU1BBTj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48Rk9OVCANCiAgICAgICAgICBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGxhbmc9RlI+UmVnYXJkaW5nIHRoZSBu b2RlIA0KICAgICAgICAgIHJlbGF0ZWQgaW5mb3JtYXRpb24sIEkgYW0gaGFwcHkgdG8gc2VlIHRo YXQgeW91IGNvbnNpZGVyIHNwbGl0dGluZyBpdHMgDQogICAgICAgICAgaW5mb3JtYXRpb24gb3Zl ciAyIHRvcC1sZXZlbCBUTFZzLCB3aGljaCB3ZSBoYXZlIGJlZW4gcHJvbmluZyBpbiBvcmRlciAN CiAgICAgICAgICB0byBlYXNlIHRoZSBzY2FsYWJpbGl0eSBhbmQgdGhlIGluZm9ybWF0aW9uIA0K ICAgICAgICAgIG9yZ2FuaXNhdGlvbi48L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAg ICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03MzYyODA5MTAtMjAxMjIw MTA+PEZPTlQgDQogICAgICAgICAgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBsYW5nPUZSPkkgZG8gZW5jb3VyYWdlIHlvdSB0byANCiAgICAgICAgICBhZG9wdCBldmVuIG1v cmUgdGhlIGNvbmNlcHRzIHByb25lZCBpbiANCiAgICAgICAgICBkcmFmdC1wZWxvc28tY2NhbXAt d29uLW9zcGYtb2VvLCBieSBkZWZpbmluZyB0aGlzIG5ldyB0b3AtbGV2ZWwgVExWIGluIA0KICAg ICAgICAgIGEgd2F5IHRoYXQgYWxsb3dzIHRvIGhhdmUgbXVsdGlwbGUgaW5zdGFuY2Ugb2YgaXQs IG9uZSBmb3IgZWFjaCANCiAgICAgICAgICBjb25pc3RlbnQgZW50aXR5IG9mIHJlc3NvcnVjZXMu PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICAgICAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9NzM2MjgwOTEwLTIwMTIyMDEwPjxGT05UIA0KICAgICAgICAgIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogICAgICAgICAgbGFuZz1GUj48 L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgICAgICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz03MzYyODA5MTAtMjAxMjIwMTA+PEZPTlQgDQogICAgICAg ICAgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBsYW5nPUZSPlRvIGRldGFp bCBteSBwb2ludCBvZiANCiAgICAgICAgICB2aWV3LCBjb25zaWRlcmluZyB0aGF0IDwvU1BBTj48 L0ZPTlQ+PC9TUEFOPjxTUEFOIA0KICAgICAgICAgIGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgICAgIGxh bmc9RlI+SSZuYnNwO2JldCB5b3Ugd291bGQga2VlcCBpbnNpZGUgdGhlIG5vZGUgYXR0cmlidXRl IHRvcC1sZXZlbCANCiAgICAgICAgICBUTFYgdGhlIGNvbm5lY3Rpdml0eSBtYXRyaXggb2JqZWN0 LCBhbmQgdHJhbnNmZXIgdGhlIGluZm9ybWF0aW9ucyANCiAgICAgICAgICBjb25jZXJuaW5nIHRo ZSBPRU8gcmVzc291cmNlcyB0byB0aGUgbmV3IHRvcC1sZXZlbCBUTFYgdGhhdCB5b3UgDQogICAg ICAgICAgc3VnZ2VzdCB0byBuYW1lIE5vZGUgUHJvcGVydHkuIEkgaGF2ZSBubyBoYXJkIGNvbnZp bmN0aW9ucyBvbiBhbnkgDQogICAgICAgICAgbmFtZSwgYW5kIHRoaXMgb25lIGNhbiBmaXQgd2l0 aCBtZSwgaXQgaXMgbm90IHRoZSBpbXBvcnRhbnQgdGhpbmcgDQogICAgICAgICAgYW55d2F5Ljwv U1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48Rk9OVCANCiAgICAgICAgICBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGxhbmc9RlI+SSBpbnNpc3QgdGhhdCwg d2hhdCANCiAgICAgICAgICBzZWVtcyBtb3JlIGltcG9ydGFudCB0byBtZSBpcyByZWFsbHkgdG8g YmVuZWZpdCBmdWxseSBmcm9tIHRoZSANCiAgICAgICAgICBhZHZhbnRhZ2VzIGJyb3VnaHQgYnkg aW50cm9kdWNpbmcgYSBuZXcgdG9wLWxldmVsIFRMViAod2hpY2ggd2FzIA0KICAgICAgICAgIGFw cGFyZW50bHkgb25lIG9mIHRoZSB0aGlua3MgeW91IHdlcmUgcmVsdWN0YW50IHRvIGRvKSwgbmFt ZWx5IHRoZSANCiAgICAgICAgICBjYXBhYmlsaXR5IHRvIGhhdmUgb25lIGluc3RhbmNlIG9mIHRo aXMmbmJzcDt0eXBlIHBlciBwb29sLiBIZXJlIGEgDQogICAgICAgICAgcG9vbCwgYmVpbmcgYSBj b25zaXN0ZW50Jm5ic3A7YnVuY2ggb2YgT0VPIHJlc291cmNlcywgc2hhcmluZyB0aGUgZmFjdCAN CiAgICAgICAgICB0aGF0IHVwZGF0aW5nIHRoZSB1c2FnZSBvZiZuYnNwO29uZSBvZiB0aGVtIHdp bGwgaGF2ZSANCiAgICAgICAgICBjb25zZXF1ZW5jZXMmbmJzcDtvbiB0aGUgYWNjZXNzaWJpbGl0 eSBvZiB0aGUgb3RoZXJzLiBXaGljaCBpcyB0byBteSANCiAgICAgICAgICBtaW5kIHRoZSBzbWFs bGVzdCBpbmZvcm1hdGlvbiZuYnNwO2VudGl0eSB0aGF0IHdpbGwgbmVlZCBhIHNpbmdsZSANCiAg ICAgICAgICB1cGRhdGUgb24gdGhlIG1vZGlmaWNhdGlvbiBvZiB1c2FnZSBvZiBvbmUgb2YgaXRz IG1lbWJlcnMsIGhlbmNlIHRoZSANCiAgICAgICAgICBtb3N0IGNvbXBsaWFudCB3aXRoIHNjYWxh YmlsaXR5LjwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICAgIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48Rk9OVCANCiAgICAg ICAgICBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgICAgIGxh bmc9RlI+PC9TUEFOPjwvRk9OVD48L1NQQU4+PFNQQU4gY2xhc3M9NzM2MjgwOTEwLTIwMTIyMDEw PjxGT05UIA0KICAgICAgICAgIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogICAgICAgICAgbGFuZz1GUj48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAg ICAgICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNv bG9yPSMwMDAwZmY+PEZPTlQgDQogICAgICAgICAgc2l6ZT0yPjxTUEFOIGNsYXNzPTczNjI4MDkx MC0yMDEyMjAxMD48U1BBTiBsYW5nPUZSPlRvIHN1bW1hcml6ZSwgb25jZSANCiAgICAgICAgICB0 aGUgY29zdCBvZiBpbnRyb2R1Y2luZyBhIG5ldyB0b3AtbGV2ZWwgVExWIGlzIGFjY2VwdGVkLCBs ZXQncyB1c2UgdGhlIA0KICAgICAgICAgIGFkdmFudGFnZXMgb2YgdGhlIGNvbmNlcHRzIGludHJv ZHVjZWQgaW4gb3VyIHNvbHV0aW9uIHRvIHRoZWlyIGZ1bGwgDQogICAgICAgICAgZXh0ZW50LCBh bmQgdGhlbiB1c2UgYSBsYXlvdXQgb2YgaW5mb3JtYXRpb24gY29tcGxpYW50IHdpdGggdGhhdC4g RG9lcyANCiAgICAgICAgICB0aGlzIHNlbXMgcmVhc29ubmFibGUgZm9yIHlvdSwgYW5kIGZvciB0 aGUgV0cgDQogICAgICAgICAgPzwvU1BBTj48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9E SVY+DQogICAgICAgICAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIA0KICAgICAgICAgIHNpemU9Mj48U1BBTiANCiAgICAg ICAgICBjbGFzcz03MzYyODA5MTAtMjAxMjIwMTA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05U PiZuYnNwOzwvRElWPg0KICAgICAgICAgIDxESVYgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFs PjxGT05UIHNpemU9Mj4tIHA8U1BBTiANCiAgICAgICAgICBjbGFzcz03MzYyODA5MTAtMjAxMjIw MTA+aWVycmU8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgICAgICAgICA8RElWPjxTUEFO IGNsYXNzPTczNjI4MDkxMC0yMDEyMjAxMD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg DQogICAgICAgICAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICAgICAg PERJVj48U1BBTiBjbGFzcz03MzYyODA5MTAtMjAxMjIwMTA+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0KICAgICAgICAgIHNpemU9Mj5QLlMuIExldCdzIGtlZXAgYXNpZGUgcmlnaHQg bm93Jm5ic3A7dGhlIGRpc2N1c3Npb25zIGNvbmNlcm5pbmcgDQogICAgICAgICAgdGhlIGFkbWlu aXN0cmF0aXZlIGdyb3VwLCBhbmQgVEUgbWV0cmljIHN1Yi1UTFZzLjwvRk9OVD48L1NQQU4+PC9E SVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgICAg ICAgPC9ESVY+DQogICAgICAgICAgPERJVj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RGUm bmJzcDs6PC9CPiA8QSANCiAgICAgICAgICBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQg aHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciIA0KICAgICAgICAgIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvQT4gWzxBIA0KICAgICAgICAg IGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZyIgDQogICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5tYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZzwvQT5dIDxCPkRlIGxhIA0KICAgICAgICAgIHBhcnQgZGU8L0I+IEdy ZWcgQmVybnN0ZWluPEJSPjxCPkVudm956SZuYnNwOzo8L0I+IG1hcmRpIDE0IGTpY2VtYnJlIA0K ICAgICAgICAgIDIwMTAgMTk6MjQ8QlI+PEI+wCZuYnNwOzo8L0I+IENDQU1QPEJSPjxCPk9iamV0 Jm5ic3A7OjwvQj4gW0NDQU1QXSBUb3AgDQogICAgICAgICAgTGV2ZWwgVExWcyBmb3IgV1NPTiBh bmQgR2VuZXJhbCBDb25zdHJhaW50IEV4dGVuc2lvbnMgdG8gT1NQRiANCiAgICAgICAgICAobG9u Zyk8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICAgICAgICA8QkxPQ0tRVU9URSBkaXI9bHRyIHN0 eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+SGkgYWxsIHR3byB3ZWVrcyBhZ28gDQogICAgICAgICAg ICB3ZSB1cGRhdGVkIGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZSBh bmQgDQogICAgICAgICAgICBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZSBiYXNlZCBv biBjb21tZW50cyBmcm9tIHRoZSBsaXN0IGFuZCANCiAgICAgICAgICAgIHRoZSBCZWlqaW5nIG1l ZXRpbmcuIFRoZXNlIGNoYW5nZXMgd2VyZSBlZGl0b3JpYWwgaW4gbmF0dXJlIGFuZCANCiAgICAg ICAgICAgIGNvbnNpc3RlZCBvZiByZW1vdmluZyBzb21lIGluZm9ybWF0aW9uYWwgdGV4dC4gPEJS PlRvIG1vdmUgdGhpbmdzIA0KICAgICAgICAgICAgZm9yd2FyZCBpbiBnZW5lcmFsIHdlIG5lZWQg dG8gcmVhY2ggYWdyZWVtZW50IG9uIHRoZSB0b3AgbGV2ZWwgVExWcyANCiAgICAgICAgICAgIHRv IGJlIHVzZWQgdG8gY2FycnkgdGhpcyBpbmZvcm1hdGlvbi4mbmJzcDsgV2UgaGF2ZSB0d28gbWFp biB0eXBlcyANCiAgICAgICAgICAgIG9mIGluZm9ybWF0aW9uOiAoYSkgbGluayByZWxhdGVkLCBh bmQgKGIpIG5vZGUgcmVsYXRlZC4mbmJzcDsgSW4gDQogICAgICAgICAgICBhZGRpdGlvbiwgZGVw ZW5kaW5nIG9uIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzeXN0ZW0gd2UgbWF5IHdhbnQgdG8gDQog ICAgICAgICAgICBzcGxpdCB0aGUgaW5mb3JtYXRpb24gZm9yIGEgcGFydGljdWxhciBub2RlIG9y IGxpbmsgaW50byBtdWx0aXBsZSANCiAgICAgICAgICAgIExTQXMmbmJzcDsgdG8ga2VlcCB0aGUg c2l6ZSBvZiB0aGUgTFNBIGJlbG93IGEgcGFydGljdWxhciBsaW1pdCBvciANCiAgICAgICAgICAg IHRvIHNlcGFyYXRlIHJhcGlkbHkgY2hhbmdpbmcgbm9kZSBvciBsaW5rIGluZm9ybWF0aW9uIGZy b20gDQogICAgICAgICAgICByZWxhdGl2ZWx5IHN0YXRpYy4gSW4gZ2VuZXJhbCBtdWx0aXBsZSBU RSBMU0EgaW5zdGFuY2VzIHByb3ZpZGUgYSANCiAgICAgICAgICAgIG1lY2hhbmlzbSBmb3IgdGhp cy48QlI+PEJSPjxCPkZvciBMaW5rIGluZm9ybWF0aW9uPC9CPiANCiAgICAgICAgICAgIDxCPlJG QzM2MzA8L0I+IGRlZmluZXMgdGhlICJUcmFmZmljIEVuZ2luZWVyaW5nIExTQSIuIFRoaXMgaGFz IGFyZWEgDQogICAgICAgICAgICBzY29wZS48QlI+Ik9uZSBuZXcgTFNBIGlzIGRlZmluZWQsIHRo ZSBUcmFmZmljIEVuZ2luZWVyaW5nIA0KICAgICAgICAgICAgTFNBLiZuYnNwOyBUaGlzIExTQSBk ZXNjcmliZXMgcm91dGVycywgcG9pbnQtdG8tcG9pbnQgbGlua3MsIGFuZCANCiAgICAgICAgICAg IGNvbm5lY3Rpb25zIHRvIG11bHRpLWFjY2VzcyBuZXR3b3JrcyAoc2ltaWxhciB0byBhIFJvdXRl ciANCiAgICAgICAgICAgIExTQSkuIjxCUj48QlI+TXVsdGlwbGUgaW5zdGFuY2VzIGNhbiBleGlz dCBmcm9tIGEgc2luZ2xlIA0KICAgICAgICAgICAgc291cmNlOjxCUj4iVGhlIEluc3RhbmNlIGZp ZWxkIGlzIGFuIGFyYml0cmFyeSB2YWx1ZSB1c2VkIHRvIA0KICAgICAgICAgICAgbWFpbnRhaW4g bXVsdGlwbGUgVHJhZmZpYyBFbmdpbmVlcmluZyBMU0FzLiZuYnNwOyBBIG1heGltdW0gb2YgDQog ICAgICAgICAgICAxNjc3NzIxNiBUcmFmZmljIEVuZ2luZWVyaW5nIExTQXMgbWF5IGJlIHNvdXJj ZWQgYnkgYSBzaW5nbGUgDQogICAgICAgICAgICBzeXN0ZW0uIjxCUj48QlI+VHdvIHRvcCBsZXZl bCBUTFZzIGFyZSBkZWZpbmVkOiBSb3V0ZXIgQWRkcmVzcyBUTFYgDQogICAgICAgICAgICAoc2Vj dGlvbiAyLjQuMSkgYW5kIExpbmsgVExWIChzZWN0aW9uIDIuNC4yKS4gVGhlIHJvdXRlciBhZGRy ZXNzIGlzIA0KICAgICAgICAgICAganVzdCBhcyBpdCBzYXlzLiBUaGUgbGluayBUTFYgaXMgdGhl IGdlbmVyYWxseSB1c2VmdWwgb25lIGZvciANCiAgICAgICAgICAgIHVzOjxCUj4iVGhlIExpbmsg VExWIGRlc2NyaWJlcyBhIHNpbmdsZSBsaW5rLiZuYnNwOyBJdCBpcyANCiAgICAgICAgICAgIGNv bnN0cnVjdGVkIG9mIGEgc2V0IG9mIHN1Yi1UTFZzLiZuYnNwOyBUaGVyZSBhcmUgbm8gb3JkZXJp bmcgDQogICAgICAgICAgICByZXF1aXJlbWVudHMgZm9yIHRoZSBzdWItVExWcy4gT25seSBvbmUg TGluayBUTFYgc2hhbGwgYmUgY2FycmllZCBpbiANCiAgICAgICAgICAgIGVhY2ggTFNBLCBhbGxv d2luZyBmb3IgZmluZSBncmFudWxhcml0eSBjaGFuZ2VzIGluIA0KICAgICAgICAgICAgdG9wb2xv Z3kuIjxCUj48QlI+VGhlcmUgZG9lcyBub3QgYXBwZWFyIHRvIGJlIGFueSBjb25zdHJhaW50cyBv biANCiAgICAgICAgICAgIGJyZWFraW5nIHVwIGluZm9ybWF0aW9uIGFib3V0IGEgc2luZ2xlIGxp bmsgaW50byBtdWx0aXBsZSBMU0FzLiBGb3IgDQogICAgICAgICAgICBXU09OIHVzZSB3ZSBtYXkg d2FudCB0byBrZWVwIHN0YXRpYyBpbmZvcm1hdGlvbiAocG9ydCB3YXZlbGVuZ3RoIA0KICAgICAg ICAgICAgY29uc3RyYWludHMpIHNlcGFyYXRlIGZyb20gZHluYW1pYyBpbmZvcm1hdGlvbiAod2F2 ZWxlbmd0aCANCiAgICAgICAgICAgIGF2YWlsYWJpbGl0eSkuPEJSPjxCUj48Qj5Gb3IgTm9kZSBM ZXZlbCBpbmZvcm1hdGlvbjwvQj4gKHN1Y2ggYXMgDQogICAgICAgICAgICBjb25uZWN0aXZpdHkg bWF0cmljZXMsIHJlc291cmNlIGJsb2NrIGluZm9ybWF0aW9uLCByZXNvdXJjZSBibG9jayANCiAg ICAgICAgICAgIHVzYWdlIHN0YXRlKSBpdCBzZWVtZWQgbGlrZSA8Qj5SRkMgNTc4NjwvQj4gd2hp Y2ggaGFzIGV4dGVuc2lvbnMgZm9yIA0KICAgICAgICAgICAgYWR2ZXJ0aXNpbmcgYSByb3V0ZXJz IGxvY2FsIGFkZHJlc3NlcyBpbiBURSBleHRlbnNpb25zIHdvdWxkIGJlIA0KICAgICAgICAgICAg dXNlZnVsLiBJdCBkZWZpbmVzIHRoZSBPU1BGIFRFIExTQSBOb2RlIFRMViBhbmQgdGhleSBzdGF0 ZTo8QlI+Ikl0IA0KICAgICAgICAgICAgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGUgTm9kZSBBdHRy aWJ1dGUgVExWIHdpbGwgYWxzbyBwcm92ZSBtb3JlIA0KICAgICAgICAgICAgZ2VuZXJhbGx5IHVz ZWZ1bC4iPEJSPkhvd2V2ZXIgaW4gc2VjdGlvbiA0LjIgKE9wZXJhdGlvbikgdGhleSANCiAgICAg ICAgICAgIHN0YXRlOjxCUj4iPEI+PEk+VGhlIE5vZGUgQXR0cmlidXRlIFRMViBNVVNUIE5PVCBh cHBlYXIgaW4gbW9yZSB0aGFuIA0KICAgICAgICAgICAgb25lIFRFIExTQSBvcmlnaW5hdGVkIGJ5 IGEgcm91dGVyPC9JPjwvQj4uJm5ic3A7IEZ1cnRoZXJtb3JlLCBzdWNoIA0KICAgICAgICAgICAg YW4gTFNBIE1VU1QgTk9UIGluY2x1ZGUgbW9yZSB0aGFuIG9uZSBOb2RlIEF0dHJpYnV0ZSANCiAg ICAgICAgICAgIFRMVi4iPEJSPjxCUj5UaGUgZmlyc3Qgb2YgdGhlc2UgcmVzdHJpY3Rpb25zIG9u IHVzZSBzZWVtcyB0byANCiAgICAgICAgICAgIHByZWNsdWRlIHVzIGZyb20gc2VwYXJhdGluZyB0 cmFmZmljIG1hdHJpY2VzLCByZXNvdXJjZSBibG9jayANCiAgICAgICAgICAgIGRlc2NyaXB0aW9u cywgYW5kIHJlc291cmNlIGJsb2NrIHV0aWxpemF0aW9uIHN0YXR1cyBpbnRvIHNlcGFyYXRlIA0K ICAgICAgICAgICAgTFNBIGluc3RhbmNlcyB1c2luZyB0aGlzIFRMVi4gVW5sZXNzIHRoaXMgcnVs ZSBjYW4gYmUgY2hhbmdlZCBpdCANCiAgICAgICAgICAgIHNlZW1zIHRoYXQgd2Ugd2lsbCBuZWVk IGEgbmV3IHRvcCBsZXZlbCAibm9kZSBwcm9wZXJ0aWVzIiBUTFYgZm9yIA0KICAgICAgICAgICAg dXNlIGluIGJvdGggV1NPTiBzcGVjaWZpYyBhbmQgR2VuZXJhbCBjb25zdHJhaW50IGV4dGVuc2lv bnMgdG8gDQogICAgICAgICAgICBPU1BGLiZuYnNwOyBQaWVycmUgYW5kIEdpb3Zhbm5pIGluIA0K ICAgICAgICAgICAgZHJhZnQtcGVsb3NvLWNjYW1wLXdzb24tb3NwZi1vZW8tMDIudHh0IHdhbnRl ZCB0byBkZWZpbmUgYSBuZXcgdG9wIA0KICAgICAgICAgICAgbGV2ZWwgVExWIGZvciB0aGUgcmVz b3VyY2UgYmxvY2sgaW5mb3JtYXRpb24sIGhvd2V2ZXIgaXQgc2VlbXMgdGhhdCANCiAgICAgICAg ICAgIHdlIHByb2JhYmx5IHNob3VsZCBhc2sgZm9yIGEgZ2VuZXJhbCAibm9kZSBwcm9wZXJ0aWVz IiAob3Igd2hhdGV2ZXIgDQogICAgICAgICAgICBiZXR0ZXIgbmFtZSB3ZSBjYW4gdGhpbmsgb2Yp IHRvcCBsZXZlbCBUTFYgdGhhdCBjb3VsZCBiZSBhcHBsaWVkIHRvIA0KICAgICAgICAgICAgdGhl IGdlbmVyYWwgY29uc3RyYWludCBub2RlIGluZm9ybWF0aW9uIChjb25uZWN0aXZpdHkgbWF0cmlj ZXMpIGFzIA0KICAgICAgICAgICAgd2VsbCBhcyB0aGUgdmFyaW91cyByZXNvdXJjZSByZWxhdGVk IHF1YW50aXRpZXMuJm5ic3A7IA0KICAgICAgICAgICAgPEJSPjxCUj5QaWVycmUgYW5kIEdpb3Zh bm5pIGRvZXMgdGhpcyBzb3VuZCBsaWtlIGEgcmVhc29uYWJsZSB3YXkgDQogICAgICAgICAgICBm b3J3YXJkPyBPciBkbyB5b3UgaGF2ZSBhIGRpZmZlcmVudCBzdWdnZXN0aW9uLiZuYnNwOyBDb21t ZW50cyBhbmQgDQogICAgICAgICAgICBzdWdnZXN0aW9ucyBmcm9tIGFsbCBhcmUgd2VsY29tZS48 QlI+PEJSPkJlc3QgUmVnYXJkczxCUj48QlI+R3JlZyANCiAgICAgICAgICAgIEIuPEJSPjxCUj48 UFJFIGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0iNzIiPi0tIA0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEciBHcmVnIEJlcm5zdGVpbiwgR3Jv dHRvIE5ldHdvcmtpbmcgKDUxMCkgNTczLTIyMzcNCg0KPC9QUkU+PC9CTE9DS1FVT1RFPjwvQkxP Q0tRVU9URT48QlI+PEJSPjxQUkUgY2xhc3M9bW96LXNpZ25hdHVyZSBjb2xzPSI3MiI+LS0gDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRyIEdy ZWcgQmVybnN0ZWluLCBHcm90dG8gTmV0d29ya2luZyAoNTEwKSA1NzMtMjIzNw0KDQo8L1BSRT48 L0RJVj48U1BBTj4mbHQ7QVRUMDAwMDEuLnR4dCZndDs8L1NQQU4+PC9CTE9DS1FVT1RFPjwvRElW PjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PEJSPjxCUj48UFJFIGNsYXNzPW1vei1zaWduYXR1cmUg Y29scz0iNzIiPi0tIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpEciBHcmVnIEJlcm5zdGVpbiwgR3JvdHRvIE5ldHdvcmtpbmcgKDUxMCkgNTcz LTIyMzcNCg0KPC9QUkU+PC9CTE9DS1FVT1RFPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5DQ0FNUCBt YWlsaW5nIA0KICBsaXN0PEJSPkNDQU1QQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXA8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_FIWtEYhB1lUmY93r8ZMbXg)-- From lberger@labn.net Mon Jan 10 06:57:13 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEBC3A69C4 for ; Mon, 10 Jan 2011 06:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 QZk8okY5LXgc for ; Mon, 10 Jan 2011 06:57:12 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id D5CB03A69B6 for ; Mon, 10 Jan 2011 06:57:12 -0800 (PST) Received: (qmail 31933 invoked by uid 0); 10 Jan 2011 14:59:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 10 Jan 2011 14:59:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Va3ma6c7sA/+bv+SOUGSFgNkmundcQAl/MAEDfBsienLHUcfObj06JfASTsAx9Tpe6VuSkyfiH1J8eln/yBXiAxNxyvW25rEt9d+rNHZEViG/pTDBuORCyq6/oTnqRJA; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PcJDS-0005KO-FY for ccamp@ietf.org; Mon, 10 Jan 2011 07:59:26 -0700 Message-ID: <4D2B1ECD.7040607@labn.net> Date: Mon, 10 Jan 2011 09:59:25 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP References: <4D136395.7040606@labn.net> In-Reply-To: <4D136395.7040606@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 14:57:13 -0000 This Last Call has ended. Authors, I don't recall seeing any comments on the list. If you received any comments privately, please address them and correct any nits (http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rwa-wson-framework-08.txt) then submit an updated draft. Also please let us know if you don't anticipate submitting an update. Much thanks, Lou On 12/23/2010 9:58 AM, Lou Berger wrote: > All, > > This mail begins a second working group last call on: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-08. The > last call ends on January 7th (slight extension due to holidays.) > > Note this second last call is being held due to the changes in the draft > since it was (1st) last called. The authors have provided a summary of > changes in: > http://www.ietf.org/mail-archive/web/ccamp/current/msg11765.html > > LC reviews/comments should focus on the modified text. > > Please send your comments to the CCAMP mailing list. > > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From leeyoung@huawei.com Mon Jan 10 07:17:08 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AD53A69C4 for ; Mon, 10 Jan 2011 07:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XCirfeiBXoIH for ; Mon, 10 Jan 2011 07:17:07 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 876AF3A6975 for ; Mon, 10 Jan 2011 07:17:07 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET00CM8BW8WH@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 07:19:21 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LET0011MBW8E4@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 07:19:20 -0800 (PST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 10 Jan 2011 07:19:18 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0218.012; Mon, 10 Jan 2011 07:19:16 -0800 Date: Mon, 10 Jan 2011 15:19:15 +0000 From: Leeyoung In-reply-to: <4D2B1ECD.7040607@labn.net> X-Originating-IP: [10.124.12.79] To: Lou Berger Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736A3BB@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework Thread-index: AQHLsNcV08jFMZv5QkC9mW/uAS4ce5PKUT1g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D136395.7040606@labn.net> <4D2B1ECD.7040607@labn.net> Cc: CCAMP Subject: Re: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:17:08 -0000 Hi Lou, We have not received any private comments on the draft. We will delete the appendix that discusses the history of the document in the revision. Thanks. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, January 10, 2011 8:59 AM To: CCAMP Subject: Re: [CCAMP] 2nd WG LC on draft-ietf-ccamp-rwa-wson-framework This Last Call has ended. Authors, I don't recall seeing any comments on the list. If you received any comments privately, please address them and correct any nits (http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rwa-wson-framework-08.txt) then submit an updated draft. Also please let us know if you don't anticipate submitting an update. Much thanks, Lou On 12/23/2010 9:58 AM, Lou Berger wrote: > All, > > This mail begins a second working group last call on: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-08. The > last call ends on January 7th (slight extension due to holidays.) > > Note this second last call is being held due to the changes in the draft > since it was (1st) last called. The authors have provided a summary of > changes in: > http://www.ietf.org/mail-archive/web/ccamp/current/msg11765.html > > LC reviews/comments should focus on the modified text. > > Please send your comments to the CCAMP mailing list. > > Lou (and Deborah) > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Internet-Drafts@ietf.org Mon Jan 10 07:45:03 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2143A682A; Mon, 10 Jan 2011 07:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 dWaiqXWqTsYo; Mon, 10 Jan 2011 07:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D3C3A67ED; Mon, 10 Jan 2011 07:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110154502.4293.77061.idtracker@localhost> Date: Mon, 10 Jan 2011 07:45:02 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:45:03 -0000 --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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-09.txt Pages : 54 Date : 2011-01-10 This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-09.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-rwa-wson-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10073358.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Jan 10 09:15:02 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35863A681F; Mon, 10 Jan 2011 09:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 kwf03fkI4YaR; Mon, 10 Jan 2011 09:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECD93A67AB; Mon, 10 Jan 2011 09:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110171501.27710.94125.idtracker@localhost> Date: Mon, 10 Jan 2011 09:15:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:15:02 -0000 --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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-10.txt Pages : 53 Date : 2011-01-10 This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-10.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-rwa-wson-framework-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10091426.I-D@ietf.org> --NextPart-- From leeyoung@huawei.com Mon Jan 10 09:19:10 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9C13A681A for ; Mon, 10 Jan 2011 09:19:10 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EEVU7nebE8Gb for ; Mon, 10 Jan 2011 09:19:09 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 9EB3D3A67ED for ; Mon, 10 Jan 2011 09:19:09 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET00C4WHJNWH@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 09:21:23 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LET00K16HJNNC@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 10 Jan 2011 09:21:23 -0800 (PST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 10 Jan 2011 09:21:21 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0218.012; Mon, 10 Jan 2011 09:21:22 -0800 Date: Mon, 10 Jan 2011 17:21:22 +0000 From: Leeyoung X-Originating-IP: [10.124.12.79] To: CCAMP Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736A484@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qOvFzRXAJZLJdaRmq99ZUw)" Content-language: en-US Accept-Language: en-US Thread-topic: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt Thread-index: AQHLsOpi8j3AFK+g0kK6KL/vw41DCpPKcyxA X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Subject: [CCAMP] FW: I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:19:10 -0000 --Boundary_(ID_qOvFzRXAJZLJdaRmq99ZUw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi CCAMPers, This update is just to fix some of the nits in the references and spacing. Thanks. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, January 10, 2011 11:15 AM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt 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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-10.txt Pages : 53 Date : 2011-01-10 This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-10.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. --Boundary_(ID_qOvFzRXAJZLJdaRmq99ZUw) Content-type: message/external-body; name=draft-ietf-ccamp-rwa-wson-framework-10.url Content-transfer-encoding: base64 Content-disposition: attachment; filename=draft-ietf-ccamp-rwa-wson-framework-10.url; size=103; creation-date="Mon, 10 Jan 2011 17:18:22 GMT"; modification-date="Mon, 10 Jan 2011 17:18:22 GMT" Content-description: draft-ietf-ccamp-rwa-wson-framework-10.url W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWZyYW1ld29yay0xMC50eHQNCg== --Boundary_(ID_qOvFzRXAJZLJdaRmq99ZUw) Content-id: <2A8CEF1A809AFF4A9A29735746D6C538@exchange.huawei.com> Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=130; creation-date="Mon, 10 Jan 2011 17:18:22 GMT"; modification-date="Mon, 10 Jan 2011 17:18:22 GMT" Content-description: ATT00001.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_qOvFzRXAJZLJdaRmq99ZUw)-- From Richard.Dunsmore@us.fujitsu.com Mon Jan 10 09:19:33 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59543A6AFC for ; Mon, 10 Jan 2011 09:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.109 X-Spam-Level: X-Spam-Status: No, score=-109.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 7r0-KBWK9Hvd for ; Mon, 10 Jan 2011 09:19:33 -0800 (PST) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) by core3.amsl.com (Postfix) with ESMTP id E47EA3A681A for ; Mon, 10 Jan 2011 09:19:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,301,1291615200"; d="scan'208,217";a="425916394" Received: from rchemxp01.fnc.net.local ([168.127.134.111]) by fncnmp02.fnc.fujitsu.com with ESMTP; 10 Jan 2011 11:21:47 -0600 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_01CBB0EA.D5533888" Date: Mon, 10 Jan 2011 11:21:35 -0600 Message-ID: <01F4E32C0948124DAA4C20DD6B5273420638C21B@rchemxp01.fnc.net.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] FW: I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt thread-index: Acuw6tVQ8BCxDfLWS/Wr6Di3oARsnAAAAAA4 From: "Dunsmore, Richard" To: "CCAMP" Subject: [CCAMP] Out of Office AutoReply: FW: I-D Action:draft-ietf-ccamp-rwa-wson-framework-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:19:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB0EA.D5533888 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am out of the office until 01/17 ------_=_NextPart_001_01CBB0EA.D5533888 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: [CCAMP] FW: I-D = Action:draft-ietf-ccamp-rwa-wson-framework-10.txt

I am out of the office until 01/17

------_=_NextPart_001_01CBB0EA.D5533888-- From Internet-Drafts@ietf.org Tue Jan 11 00:45:02 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1013A6A19; Tue, 11 Jan 2011 00:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Z1CXl9PoV+3z; Tue, 11 Jan 2011 00:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B993A69BF; Tue, 11 Jan 2011 00:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111084501.20416.21857.idtracker@localhost> Date: Tue, 11 Jan 2011 00:45:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:45:02 -0000 --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 Labels for Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.txt Pages : 16 Date : 2011-01-11 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined that a wavelength label only has significance between two neighbors and global wavelength semantics are not considered. In order to facilitate interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format that is compliant with Dense Wavelength Division Multiplexing and Coarse Wavelength Division Multiplexing grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.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-g-694-lambda-labels-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11003036.I-D@ietf.org> --NextPart-- From leeyoung@huawei.com Tue Jan 11 14:19:16 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6D83A6A9D for ; Tue, 11 Jan 2011 14:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_53=1, RCVD_IN_DNSWL_MED=-4] 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 eI5j1O-ECywu for ; Tue, 11 Jan 2011 14:19:01 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5661F3A6872 for ; Tue, 11 Jan 2011 14:19:01 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV002EOQ3ILQ@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 11 Jan 2011 16:21:18 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LEV00IO7Q3F4A@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 11 Jan 2011 16:21:18 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 11 Jan 2011 14:21:16 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0218.012; Tue, 11 Jan 2011 14:21:14 -0800 Date: Tue, 11 Jan 2011 22:21:13 +0000 From: Leeyoung In-reply-to: <745A5455E5D14361B3311D49116C8976@china.huawei.com> X-Originating-IP: [10.124.12.79] To: Fatai Zhang , "PELOSO, PIERRE (PIERRE)" , Greg Bernstein , Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736A6D4@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gKa9x3Gdn07ktGt2blZ2FQ)" Content-language: en-US Accept-Language: en-US Thread-topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-index: AcutxpxpyXylMEL5TQWoF72BtITcgQASmO2AADAN9AAAZjom9ABb3Sgg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> <745A5455E5D14361B3311D49116C8976@china.huawei.com> Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 22:19:16 -0000 --Boundary_(ID_gKa9x3Gdn07ktGt2blZ2FQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Pierre, Greg and Fatai, I tend to agree with Fatai. Since the connectivity matrix is a generic aspe= ct, we still can use existing TOP-level Node Attribute TLV. Please make sur= e that the connectivity matrix is non-WSON property. I think it was the int= ention of the CCAMP co-chairs to delineate WSON specific from Generic stuff= s. If we can agree with this, I think we can create ONE new TOP level TLV, "No= de Attribute for Optical Resources" (tentative name) in which to advertise = all Optical Resource related information. Although I still have problem understanding the RFC 5786 restriction on why= the TE LSA wouldn't allow more than one Node Attribute TLV, I want to reso= lve this issue and move the stalled OSPF extensions. So Pierre, Greg and Fatai, can we agree on this discussion. In summary: =B7 Use existing Node Attribute TLV for the connectivity matrix enc= oding =B7 Create ONE NEW top level node TLV (name to TBD) to encode all t= he optical resource related information. If we can agree, I think we can move on. If that is the case, I will update= current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf= -ccamp-wson-signal-compatibility-ospf/) to recommend use of a new top level= node TLV for the encoding of all optical resource related information. And there is no change in Fatai's draft (http://datatracker.ietf.org/doc/dr= aft-zhang-ccamp-general-constraints-ospf-ext/) I look forward to hearing from you. Best Regards, Young ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Sunday, January 09, 2011 7:59 PM To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensi= ons to OSPF (long) Hi Pierre and Greg, I need to remind you both that [OSPF-Gen] ("draft-zhang-ccamp-general-const= raints-ospf-ext-00.txt") is general (not specific to WSON). "Connectivity Matrix" defined in [OSPF-Gen] is a kind of node attribute, an= d it is static like "IPv4/v6 Local Address" defined in RFC5786, so we can r= esue "Node Attribute" top TLV to advertise Connectivity Matrix information = without breaking the existing rules/restrictions defined in RFC5786. For WSON specific information(ie., OEO stuff), I think we should define a n= ew top TLV in order to comply with the rules defined in RFC5786 (or we may = life-up this restriction defined in RFC5786 as Young suggested). Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: PELOSO, PIERRE (PIERRE) To: Greg Bernstein ; Acee Lindem Cc: CCAMP Sent: Saturday, January 08, 2011 1:13 AM Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensi= ons to OSPF (long) Hi Greg, Acee and Every CCAMPers, My answer is definitively two, Acee mentions there is no issue implementing= one or two regarding OSPF, hence I really see no blocking point against tw= o new Top level TLV. On top of ensuring the split between static and dynamic information. It als= o provides an intrinsic structure of information organization. One type of LSA is structured around the connectivity constraints of the no= des. Another type of LSA is structured around the resources in the node. One ins= tance per ressource block. Hence one LSA of this type updated only at each = time. This feature is achieved with no extra-cost on the overall information to b= e conveyed, while the one to be updated is intrinsically placed in independ= ant LSA. To conclude I am all the more convinced that we need to benefit of the inhe= rent organization of information spread over multiple type of LSAs. It prov= ides an inherent solution to address static and dynamic information inside = nodes, which is altogether efficient regarding the amount of information to= be updated, while providing a clear layout of information for OSPF-TE. Pierre ________________________________ De : Greg Bernstein [mailto:gregb@grotto-networking.com] Envoy=E9 : jeudi 6 janvier 2011 19:17 =C0 : Acee Lindem Cc : PELOSO, PIERRE (PIERRE); CCAMP Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensio= ns to OSPF (long) Thanks Acee. Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? What= would be the justification for two new Top level TLVs for node related inf= ormation? We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability). Hence I don't see the need = for two top level TLVs. Greg On 1/6/2011 9:24 AM, Acee Lindem wrote: Hi Greg, I think it is better to get 1 or 2 new top-level TE TLVs than to overload t= he TE Node Attribute TLV" with the optical capabilities information. Thanks, Acee On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: Hi Pierre, do you think we should still try to use the "node attribute top = level TLV" from RFC5786? A complete node description may require multiple c= onnectivity matrices and these could potentially become large. RFC5786 has = the constraint: "The Node Attribute TLV MUST NOT appear in more than one TE LSA origina= ted by a router. Furthermore, such an LSA MUST NOT include more than one N= ode Attribute TLV." So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances? Other opinions? Best Regards Greg On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: Hi Greg, To start with, I am pretty in-line with the part related to the link TLV, w= hich was already agreed. Regarding the node related information, I am happy to see that you consider= splitting its information over 2 top-level TLVs, which we have been pronin= g in order to ease the scalability and the information organisation. I do encourage you to adopt even more the concepts proned in draft-peloso-c= camp-won-ospf-oeo, by defining this new top-level TLV in a way that allows = to have multiple instance of it, one for each conistent entity of ressoruce= s. To detail my point of view, considering that I bet you would keep inside th= e node attribute top-level TLV the connectivity matrix object, and transfer= the informations concerning the OEO ressources to the new top-level TLV th= at you suggest to name Node Property. I have no hard convinctions on any na= me, and this one can fit with me, it is not the important thing anyway. I insist that, what seems more important to me is really to benefit fully f= rom the advantages brought by introducing a new top-level TLV (which was ap= parently one of the thinks you were reluctant to do), namely the capability= to have one instance of this type per pool. Here a pool, being a consisten= t bunch of OEO resources, sharing the fact that updating the usage of one o= f them will have consequences on the accessibility of the others. Which is = to my mind the smallest information entity that will need a single update o= n the modification of usage of one of its members, hence the most compliant= with scalability. To summarize, once the cost of introducing a new top-level TLV is accepted,= let's use the advantages of the concepts introduced in our solution to the= ir full extent, and then use a layout of information compliant with that. D= oes this sems reasonnable for you, and for the WG ? - pierre P.S. Let's keep aside right now the discussions concerning the administrati= ve group, and TE metric sub-TLVs. ________________________________ De : ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] De la part de Greg Bernstein Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 =C0 : CCAMP Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions t= o OSPF (long) Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode = and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and th= e Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text. To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information. We have two main types of in= formation: (a) link related, and (b) node related. In addition, depending = on the complexity of the system we may want to split the information for a = particular node or link into multiple LSAs to keep the size of the LSA bel= ow a particular limit or to separate rapidly changing node or link informat= ion from relatively static. In general multiple TE LSA instances provide a = mechanism for this. For Link information RFC3630 defines the "Traffic Engineering LSA". This ha= s area scope. "One new LSA is defined, the Traffic Engineering LSA. This LSA describes r= outers, point-to-point links, and connections to multi-access networks (sim= ilar to a Router LSA)." Multiple instances can exist from a single source: "The Instance field is an arbitrary value used to maintain multiple Traffic= Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be s= ourced by a single system." Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us: "The Link TLV describes a single link. It is constructed of a set of sub-T= LVs. There are no ordering requirements for the sub-TLVs. Only one Link TL= V shall be carried in each LSA, allowing for fine granularity changes in to= pology." There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability). For Node Level information (such as connectivity matrices, resource block i= nformation, resource block usage state) it seemed like RFC 5786 which has e= xtensions for advertising a routers local addresses in TE extensions would = be useful. It defines the OSPF TE LSA Node TLV and they state: "It is anticipated that the Node Attribute TLV will also prove more general= ly useful." However in section 4.2 (Operation) they state: "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated = by a router. Furthermore, such an LSA MUST NOT include more than one Node = Attribute TLV." The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TL= V for use in both WSON specific and General constraint extensions to OSPF. = Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to d= efine a new top level TLV for the resource block information, however it se= ems that we probably should ask for a general "node properties" (or whateve= r better name we can think of) top level TLV that could be applied to the g= eneral constraint node information (connectivity matrices) as well as the v= arious resource related quantities. Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion. Comments and suggestions from all are welco= me. Best Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_gKa9x3Gdn07ktGt2blZ2FQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Pierre, Greg and Fatai,<= /span>

 

I tend to agree with Fatai. Since the = connectivity matrix is a generic aspect, we still can use existing TOP-leve= l Node Attribute TLV. Please make sure that the connectivity matrix is non-WSON property. I thin= k it was the intention of the CCAMP co-chairs to delineate W= SON specific from Generic stuffs.

 

If we can agree with this, I think we = can create ONE new TOP level TLV, “Node Attribute for Optical Resourc= es” (tentative name) in which to advertise all Optical Resource related information. <= /font>

 

Although I still have problem understa= nding the RFC 5786 restriction on why the TE LSA wouldn’t allow more = than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions.

 

So Pierre, Greg and Fatai, can we agre= e on this discussion. In summary:

 

=B7 =         Use existing Node Attribute TLV for the connectivity matrix encoding

=B7 =         Create ONE NEW top level node TLV (name to TBD) to encode all the optic= al resource related information.

 

If we can agree, I think we can move o= n. If that is the case, I will update current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-c= ompatibility-ospf/) to recommend use of a new top level node TLV for the encoding of all optic= al resource related information.

 

And there is no change in Fatai’= s draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp= -general-constraints-ospf-ext/)

 

I look forward to hearing from you.

 

Best Regards,=

Young

 

 

= From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Sunday, January 09, 20= 11 7:59 PM
To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and General C= onstraint Extensions to OSPF (long)

 

<= span style=3D"font-family:Calibri;color:navy">Hi Pierre and Greg,

 

I need to remind you both that [OSPF= -Gen] ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") i= s general (not specific to WSON).

 

"Connectivity Matrix" defi= ned in [OSPF-Gen] is a kind of node attribute, and it is static like "= IPv4/v6 Local Address" defined in RFC5786, so we can resue "Node Attribute" top TLV to advertise C= onnectivity Matrix information without breaking the existing rules/restrict= ions defined in RFC5786.

 

For WSON specific information(ie., O= EO stuff), I think we should define a new top TLV in order to comply with t= he rules defined in RFC5786 (or we may  life-up this restriction defined in RFC5786 = as Young suggested).

 

 

 


Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message -----

= Cc: CCAMP <= /o:p>

= Sent: Saturday, January 08, 2011 1:13 AM

= Subject= : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

 

Hi Greg, Acee and Every CCAMPers,

 

My answer is definitively two, Acee me= ntions there is no issue implementing one or two regarding OSPF, hence I re= ally see no blocking point against two new Top level TLV.

On top of ensuring the split between s= tatic and dynamic information. It also provides an intrinsic structure of i= nformation organization.

One type of LSA is structured around t= he connectivity constraints of the nodes.

Another type of LSA is structured arou= nd the resources in the node. One instance per ressource block. Hence one L= SA of this type updated only at each time.

This feature is achieved with no extra= -cost on the overall information to be conveyed, while the one to be update= d is intrinsically placed in independant LSA.

To conclude I am all the more con= vinced that we need to benefit of the inherent organization of in= formation spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic in= formation inside nodes, which is altogether efficient regarding the amount = of information to be updated, while providing a clear layout of information= for OSPF-TE.

 

Pierre

 

De : Greg Bernstein [mailto:gregb@g= rotto-networking.com]
Envoy=E9 : jeudi 6 janv= ier 2011 19:17
=C0 : Acee Lindem
Cc : PELOSO, PIERRE (PI= ERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and Gener= al Constraint Extensions to OSPF (long)

Thanks Acee. 
Okay CCAMPers (Fatai and Pierr= e in particular) do we need one or two?  What would be the justificati= on for two new Top level TLVs for node related information? 
We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs.&nb= sp;

Greg


On 1/6/2011 9:24 AM, Acee Lindem wrote:

Hi Greg, 

I think it is better to get 1 or 2 n= ew top-level TE TLVs than to overload the TE Node Attribute TLV" with = the optical capabilities information. 

Thanks,

Acee <= /p>

On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:



Hi Pierre, do you think we should st= ill try to use the "node attribute top level TLV" from RFC5786? A= complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constra= int:
    "The Node Attribute TLV MUST NOT appear in more than one TE LSA origi= nated by a router.  Furthermore, such an LSA MUST NOT i= nclude more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:

Hi Greg,

 

To start with, I am pretty in-line wit= h the part related to the link TLV, which was already agreed.=

 

Regard= ing the node related information, I am happy to see that you consider split= ting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the inform= ation organisation.

I do e= ncourage you to adopt even more the concepts proned in draft-peloso-ccamp-w= on-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each con= istent entity of ressoruces.

 

To det= ail my point of view, considering that I bet you would keep inside the= node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the= new top-level TLV that you suggest to name Node Property. I have no hard c= onvinctions on any name, and this one can fit with me, it is not the import= ant thing anyway.

I insi= st that, what seems more important to me is really to benefit fully from th= e advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), nam= ely the capability to have one instance of this type per pool. Here a = pool, being a consistent bunch of OEO resources, sharing the fact that= updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind = the smallest information entity that will need a single update on the = modification of usage of one of its members, hence the most compliant with = scalability.

 

To sum= marize, once the cost of introducing a new top-level TLV is accepted, let's= use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information= compliant with that. Does this sems reasonnable for you, and for the WG ?<= /span>

 

- pierre<= /span>

 

P.S. Let's keep aside right now t= he discussions concerning the administrative group, and TE metric sub-TLVs.=

De : ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoy=E9 : mardi 14 d= =E9cembre 2010 19:24
=C0 : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General C= onstraint Extensions to OSPF (long)

Hi all two weeks ago we updated draf= t-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode= based on comments from the list and the Beijing= meeting. These changes were editorial in nature and consisted of removing = some informational text.
To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information.  We have two main types = of information: (a) link related, and (b) node related.  In addition, = depending on the complexity of the system we may want to split the information for a particular node or link into mu= ltiple LSAs  to keep the size of the LSA below a particular limit or t= o separate rapidly changing node or link information from relatively static= . In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic E= ngineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA d= escribes routers, point-to-point links, and connections to multi-access net= works (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Tr= affic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSA= s may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a se= t of sub-TLVs.  There are no ordering requirements for the sub-TLVs. O= nly one Link TLV shall be carried in each LSA, allowing for fine granularit= y changes in topology."

There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability).

For Node Level information (= such as connectivity matrices, resource block information, resource block u= sage state) it seemed like RFC 5786 which has extension= s for advertising a routers local addresses in TE extensions would be usefu= l. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more ge= nerally useful."
However in section 4.2 (Operation) they state:
"The Node Att= ribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than on= e Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TLV for use in both WSON = specific and General constraint extensions to OSPF.  Pierre and Giovan= ni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top le= vel TLV for the resource block information, however it seems that we probably should ask for a general "node properties&q= uot; (or whatever better name we can think of) top level TLV that could be = applied to the general constraint node information (connectivity matrices) = as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion.  Comments and suggestions from all are = welcome.

Best Regards

Greg B.


-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

<ATT00001..txt>

 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

____________________________________= ___________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--Boundary_(ID_gKa9x3Gdn07ktGt2blZ2FQ)-- From acee.lindem@ericsson.com Tue Jan 11 17:34:15 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21993A6802 for ; Tue, 11 Jan 2011 17:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_53=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 N1DcE1VE5Mcq for ; Tue, 11 Jan 2011 17:34:13 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id B73333A67ED for ; Tue, 11 Jan 2011 17:34:12 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p0C2DicT009923; Tue, 11 Jan 2011 20:13:50 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 11 Jan 2011 20:36:17 -0500 From: Acee Lindem To: Leeyoung Date: Tue, 11 Jan 2011 20:34:48 -0500 Thread-Topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-Index: Acux+Rsz1HL7K3hlSfSVWF53diioRQ== Message-ID: <01D37ACD-AB16-4666-8252-517538B40484@ericsson.com> References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> <745A5455E5D14361B3311D49116C8976@china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1736A6D4@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1736A6D4@DFWEML501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5-808792263"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 01:34:16 -0000 --Apple-Mail-5-808792263 Content-Type: multipart/alternative; boundary=Apple-Mail-4-808792249 --Apple-Mail-4-808792249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Young, Fatai, and Greg,=20 I'm not too concerned about lifting the restriction on the single TE LSA = containing the TE Node Attribute TLV. In fact, we are removing this = restriction for ASON single in order for a control place node to = advertise reachability information for more than one node in the = transport place. However, I still don't think that the WSON switching = capabilities belong here. As for the general constraints document, this = looks more along the lines of what could go here.=20 Thanks, Acee On Jan 11, 2011, at 5:21 PM, Leeyoung wrote: > Hi Pierre, Greg and Fatai, > =20 > I tend to agree with Fatai. Since the connectivity matrix is a generic = aspect, we still can use existing TOP-level Node Attribute TLV. Please = make sure that the connectivity matrix is non-WSON property. I think it = was the intention of the CCAMP co-chairs to delineate WSON specific from = Generic stuffs. > =20 > If we can agree with this, I think we can create ONE new TOP level = TLV, =93Node Attribute for Optical Resources=94 (tentative name) in = which to advertise all Optical Resource related information. > =20 > Although I still have problem understanding the RFC 5786 restriction = on why the TE LSA wouldn=92t allow more than one Node Attribute TLV, I = want to resolve this issue and move the stalled OSPF extensions. > =20 > So Pierre, Greg and Fatai, can we agree on this discussion. In = summary: > =20 > =B7 Use existing Node Attribute TLV for the connectivity = matrix encoding > =B7 Create ONE NEW top level node TLV (name to TBD) to encode = all the optical resource related information. > =20 > If we can agree, I think we can move on. If that is the case, I will = update current WSON-specific WG draft = (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibilit= y-ospf/) to recommend use of a new top level node TLV for the encoding = of all optical resource related information. > =20 > And there is no change in Fatai=92s draft = (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-osp= f-ext/) > =20 > I look forward to hearing from you. > =20 > Best Regards, > Young > =20 > =20 > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Fatai Zhang > Sent: Sunday, January 09, 2011 7:59 PM > To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem > Cc: CCAMP > Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint = Extensions to OSPF (long) > =20 > Hi Pierre and Greg, > =20 > I need to remind you both that [OSPF-Gen] = ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general = (not specific to WSON). > =20 > "Connectivity Matrix" defined in [OSPF-Gen] is a kind of node = attribute, and it is static like "IPv4/v6 Local Address" defined in = RFC5786, so we can resue "Node Attribute" top TLV to advertise = Connectivity Matrix information without breaking the existing = rules/restrictions defined in RFC5786. > =20 > For WSON specific information(ie., OEO stuff), I think we should = define a new top TLV in order to comply with the rules defined in = RFC5786 (or we may life-up this restriction defined in RFC5786 as Young = suggested). > =20 > =20 > =20 >=20 > Thanks > =20 > Fatai > =20 > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 > ----- Original Message ----- > From: PELOSO, PIERRE (PIERRE) > To: Greg Bernstein ; Acee Lindem > Cc: CCAMP > Sent: Saturday, January 08, 2011 1:13 AM > Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint = Extensions to OSPF (long) > =20 > Hi Greg, Acee and Every CCAMPers, > =20 > My answer is definitively two, Acee mentions there is no issue = implementing one or two regarding OSPF, hence I really see no blocking = point against two new Top level TLV. > On top of ensuring the split between static and dynamic information. = It also provides an intrinsic structure of information organization. > One type of LSA is structured around the connectivity constraints of = the nodes. > Another type of LSA is structured around the resources in the node. = One instance per ressource block. Hence one LSA of this type updated = only at each time. > This feature is achieved with no extra-cost on the overall information = to be conveyed, while the one to be updated is intrinsically placed in = independant LSA. > To conclude I am all the more convinced that we need to benefit of the = inherent organization of information spread over multiple type of LSAs. = It provides an inherent solution to address static and dynamic = information inside nodes, which is altogether efficient regarding the = amount of information to be updated, while providing a clear layout of = information for OSPF-TE. > =20 > Pierre > =20 > De : Greg Bernstein [mailto:gregb@grotto-networking.com]=20 > Envoy=E9 : jeudi 6 janvier 2011 19:17 > =C0 : Acee Lindem > Cc : PELOSO, PIERRE (PIERRE); CCAMP > Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint = Extensions to OSPF (long) >=20 > Thanks Acee. =20 > Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? = What would be the justification for two new Top level TLVs for node = related information? =20 > We've talked before about static versus dynamic information, but for = link information we seemed to have settled on using multiple LSA = instances for this purpose, i.e., keep the static stuff in LSA instances = different from the dynamic stuff (e.g. wavelength availability). Hence = I don't see the need for two top level TLVs. =20 >=20 > Greg >=20 >=20 > On 1/6/2011 9:24 AM, Acee Lindem wrote: > Hi Greg,=20 > I think it is better to get 1 or 2 new top-level TE TLVs than to = overload the TE Node Attribute TLV" with the optical capabilities = information.=20 > Thanks, > Acee=20 > On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: >=20 >=20 > Hi Pierre, do you think we should still try to use the "node attribute = top level TLV" from RFC5786? A complete node description may require = multiple connectivity matrices and these could potentially become large. = RFC5786 has the constraint:=20 > "The Node Attribute TLV MUST NOT appear in more than one TE LSA = originated by a router. Furthermore, such an LSA MUST NOT include more = than one Node Attribute TLV."=20 >=20 > So we couldn't split them up for MTU purposes. It seems that one new = top level TLV for a node without the RFC5786 constraints would suffice. = Do you think we need two? How would we justify two new top level TLVs to = the OSPF WG when we have the ability to use multiple instances? >=20 > Other opinions? >=20 > Best Regards >=20 > Greg=20 > On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: > Hi Greg, > =20 > To start with, I am pretty in-line with the part related to the link = TLV, which was already agreed. > =20 > Regarding the node related information, I am happy to see that you = consider splitting its information over 2 top-level TLVs, which we have = been proning in order to ease the scalability and the information = organisation. > I do encourage you to adopt even more the concepts proned in = draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a = way that allows to have multiple instance of it, one for each conistent = entity of ressoruces. > =20 > To detail my point of view, considering that I bet you would keep = inside the node attribute top-level TLV the connectivity matrix object, = and transfer the informations concerning the OEO ressources to the new = top-level TLV that you suggest to name Node Property. I have no hard = convinctions on any name, and this one can fit with me, it is not the = important thing anyway. > I insist that, what seems more important to me is really to benefit = fully from the advantages brought by introducing a new top-level TLV = (which was apparently one of the thinks you were reluctant to do), = namely the capability to have one instance of this type per pool. Here a = pool, being a consistent bunch of OEO resources, sharing the fact that = updating the usage of one of them will have consequences on the = accessibility of the others. Which is to my mind the smallest = information entity that will need a single update on the modification of = usage of one of its members, hence the most compliant with scalability. > =20 > To summarize, once the cost of introducing a new top-level TLV is = accepted, let's use the advantages of the concepts introduced in our = solution to their full extent, and then use a layout of information = compliant with that. Does this sems reasonnable for you, and for the WG = ? > =20 > - pierre > =20 > P.S. Let's keep aside right now the discussions concerning the = administrative group, and TE metric sub-TLVs. > De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part = de Greg Bernstein > Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 > =C0 : CCAMP > Objet : [CCAMP] Top Level TLVs for WSON and General Constraint = Extensions to OSPF (long) >=20 > Hi all two weeks ago we updated = draft-ietf-ccamp-general-constraint-encode and = draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the = Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text.=20 > To move things forward in general we need to reach agreement on the = top level TLVs to be used to carry this information. We have two main = types of information: (a) link related, and (b) node related. In = addition, depending on the complexity of the system we may want to split = the information for a particular node or link into multiple LSAs to = keep the size of the LSA below a particular limit or to separate rapidly = changing node or link information from relatively static. In general = multiple TE LSA instances provide a mechanism for this. >=20 > For Link information RFC3630 defines the "Traffic Engineering LSA". = This has area scope. > "One new LSA is defined, the Traffic Engineering LSA. This LSA = describes routers, point-to-point links, and connections to multi-access = networks (similar to a Router LSA)." >=20 > Multiple instances can exist from a single source: > "The Instance field is an arbitrary value used to maintain multiple = Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering = LSAs may be sourced by a single system." >=20 > Two top level TLVs are defined: Router Address TLV (section 2.4.1) and = Link TLV (section 2.4.2). The router address is just as it says. The = link TLV is the generally useful one for us: > "The Link TLV describes a single link. It is constructed of a set of = sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one = Link TLV shall be carried in each LSA, allowing for fine granularity = changes in topology." >=20 > There does not appear to be any constraints on breaking up information = about a single link into multiple LSAs. For WSON use we may want to keep = static information (port wavelength constraints) separate from dynamic = information (wavelength availability). >=20 > For Node Level information (such as connectivity matrices, resource = block information, resource block usage state) it seemed like RFC 5786 = which has extensions for advertising a routers local addresses in TE = extensions would be useful. It defines the OSPF TE LSA Node TLV and they = state: > "It is anticipated that the Node Attribute TLV will also prove more = generally useful." > However in section 4.2 (Operation) they state: > "The Node Attribute TLV MUST NOT appear in more than one TE LSA = originated by a router. Furthermore, such an LSA MUST NOT include more = than one Node Attribute TLV." >=20 > The first of these restrictions on use seems to preclude us from = separating traffic matrices, resource block descriptions, and resource = block utilization status into separate LSA instances using this TLV. = Unless this rule can be changed it seems that we will need a new top = level "node properties" TLV for use in both WSON specific and General = constraint extensions to OSPF. Pierre and Giovanni in = draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level = TLV for the resource block information, however it seems that we = probably should ask for a general "node properties" (or whatever better = name we can think of) top level TLV that could be applied to the general = constraint node information (connectivity matrices) as well as the = various resource related quantities. =20 >=20 > Pierre and Giovanni does this sound like a reasonable way forward? Or = do you have a different suggestion. Comments and suggestions from all = are welcome. >=20 > Best Regards >=20 > Greg B. >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > =20 >=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > =20 > > =20 >=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > =20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp --Apple-Mail-4-808792249 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Young, Fatai, and Greg, 

I'm not too concerned about = lifting the restriction on the single TE LSA containing the TE Node = Attribute TLV. In fact, we are removing this restriction for ASON single = in order for a control place node to advertise reachability information = for more than one node in the transport place. However, I still don't = think that the WSON switching capabilities belong here. As for the = general constraints document, this looks more along the lines of what = could go = here. 

Thanks,
Acee

=
On Jan 11, 2011, at 5:21 PM, Leeyoung wrote:

Hi Pierre, Greg and = Fatai,

 

I tend to agree with Fatai. Since = the connectivity matrix is a generic aspect, we still can use existing = TOP-level Node Attribute TLV. Please make sure that the connectivity matrix is non-WSON property. I = think it was the intention of the CCAMP co-chairs to = delineate WSON specific from Generic stuffs.

 

If we can agree with this, I think = we can create ONE new TOP level TLV, =93Node Attribute for Optical = Resources=94 (tentative name) in which to advertise all Optical Resource related information. =

 

Although I still have problem = understanding the RFC 5786 restriction on why the TE LSA wouldn=92t = allow more than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions. =

 

So Pierre, Greg and Fatai, can we = agree on this discussion. In summary:

 

=B7         Use existing = Node Attribute TLV for the connectivity matrix = encoding

=B7         Create ONE NEW = top level node TLV (name to TBD) to encode all the optical resource = related information.

 

If we can agree, I think we can = move on. If that is the case, I will update current WSON-specific WG = draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-sign= al-compatibility-ospf/) to recommend use of a new top level node TLV for the encoding of all = optical resource related information.

 

And there is no change in Fatai=92s = draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-c= onstraints-ospf-ext/)

 

I look forward to hearing from you.

 

Best = Regards,

Young

 

 

From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On = Behalf Of Fatai Zhang
Sent: Sunday, January 09, = 2011 7:59 PM
To: PELOSO, PIERRE = (PIERRE); Greg Bernstein; = Acee Lindem
Cc: CCAMP
Subject: Re: = [CCAMP] Top Level TLVs for = WSON and General Constraint Extensions to OSPF (long)

 

Hi Pierre and Greg,

 

I need to remind you both that = [OSPF-Gen] ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is = general (not specific to WSON).

 

"Connectivity Matrix" defined in = [OSPF-Gen] is a kind of node attribute, and it is static like "IPv4/v6 = Local Address" defined in RFC5786, so we can resue "Node Attribute" top TLV to advertise = Connectivity Matrix information without breaking the existing = rules/restrictions defined in RFC5786.

 

For WSON specific = information(ie., OEO stuff), I think we should define a new top TLV in = order to comply with the rules defined in RFC5786 (or we may  life-up this restriction defined in = RFC5786 as Young suggested).

 

 

 


Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

=

----- Original Message -----

Cc: CCAMP =

Sent:= Saturday, January 08, 2011 1:13 AM

Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF = (long)

 

Hi Greg, Acee and Every CCAMPers,

 

My answer is definitively two, Acee = mentions there is no issue implementing one or two regarding OSPF, hence = I really see no blocking point against two new Top level TLV.

On top of ensuring the split = between static and dynamic information. It also provides an intrinsic = structure of information organization.

One type of LSA is structured = around the connectivity constraints of the = nodes.

Another type of LSA is structured = around the resources in the node. One instance per ressource block. = Hence one LSA of this type updated only at each time.

This feature is achieved with no = extra-cost on the overall information to be conveyed, while the one to = be updated is intrinsically placed in independant LSA.

To conclude I am all the more = convinced that we need to benefit of the inherent organization = of information spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic = information inside nodes, which is altogether efficient regarding the = amount of information to be updated, while providing a clear layout of = information for OSPF-TE.

 

Pierre

 

De : Greg Bernstein = [mailto:gregb@grotto-networking.com]
Envoy=E9 : jeudi 6 = janvier 2011 19:17
=C0 : = Acee Lindem
Cc : PELOSO, PIERRE = (PIERRE); CCAMP
Objet : Re: = [CCAMP] Top Level TLVs for = WSON and General Constraint Extensions to OSPF (long)

Thanks Acee. 
Okay CCAMPers (Fatai and = Pierre in particular) do we need one or two?  What would be the = justification for two new Top level TLVs for node related = information? 
We've talked before about static versus dynamic information, but for = link information we seemed to have settled on using multiple LSA = instances for this purpose, i.e., keep the static stuff in LSA instances = different from the dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level = TLVs. 

Greg


On 1/6/2011 9:24 AM, Acee = Lindem wrote:

Hi Greg, 

I think it is better to get = 1 or 2 new top-level TE TLVs than to overload the TE Node Attribute TLV" = with the optical capabilities = information. 

Thanks,

Acee 

On Jan 3, 2011, at 11:55 = AM, Greg Bernstein = wrote:



Hi Pierre, do you think we should still try = to use the "node attribute top level TLV" from RFC5786? A complete node = description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the = constraint:
    "The Node Attribute TLV MUST = NOT appear in more than one TE LSA originated by a = router.  Furthermore, such an LSA MUST NOT include = more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top = level TLV for a node without the RFC5786 constraints would suffice. Do = you think we need two? How would we justify two new top level TLVs to = the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: =

Hi = Greg,

 

To start with, I am pretty in-line = with the part related to the link TLV, which was already = agreed.

 

Regarding the = node related information, I am happy to see that you consider splitting = its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the = information organisation.

I do = encourage you to adopt even more the concepts proned in = draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each = conistent entity of ressoruces.

 

To = detail my point of view, considering that I bet you would keep = inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to = the new top-level TLV that you suggest to name Node Property. I have no = hard convinctions on any name, and this one can fit with me, it is not = the important thing anyway.

I = insist that, what seems more important to me is really to benefit fully = from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), = namely the capability to have one instance of this type per pool. = Here a pool, being a consistent bunch of OEO resources, sharing the = fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my = mind the smallest information entity that will need a single update = on the modification of usage of one of its members, hence the most = compliant with scalability.

 

To = summarize, once the cost of introducing a new top-level TLV is accepted, = let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of = information compliant with that. Does this sems reasonnable for you, and = for the WG ?

 

- pierre

 

P.S. Let's keep aside right = now the discussions concerning the administrative group, and TE = metric sub-TLVs.

De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de = Greg Bernstein
Envoy=E9 : mardi 14 = d=E9cembre 2010 19:24
=C0 : = CCAMP
Objet : = [CCAMP] Top Level TLVs for = WSON and General Constraint Extensions to OSPF = (long)

Hi all two weeks ago we updated = draft-ietf-ccamp-general-constraint-encode and = draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were = editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top = level TLVs to be used to carry this information.  We have two main = types of information: (a) link related, and (b) node related.  In = addition, depending on the complexity of the system we may want to split the information for a particular node or link into = multiple LSAs  to keep the size of the LSA below a particular limit = or to separate rapidly changing node or link information from relatively = static. In general multiple TE LSA instances provide a mechanism for this.

For Link information = RFC3630 defines the = "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA = describes routers, point-to-point links, and connections to multi-access = networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple = Traffic Engineering LSAs.  A maximum of 16777216 Traffic = Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and = Link TLV (section 2.4.2). The router address is just as it says. The = link TLV is the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a set = of sub-TLVs.  There are no ordering requirements for the sub-TLVs. = Only one Link TLV shall be carried in each LSA, allowing for fine = granularity changes in topology."

There does not appear to be any constraints on breaking up information = about a single link into multiple LSAs. For WSON use we may want to keep = static information (port wavelength constraints) separate from dynamic = information (wavelength availability).

For Node Level = information (such as connectivity matrices, resource block = information, resource block usage state) it seemed like RFC 5786 which has = extensions for advertising a routers local addresses in TE extensions = would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more = generally useful."
However in section 4.2 (Operation) they state:
"The Node = Attribute TLV MUST NOT appear in more than one TE LSA originated by a = router.  Furthermore, such an LSA MUST NOT include = more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from = separating traffic matrices, resource block descriptions, and resource = block utilization status into separate LSA instances using this TLV. = Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON = specific and General constraint extensions to OSPF.  Pierre and = Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a = new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" = (or whatever better name we can think of) top level TLV that could be = applied to the general constraint node information (connectivity = matrices) as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do = you have a different suggestion.  Comments and suggestions from all = are welcome.

Best Regards

Greg B.


-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg =
Bernstein, Grotto Networking (510) =
573-2237
 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg =
Bernstein, Grotto Networking (510) =
573-2237
 

<ATT00001..txt><= /p>

 




-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg =
Bernstein, Grotto Networking (510) =
573-2237
 

_______________________________________________=
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/= mailman/listinfo/ccamp

=

=
= --Apple-Mail-4-808792249-- --Apple-Mail-5-808792263 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExMjAxMzQ0OFowIwYJKoZI hvcNAQkEMRYEFFNmnJu0rJE5pQPg9WrqpX4Asn4uMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDMjEkwyJlLLHKH/6wygx7PeS0OvX3utxJ7u6NuhS8ZJFT2MYgU7WtRVGGhDxR3R KhpiH5aF9FRQHOUXjn0XLDk0PuLiCk51CR7dESD6ztOpmVCteNFGLRXttpZP3HMt4GdCblF9ZU7t O3dT40Bo9H68nhHSWUskXNGWZclc+rmGAAAAAAAA --Apple-Mail-5-808792263-- From gregb@grotto-networking.com Wed Jan 12 10:20:53 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895F63A6A64 for ; Wed, 12 Jan 2011 10:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_53=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 U-pdD1Ugs+pC for ; Wed, 12 Jan 2011 10:20:50 -0800 (PST) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id 2893C3A680D for ; Wed, 12 Jan 2011 10:20:49 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p0CIMu1d011762; Wed, 12 Jan 2011 18:22:57 GMT Message-ID: <4D2DF17C.3000407@grotto-networking.com> Date: Wed, 12 Jan 2011 10:22:52 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Acee Lindem References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> <745A5455E5D14361B3311D49116C8976@china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1736A6D4@DFWEML501-MBX.china.huawei.com> <01D37ACD-AB16-4666-8252-517538B40484@ericsson.com> In-Reply-To: <01D37ACD-AB16-4666-8252-517538B40484@ericsson.com> Content-Type: multipart/alternative; boundary="------------020007090709080307040906" X-CSC: 0 X-CHA: v=1.1 cv=isW/3xriJrheY5qfHj3FsLYdvh9Aqae2ZJS34S2zH3k= c=1 sm=1 a=_4VyIEzS4mEA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=VZAVAGJQAAAA:8 a=0FD05c-RAAAA:8 a=rOv1AkKdcHLmd6TOn4QA:9 a=ODBO3-kH-R6itoVD_XgA:7 a=FG6Z05f0aDU8JI5sfaxkpVKlXnMA:4 a=pILNOxqGKmIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=lZB815dzVvQA:10 a=3FZX-ydVlcEA:10 a=m1nndEFD3LoA:10 a=f7GxY0FH8QIA:10 a=upcVuAcNMUdTyBd5:21 a=M-9Kz09cOkPzYBtA:21 a=ebihWP0fKHWoyC4GqcAA:9 a=TQ_FdQPvEZ8CYhJC6CQA:7 a=NgmFu9ZpGFL37Bkdm_km_9ywGREA:4 a=a-fm8pbZHyhJ4mPu:21 a=R65vAL13qD44LgDy:21 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:20:53 -0000 This is a multi-part message in MIME format. --------------020007090709080307040906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Acee, Young, Fatai and Pierre, the approach outlined below by Young and Acee below sounds great to me! Best Regards Greg On 1/11/2011 5:34 PM, Acee Lindem wrote: > Hi Young, Fatai, and Greg, > > I'm not too concerned about lifting the restriction on the single TE > LSA containing the TE Node Attribute TLV. In fact, we are removing > this restriction for ASON single in order for a control place node to > advertise reachability information for more than one node in the > transport place. However, I still don't think that the WSON switching > capabilities belong here. As for the general constraints document, > this looks more along the lines of what could go here. > > Thanks, > Acee > > On Jan 11, 2011, at 5:21 PM, Leeyoung wrote: > >> Hi Pierre, Greg and Fatai, >> >> I tend to agree with Fatai. Since the connectivity matrix is a >> generic aspect, we still can use existing TOP-level Node Attribute >> TLV. Please make sure that the connectivity matrix is non-WSON >> property. I think it was the intention of the CCAMP co-chairs to >> delineate WSON specific from Generic stuffs. >> >> If we can agree with this, I think we can create ONE new TOP level >> TLV, “Node Attribute for Optical Resources” (tentative name) in which >> to advertise all Optical Resource related information. >> >> Although I still have problem understanding the RFC 5786 restriction >> on why the TE LSA wouldn’t allow more than one Node Attribute TLV, I >> want to resolve this issue and move the stalled OSPF extensions. >> >> So Pierre, Greg and Fatai, can we agree on this discussion. In summary: >> >> ·Use existing Node Attribute TLV for the connectivity matrix encoding >> >> ·Create ONE NEW top level node TLV (name to TBD) to encode all the >> optical resource related information. >> >> If we can agree, I think we can move on. If that is the case, I will >> update current WSON-specific WG draft >> (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/) >> to recommend use of a new top level node TLV for the encoding of all >> optical resource related information. >> >> And there is no change in Fatai’s draft >> (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/) >> >> >> I look forward to hearing from you. >> >> Best Regards, >> >> Young >> >> ------------------------------------------------------------------------ >> >> *From:*ccamp-bounces@ietf.org >> [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Fatai Zhang >> *Sent:* Sunday, January 09, 2011 7:59 PM >> *To:* PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem >> *Cc:* CCAMP >> *Subject:* Re: [CCAMP] Top Level TLVs for WSON and General Constraint >> Extensions to OSPF (long) >> >> Hi Pierre and Greg, >> >> I need to remind you both that [OSPF-Gen] >> ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general >> (not specific to WSON). >> >> "Connectivity Matrix" defined in [OSPF-Gen] is a kind of node >> attribute, and it is static like "IPv4/v6 Local Address" defined in >> RFC5786, so we can resue "Node Attribute" top TLV to advertise >> Connectivity Matrix information without breaking the existing >> rules/restrictions defined in RFC5786. >> >> For WSON specific information(ie., OEO stuff), I think we should >> define a new top TLV in order to comply with the rules defined in >> RFC5786 (or we may life-up this restriction defined in RFC5786 as >> Young suggested). >> >> >> Thanks >> >> Fatai >> >> Huawei Technologies Co., LTD. >> Huawei Base, Bantian, Longgang, >> Shenzhen 518129 P.R.China >> Tel: +86-755-28972912 >> Fax: +86-755-28972935 >> >> ----- Original Message ----- >> >> *From:*PELOSO, PIERRE (PIERRE) >> >> >> *To:*Greg Bernstein ; Acee >> Lindem >> >> *Cc:*CCAMP >> >> *Sent:*Saturday, January 08, 2011 1:13 AM >> >> *Subject:*Re: [CCAMP] Top Level TLVs for WSON and General >> Constraint Extensions to OSPF (long) >> >> Hi Greg, Acee and Every CCAMPers, >> >> My answer is definitively two, Acee mentions there is no issue >> implementing one or two regarding OSPF, hence I really see no >> blocking point against two new Top level TLV. >> >> On top of ensuring the split between static and dynamic >> information. It also provides an intrinsic structure of >> information organization. >> >> One type of LSA is structured around the connectivity constraints >> of the nodes. >> >> Another type of LSA is structured around the resources in the >> node. One instance per ressource block. Hence one LSA of this >> type updated only at each time. >> >> This feature is achieved with no extra-cost on the overall >> information to be conveyed, while the one to be updated is >> intrinsically placed in independant LSA. >> >> To conclude I am all the more convinced that we need to benefit >> of the inherent organization of information spread over multiple >> type of LSAs. It provides an inherent solution to address static >> and dynamic information inside nodes, which is altogether >> efficient regarding the amount of information to be updated, >> while providing a clear layout of information for OSPF-TE. >> >> Pierre >> >> ------------------------------------------------------------------------ >> >> *De :*Greg Bernstein [mailto:gregb@grotto-networking.com] >> *Envoyé :* jeudi 6 janvier 2011 19:17 >> *À :* Acee Lindem >> *Cc :* PELOSO, PIERRE (PIERRE); CCAMP >> *Objet :* Re: [CCAMP] Top Level TLVs for WSON and General >> Constraint Extensions to OSPF (long) >> >> Thanks Acee. >> Okay CCAMPers (Fatai and Pierre in particular) do we need one >> or two? What would be the justification for two new Top >> level TLVs for node related information? >> We've talked before about static versus dynamic information, >> but for link information we seemed to have settled on using >> multiple LSA instances for this purpose, i.e., keep the >> static stuff in LSA instances different from the dynamic >> stuff (e.g. wavelength availability). Hence I don't see the >> need for two top level TLVs. >> >> Greg >> >> >> On 1/6/2011 9:24 AM, Acee Lindem wrote: >> >> Hi Greg, >> >> I think it is better to get 1 or 2 new top-level TE TLVs than >> to overload the TE Node Attribute TLV" with the optical >> capabilities information. >> >> Thanks, >> >> Acee >> >> On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: >> >> >> >> Hi Pierre, do you think we should still try to use the "node >> attribute top level TLV" from RFC5786? A complete node >> description may require multiple connectivity matrices and >> these could potentially become large. RFC5786 has the >> constraint: >> "*/The Node Attribute TLV MUST NOT appear in more than >> one TE LSA originated by a router/*. Furthermore, such an >> LSA MUST NOT include more than one Node Attribute TLV." >> >> So we couldn't split them up for MTU purposes. It seems that >> one new top level TLV for a node without the RFC5786 >> constraints would suffice. Do you think we need two? How >> would we justify two new top level TLVs to the OSPF WG when >> we have the ability to use multiple instances? >> >> Other opinions? >> >> Best Regards >> >> Greg >> On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: >> >> Hi Greg, >> >> To start with, I am pretty in-line with the part related to >> the link TLV, which was already agreed. >> >> Regarding the node related information, I am happy to see >> that you consider splitting its information over 2 top-level >> TLVs, which we have been proning in order to ease the >> scalability and the information organisation. >> >> I do encourage you to adopt even more the concepts proned in >> draft-peloso-ccamp-won-ospf-oeo, by defining this new >> top-level TLV in a way that allows to have multiple instance >> of it, one for each conistent entity of ressoruces. >> >> To detail my point of view, considering that I bet you would >> keep inside the node attribute top-level TLV the connectivity >> matrix object, and transfer the informations concerning the >> OEO ressources to the new top-level TLV that you suggest to >> name Node Property. I have no hard convinctions on any name, >> and this one can fit with me, it is not the important thing >> anyway. >> >> I insist that, what seems more important to me is really to >> benefit fully from the advantages brought by introducing a >> new top-level TLV (which was apparently one of the thinks you >> were reluctant to do), namely the capability to have one >> instance of this type per pool. Here a pool, being a >> consistent bunch of OEO resources, sharing the fact that >> updating the usage of one of them will have consequences on >> the accessibility of the others. Which is to my mind the >> smallest information entity that will need a single update on >> the modification of usage of one of its members, hence the >> most compliant with scalability. >> >> To summarize, once the cost of introducing a new top-level >> TLV is accepted, let's use the advantages of the concepts >> introduced in our solution to their full extent, and then use >> a layout of information compliant with that. Does this sems >> reasonnable for you, and for the WG ? >> >> - pierre >> >> P.S. Let's keep aside right now the discussions concerning >> the administrative group, and TE metric sub-TLVs. >> >> ------------------------------------------------------------------------ >> >> *De :*ccamp-bounces@ietf.org >> [mailto:ccamp-bounces@ietf.org] *De la part de* Greg Bernstein >> *Envoyé :* mardi 14 décembre 2010 19:24 >> *À :* CCAMP >> *Objet :* [CCAMP] Top Level TLVs for WSON and General >> Constraint Extensions to OSPF (long) >> >> Hi all two weeks ago we updated >> draft-ietf-ccamp-general-constraint-encode and >> draft-ietf-ccamp-rwa-wson-encode based on comments from >> the list and the Beijing meeting. These changes were >> editorial in nature and consisted of removing some >> informational text. >> To move things forward in general we need to reach >> agreement on the top level TLVs to be used to carry this >> information. We have two main types of information: (a) >> link related, and (b) node related. In addition, >> depending on the complexity of the system we may want to >> split the information for a particular node or link into >> multiple LSAs to keep the size of the LSA below a >> particular limit or to separate rapidly changing node or >> link information from relatively static. In general >> multiple TE LSA instances provide a mechanism for this. >> >> *For Link information* *RFC3630* defines the "Traffic >> Engineering LSA". This has area scope. >> "One new LSA is defined, the Traffic Engineering LSA. >> This LSA describes routers, point-to-point links, and >> connections to multi-access networks (similar to a Router >> LSA)." >> >> Multiple instances can exist from a single source: >> "The Instance field is an arbitrary value used to >> maintain multiple Traffic Engineering LSAs. A maximum of >> 16777216 Traffic Engineering LSAs may be sourced by a >> single system." >> >> Two top level TLVs are defined: Router Address TLV >> (section 2.4.1) and Link TLV (section 2.4.2). The router >> address is just as it says. The link TLV is the generally >> useful one for us: >> "The Link TLV describes a single link. It is constructed >> of a set of sub-TLVs. There are no ordering requirements >> for the sub-TLVs. Only one Link TLV shall be carried in >> each LSA, allowing for fine granularity changes in topology." >> >> There does not appear to be any constraints on breaking >> up information about a single link into multiple LSAs. >> For WSON use we may want to keep static information (port >> wavelength constraints) separate from dynamic information >> (wavelength availability). >> >> *For Node Level information* (such as connectivity >> matrices, resource block information, resource block >> usage state) it seemed like *RFC 5786* which has >> extensions for advertising a routers local addresses in >> TE extensions would be useful. It defines the OSPF TE LSA >> Node TLV and they state: >> "It is anticipated that the Node Attribute TLV will also >> prove more generally useful." >> However in section 4.2 (Operation) they state: >> "*/The Node Attribute TLV MUST NOT appear in more than >> one TE LSA originated by a router/*. Furthermore, such >> an LSA MUST NOT include more than one Node Attribute TLV." >> >> The first of these restrictions on use seems to preclude >> us from separating traffic matrices, resource block >> descriptions, and resource block utilization status into >> separate LSA instances using this TLV. Unless this rule >> can be changed it seems that we will need a new top level >> "node properties" TLV for use in both WSON specific and >> General constraint extensions to OSPF. Pierre and >> Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt >> wanted to define a new top level TLV for the resource >> block information, however it seems that we probably >> should ask for a general "node properties" (or whatever >> better name we can think of) top level TLV that could be >> applied to the general constraint node information >> (connectivity matrices) as well as the various resource >> related quantities. >> >> Pierre and Giovanni does this sound like a reasonable way >> forward? Or do you have a different suggestion. Comments >> and suggestions from all are welcome. >> >> Best Regards >> >> Greg B. >> >> >> -- >> >> =================================================== >> >> DrGreg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> >> >> >> -- >> >> =================================================== >> >> DrGreg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> >> >> >> >> >> -- >> >> =================================================== >> >> DrGreg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020007090709080307040906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Acee, Young, Fatai and Pierre,
the approach outlined below by Young and Acee below sounds great to me!
Best Regards
Greg
On 1/11/2011 5:34 PM, Acee Lindem wrote:
Hi Young, Fatai, and Greg, 

I'm not too concerned about lifting the restriction on the single TE LSA containing the TE Node Attribute TLV. In fact, we are removing this restriction for ASON single in order for a control place node to advertise reachability information for more than one node in the transport place. However, I still don't think that the WSON switching capabilities belong here. As for the general constraints document, this looks more along the lines of what could go here. 

Thanks,
Acee

On Jan 11, 2011, at 5:21 PM, Leeyoung wrote:

Hi Pierre, Greg and Fatai,

 

I tend to agree with Fatai. Since the connectivity matrix is a generic aspect, we still can use existing TOP-level Node Attribute TLV. Please make sure that the connectivity matrix is non-WSON property. I think it was the intention of the CCAMP co-chairs to delineate WSON specific from Generic stuffs.

 

If we can agree with this, I think we can create ONE new TOP level TLV, “Node Attribute for Optical Resources” (tentative name) in which to advertise all Optical Resource related information.

 

Although I still have problem understanding the RFC 5786 restriction on why the TE LSA wouldn’t allow more than one Node Attribute TLV, I want to resolve this issue and move the stalled OSPF extensions.

 

So Pierre, Greg and Fatai, can we agree on this discussion. In summary:

 

·         Use existing Node Attribute TLV for the connectivity matrix encoding

·         Create ONE NEW top level node TLV (name to TBD) to encode all the optical resource related information.

 

If we can agree, I think we can move on. If that is the case, I will update current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/) to recommend use of a new top level node TLV for the encoding of all optical resource related information.

 

And there is no change in Fatai’s draft (http://datatracker.ietf.org/doc/draft-zhang-ccamp-general-constraints-ospf-ext/)

 

I look forward to hearing from you.

 

Best Regards,

Young

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Sunday, January 09, 2011 7:59 PM
To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

 

Hi Pierre and Greg,

 

I need to remind you both that [OSPF-Gen] ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general (not specific to WSON).

 

"Connectivity Matrix" defined in [OSPF-Gen] is a kind of node attribute, and it is static like "IPv4/v6 Local Address" defined in RFC5786, so we can resue "Node Attribute" top TLV to advertise Connectivity Matrix information without breaking the existing rules/restrictions defined in RFC5786.

 

For WSON specific information(ie., OEO stuff), I think we should define a new top TLV in order to comply with the rules defined in RFC5786 (or we may  life-up this restriction defined in RFC5786 as Young suggested).

 

 

 


Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message -----

Cc: CCAMP

Sent: Saturday, January 08, 2011 1:13 AM

Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

 

Hi Greg, Acee and Every CCAMPers,

 

My answer is definitively two, Acee mentions there is no issue implementing one or two regarding OSPF, hence I really see no blocking point against two new Top level TLV.

On top of ensuring the split between static and dynamic information. It also provides an intrinsic structure of information organization.

One type of LSA is structured around the connectivity constraints of the nodes.

Another type of LSA is structured around the resources in the node. One instance per ressource block. Hence one LSA of this type updated only at each time.

This feature is achieved with no extra-cost on the overall information to be conveyed, while the one to be updated is intrinsically placed in independant LSA.

To conclude I am all the more convinced that we need to benefit of the inherent organization of information spread over multiple type of LSAs. It provides an inherent solution to address static and dynamic information inside nodes, which is altogether efficient regarding the amount of information to be updated, while providing a clear layout of information for OSPF-TE.

 

Pierre

 

De : Greg Bernstein [mailto:gregb@grotto-networking.com]
Envoyé : jeudi 6 janvier 2011 19:17
À : Acee Lindem
Cc : PELOSO, PIERRE (PIERRE); CCAMP
Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Thanks Acee. 
Okay CCAMPers (Fatai and Pierre in particular) do we need one or two?  What would be the justification for two new Top level TLVs for node related information? 
We've talked before about static versus dynamic information, but for link information we seemed to have settled on using multiple LSA instances for this purpose, i.e., keep the static stuff in LSA instances different from the dynamic stuff (e.g. wavelength availability).  Hence I don't see the need for two top level TLVs. 

Greg


On 1/6/2011 9:24 AM, Acee Lindem wrote:

Hi Greg, 

I think it is better to get 1 or 2 new top-level TE TLVs than to overload the TE Node Attribute TLV" with the optical capabilities information. 

Thanks,

Acee 

On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote:



Hi Pierre, do you think we should still try to use the "node attribute top level TLV" from RFC5786? A complete node description may require multiple connectivity matrices and these could potentially become large. RFC5786 has the constraint:
    "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

So we couldn't split them up for MTU purposes. It seems that one new top level TLV for a node without the RFC5786 constraints would suffice. Do you think we need two? How would we justify two new top level TLVs to the OSPF WG when we have the ability to use multiple instances?

Other opinions?

Best Regards

Greg
On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote:

Hi Greg,

 

To start with, I am pretty in-line with the part related to the link TLV, which was already agreed.

 

Regarding the node related information, I am happy to see that you consider splitting its information over 2 top-level TLVs, which we have been proning in order to ease the scalability and the information organisation.

I do encourage you to adopt even more the concepts proned in draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level TLV in a way that allows to have multiple instance of it, one for each conistent entity of ressoruces.

 

To detail my point of view, considering that I bet you would keep inside the node attribute top-level TLV the connectivity matrix object, and transfer the informations concerning the OEO ressources to the new top-level TLV that you suggest to name Node Property. I have no hard convinctions on any name, and this one can fit with me, it is not the important thing anyway.

I insist that, what seems more important to me is really to benefit fully from the advantages brought by introducing a new top-level TLV (which was apparently one of the thinks you were reluctant to do), namely the capability to have one instance of this type per pool. Here a pool, being a consistent bunch of OEO resources, sharing the fact that updating the usage of one of them will have consequences on the accessibility of the others. Which is to my mind the smallest information entity that will need a single update on the modification of usage of one of its members, hence the most compliant with scalability.

 

To summarize, once the cost of introducing a new top-level TLV is accepted, let's use the advantages of the concepts introduced in our solution to their full extent, and then use a layout of information compliant with that. Does this sems reasonnable for you, and for the WG ?

 

- pierre

 

P.S. Let's keep aside right now the discussions concerning the administrative group, and TE metric sub-TLVs.

De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoyé : mardi 14 décembre 2010 19:24
À : CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long)

Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and the Beijing meeting. These changes were editorial in nature and consisted of removing some informational text.
To move things forward in general we need to reach agreement on the top level TLVs to be used to carry this information.  We have two main types of information: (a) link related, and (b) node related.  In addition, depending on the complexity of the system we may want to split the information for a particular node or link into multiple LSAs  to keep the size of the LSA below a particular limit or to separate rapidly changing node or link information from relatively static. In general multiple TE LSA instances provide a mechanism for this.

For Link information RFC3630 defines the "Traffic Engineering LSA". This has area scope.
"One new LSA is defined, the Traffic Engineering LSA.  This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA)."

Multiple instances can exist from a single source:
"The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs.  A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system."

Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link TLV (section 2.4.2). The router address is just as it says. The link TLV is the generally useful one for us:
"The Link TLV describes a single link.  It is constructed of a set of sub-TLVs.  There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology."

There does not appear to be any constraints on breaking up information about a single link into multiple LSAs. For WSON use we may want to keep static information (port wavelength constraints) separate from dynamic information (wavelength availability).

For Node Level information (such as connectivity matrices, resource block information, resource block usage state) it seemed like RFC 5786 which has extensions for advertising a routers local addresses in TE extensions would be useful. It defines the OSPF TE LSA Node TLV and they state:
"It is anticipated that the Node Attribute TLV will also prove more generally useful."
However in section 4.2 (Operation) they state:
"The Node Attribute TLV MUST NOT appear in more than one TE LSA originated by a router.  Furthermore, such an LSA MUST NOT include more than one Node Attribute TLV."

The first of these restrictions on use seems to preclude us from separating traffic matrices, resource block descriptions, and resource block utilization status into separate LSA instances using this TLV. Unless this rule can be changed it seems that we will need a new top level "node properties" TLV for use in both WSON specific and General constraint extensions to OSPF.  Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new top level TLV for the resource block information, however it seems that we probably should ask for a general "node properties" (or whatever better name we can think of) top level TLV that could be applied to the general constraint node information (connectivity matrices) as well as the various resource related quantities. 

Pierre and Giovanni does this sound like a reasonable way forward? Or do you have a different suggestion.  Comments and suggestions from all are welcome.

Best Regards

Greg B.


-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

<ATT00001..txt>

 




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp




-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020007090709080307040906-- From lberger@labn.net Wed Jan 12 12:02:10 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7B83A6A8B for ; Wed, 12 Jan 2011 12:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 NqyvzcbXpogl for ; Wed, 12 Jan 2011 12:02:08 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id D54DA3A69A4 for ; Wed, 12 Jan 2011 12:02:08 -0800 (PST) Received: (qmail 12206 invoked by uid 0); 12 Jan 2011 20:04:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 12 Jan 2011 20:04:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=oyxcYmsA/tLsgxpWXZL/Bu+AsRfPf4oluT9efGsE/0vPmO62JlbLTzil8hVJU6JYsMSxoslWrJpdKxEeEPqEdpKogdWORkdzdPYvE8WsesfDL3gy3Yfq3vbUv0dNkwpn; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pd6vk-0006ek-U6; Wed, 12 Jan 2011 13:04:29 -0700 Message-ID: <4D2E097A.7030802@labn.net> Date: Wed, 12 Jan 2011 15:05:14 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP ADs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , The IESG Secretary Subject: [CCAMP] Please publish: draft-ietf-ccamp-rwa-wson-framework-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:02:10 -0000 Adrian, We request the publication of the document covered in the PROTO write included below. Much thanks, Lou (and Deborah) ========================================================================== PROTO-write-up for: draft-ietf-ccamp-rwa-wson-framework Intended status: Informational (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Lou Berger is the Document Shepherd. He has reviewed the document and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by WG members who are active in this area. The PCE WG was also notified about the WG LC and no comments were received. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns or additional review needed. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns or issues. No IPR found in the datatracker. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There is one instance of a missing reference which is really due to a capitalization mismatch which can be corrected as part of the publication process. No other reviews are required. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Split looks okay. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? No IANA implications. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, no automated checks needed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments, and does not address optical impairments in any depth. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document is an informational framework. From jcucchiara@mindspring.com Thu Jan 13 10:15:30 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D5E3A683D; Thu, 13 Jan 2011 10:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 x1ipV19nb97L; Thu, 13 Jan 2011 10:15:29 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 38E893A67B8; Thu, 13 Jan 2011 10:15:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X89VQKl63wNuWLb2B9YnWaHTgXnjk0hiT3PYDIW58lhwVgknwtIkxHhjG5NnSz/Q; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PdRk7-0002Wt-N3; Thu, 13 Jan 2011 13:17:51 -0500 Message-ID: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> From: "Joan Cucchiara" To: , "MIB Doctors \(E-mail\)" , "Tomohiro Otani" , "Masanori Miyazawa" , , "Thomas D. Nadeau" Date: Thu, 13 Jan 2011 13:15:46 -0500 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.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26549d3dfa31b1cf72b110eb8a3a9274c91c93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Cc: "Dan Romascanu \(E-mail\)" Subject: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:15:30 -0000 Hi Masonori, Thank you for the new version of this document. There were many good updates, particularly, the Conformance section. Please see following comments. Thanks, -Joan COMPILER RESULTS ------------------------------ * MIB compiles cleanly with smicngPRO * MIB compiles cleanly with smiLint DOCUMENT COMMENTS ------------------------------------- *) NIT: Does not strip cleanly with smicPRO's mstrip. (This does not have to be fixed for MIB Dr. purposes, only mention as an fyi.) *) Author contact info needs to be updated. *) Dates and copyright need to be updated *) RFC references probably need to be updated. RFC3784 was obsoleted by RFC5305 RFC4205 was obsoleted by RFC5307 IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. *) 2. Introduction Since this document supports both OSPFv2 and OSPFv3, please say this explicitly. *) The following 2 RFCs should be referenced also. a. OSPFv3 MIB is defined in rfc5643 b. TE extensions to OSPFv3 are described in RFC5329 *) 3.3 Acronyms These should be in alphabetical order (or some order that is defined at the beginning of this subsection.) Should include TED: Traffic Engineering Database *) Section 4. Motivations The motivation statement leads one to believe that this document will provide "for the management of all of the extensions to the OSPF and ISIS protocol.". There are 2 inconsistencies here: a) Since this is a read-only MIB, (no configuration) then the statement should be revised because management includes configuration. b) As previously mentioned, the use of OSPF and then references to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 along with relevant documents. *) Section 5.1 s/information of/information for/ *) Section 5.3 s/This is also independently utilized,because/Also, this is utilized independently because/ *) Section 5.4 This is referred to as Switch Capable and also as Switching Capability, please be consistent. If SwCap is supposed to be Switching Capability, then please use that Switching Capablity consistently. COMMENTS ON MIB MODULE -------------------------------------------- *) TEXTUAL-CONVENTIONS The names of these TCs are already used in the OSPFv2 MIB and while this may have been done intentionally, would prefer a TED specific name. For example: RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) Could these be renamed to be prefixed with "Ted" and suffixed with "TC", such as TedRouterIdTC" ? *) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate a) Why are these objects not located closer to the Notifications? b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION clause does not indicate that 0 has a special value (as it does for tedStatusChangeNotificationMaxRate, so just want to check on this? Do you really mean 0 here? *) tedInfoStatus object I think there is still some confusion about my request for status/state information. Obviously, if there are rows in these tables, then the MIB has been configured by some means other than SNMP, and granted notifications are sent (unless they are dropped due to throttling or lost), but what is the Operational Status link? The RowPointer object, tedLinkInformationData, might provide this information, however, the DESCRIPTION clause makes it sound completely optional since it looks like 0.0 can be entered under any circumstance, so again, I have to ask, how is an operator supposed to know if the TE link is acting as intended? If tedLinkInformationData is supposed to provide this, then it needs to be rewritten to be mandatory. That means that there are dependencies on other MIBs also. That is unclear in this document. In summary, tedInfoStatus object does not provide any additional information, as I can see if the MIB is populated. What I'm asking for is Operational Status/State information. Please discuss. *) tedSwCapSwitchingType Please rename to tedSwCapType. *) tedNotificationAreaId and tedNotificationRouterId Not sure why these are needed. Couldn't you include an object from the tedTable (such as tedLinkInformationSource) rather than have these accessible for Notify objects. Seems like extra work on all parts and not sure I see the advantage when you already have this info in a table. Please discuss. *) 8. Security Considerations s/read-write../read-write./ *) 10.1 Normative References a) Some of the Informative References should probably moved to Normative, specifically, any of the MIB docs that are IMPORTED or appear in a REFERENCE clause. *) 10.2 Informative References a) NIT: should be listed in increasing RFC Order. From db3546@att.com Thu Jan 13 11:37:27 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6263A6A81; Thu, 13 Jan 2011 11:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 t3NuNK4ehsf7; Thu, 13 Jan 2011 11:37:26 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1A2D93A6A6E; Thu, 13 Jan 2011 11:37:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1294947588!2577061!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26008 invoked from network); 13 Jan 2011 19:39:49 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jan 2011 19:39:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0DJcwvq023137; Thu, 13 Jan 2011 14:38:58 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0DJcrQK023055; Thu, 13 Jan 2011 14:38:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: C7z3 E+9H JrOq KQX9 MYjR TAA/ ULFZ UpNI YCou bfxb cQNY d/Wm eQN+ eUQN eing f+R+; 3; YQBkAHIAaQBhAG4ALgBmAGEAcgByAGUAbABAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBjAGMAYQBtAHAAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAC0AcwBlAGMAcgBlAHQAYQByAHkAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {13C12249-CFDC-43D0-A0C1-F94EF756A4F0}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 13 Jan 2011 19:39:35 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAG0AcABsAHMALQB0AHAALQBjAHAALQBmAHIAYQBtAGUAdwBvAHIAawAtADAANQAuAHQAeAB0AA== x-cr-puzzleid: {13C12249-CFDC-43D0-A0C1-F94EF756A4F0} Content-class: urn:content-classes:message Date: Thu, 13 Jan 2011 14:39:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-mpls-tp-cp-framework-05.txt Thread-Index: AcuzWZuDQBQx6CpYTomaV8zJseDokg== From: "BRUNGARD, DEBORAH A (ATTSI)" To: Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-mpls-tp-cp-framework-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 19:37:27 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D PROTO-write-up for: draft-ietf-ccamp-mpls-tp-cp-framework Intended status: Informational (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Deborah Brungard is the Document Shepherd. She has reviewed the document and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by CCAMP, MPLS, and PWE3 WGs. In addition, it was liaisoned with ITU-T. Two WG Last Calls were held to ensure adequate review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns or issues. No IPR found in the datatracker. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There is one nit regarding a missing reference to RFC 2119 due to one keyword use but this use is a quoted sentence from another RFC. There are several instances of long lines which can be corrected as part of the publication process. No other reviews are required. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Split looks okay. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? No IANA implications. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, no automated checks needed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document is an informational framework. From lberger@labn.net Fri Jan 14 07:08:06 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F7228C0E7 for ; Fri, 14 Jan 2011 07:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 OvSq3131uekh for ; Fri, 14 Jan 2011 07:08:05 -0800 (PST) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 0B9313A6C63 for ; Fri, 14 Jan 2011 07:08:05 -0800 (PST) Received: (qmail 11407 invoked by uid 0); 14 Jan 2011 15:10:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 14 Jan 2011 15:10:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=0bbmpeZ6sS9qr4eSDkhWHXNHVFMAIpMuUgIfJEX2oeAUTaIy+FvPpT3WdBabAl5ELyDQEPD9JyVR0wceuJ2KQYwdiILrdn8xil6oIrWkMAmA0XT705qsHZuXXpjysZ+r; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PdlIM-0003UV-8l; Fri, 14 Jan 2011 08:10:30 -0700 Message-ID: <4D306793.8@labn.net> Date: Fri, 14 Jan 2011 10:11:15 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joan Cucchiara References: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> In-Reply-To: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: Tomohiro Otani , "MIB Doctors \(E-mail\)" , ccamp@ietf.org, "Dan Romascanu \(E-mail\)" , ke-kumaki@kddilabs.jp Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 15:08:06 -0000 Joan, Thank you for the very thorough review! Authors, Please respond, letting us know how your propose to resolve each raised point. Please note that some of the comments require discussion which can/should take place over e-mail prior to a new version being submitted. Much thanks, Lou On 1/13/2011 1:15 PM, Joan Cucchiara wrote: > > Hi Masonori, > > Thank you for the new version of this document. There were many good > updates, particularly, the Conformance section. > > Please see following comments. > > Thanks, > -Joan > > > > COMPILER RESULTS > ------------------------------ > * MIB compiles cleanly with smicngPRO > > * MIB compiles cleanly with smiLint > > > DOCUMENT COMMENTS > ------------------------------------- > *) NIT: Does not strip cleanly with smicPRO's mstrip. > (This does not have to be fixed for MIB Dr. purposes, > only mention as an fyi.) > > > *) Author contact info needs to be updated. > > *) Dates and copyright need to be updated > > *) RFC references probably need to be updated. > > RFC3784 was obsoleted by RFC5305 > RFC4205 was obsoleted by RFC5307 > > IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. > > > > > *) 2. Introduction > > Since this document supports both OSPFv2 and OSPFv3, please > say this explicitly. > > *) The following 2 RFCs should be referenced also. > > a. OSPFv3 MIB is defined in rfc5643 > b. TE extensions to OSPFv3 are described in RFC5329 > > > > *) 3.3 Acronyms > > These should be in alphabetical order (or some order that > is defined at the beginning of this subsection.) > > Should include TED: Traffic Engineering Database > > > > *) Section 4. Motivations > > The motivation statement leads one to believe that this > document will provide "for the management of all of the > extensions to the OSPF and ISIS protocol.". > > There are 2 inconsistencies here: > a) Since this is a read-only MIB, (no configuration) then the > statement should be revised because management includes configuration. > b) As previously mentioned, the use of OSPF and then references > to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 > along with relevant documents. > > > *) Section 5.1 > > s/information of/information for/ > > > *) Section 5.3 > > s/This is also independently utilized,because/Also, this is utilized > independently > because/ > > > *) Section 5.4 > > This is referred to as Switch Capable and also > as Switching Capability, please be consistent. If SwCap is > supposed to be Switching Capability, then please use that > Switching Capablity consistently. > > > > > > COMMENTS ON MIB MODULE > -------------------------------------------- > > > *) TEXTUAL-CONVENTIONS > > The names of these TCs are already used in the OSPFv2 MIB > and while this may have been done intentionally, would prefer > a TED specific name. > > For example: > > RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) > > Could these be renamed to be prefixed with "Ted" > and suffixed with "TC", such as TedRouterIdTC" ? > > > > > *) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate > > a) Why are these objects not located closer to the Notifications? > > b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION > clause > does not indicate that 0 has a special value (as it does for > tedStatusChangeNotificationMaxRate, > so just want to check on this? Do you really mean 0 here? > > *) tedInfoStatus object > > I think there is still some confusion about my request for status/state > information. > Obviously, if there are rows in these tables, then > the MIB has been configured by some means other than SNMP, and granted > notifications are sent (unless > they are dropped due to throttling or lost), but what is the Operational > Status > link? > > The RowPointer object, tedLinkInformationData, might provide this > information, however, > the DESCRIPTION clause makes it sound completely optional since it looks > like 0.0 > can be entered under any circumstance, so again, I have to ask, how is an > operator > supposed to know if the TE link is acting as intended? > > If tedLinkInformationData is supposed to provide this, then it needs to be > rewritten to > be mandatory. That means that there are dependencies on other MIBs also. > That is > unclear in this document. > > In summary, tedInfoStatus object does not provide any additional > information, as > I can see if the MIB is populated. What I'm asking for is Operational > Status/State > information. > > > Please discuss. > > > *) tedSwCapSwitchingType > > Please rename to tedSwCapType. > > > > > *) tedNotificationAreaId and tedNotificationRouterId > > Not sure why these are needed. Couldn't you include > an object from the tedTable (such as tedLinkInformationSource) > rather than have these accessible for Notify objects. Seems like > extra work on all parts and not sure I see the advantage when > you already have this info in a table. > > Please discuss. > > > > *) 8. Security Considerations > > s/read-write../read-write./ > > *) 10.1 Normative References > > a) Some of the Informative References should > probably moved to Normative, specifically, any of the MIB > docs that are IMPORTED or appear in a REFERENCE clause. > > > *) 10.2 Informative References > > a) NIT: should be listed in increasing RFC Order. > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From pierre.peloso@alcatel-lucent.com Mon Jan 17 13:21:34 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F3C28C1FF for ; Mon, 17 Jan 2011 13:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-2.470, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_53=1, SARE_GENUINEOP=0.055] 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 w7wtxNM42+DZ for ; Mon, 17 Jan 2011 13:21:31 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id E093528C17D for ; Mon, 17 Jan 2011 13:21:29 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0HLNoov019310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Jan 2011 22:23:53 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 17 Jan 2011 22:23:51 +0100 From: "PELOSO, PIERRE (PIERRE)" To: Greg Bernstein , Acee Lindem Date: Mon, 17 Jan 2011 22:19:56 +0100 Thread-Topic: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) Thread-Index: AcuyhcIrC8w+Q4OFQnWD57z9idnFawBqHDvg Message-ID: References: <4D07B635.1030503@grotto-networking.com> <4D21FF94.8090205@grotto-networking.com> <4D26072B.8040902@grotto-networking.com> <745A5455E5D14361B3311D49116C8976@china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E1736A6D4@DFWEML501-MBX.china.huawei.com> <01D37ACD-AB16-4666-8252-517538B40484@ericsson.com> <4D2DF17C.3000407@grotto-networking.com> In-Reply-To: <4D2DF17C.3000407@grotto-networking.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CCBFBB7025DF984494DEC3285C058152126A04AB64FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to OSPF (long) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:21:34 -0000 --_000_CCBFBB7025DF984494DEC3285C058152126A04AB64FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, Point 1: I do agree as well to have a top level TLV for the connectivity ma= trix and another type of top level TLV to place the information related to = oeo encoding. Then I feel that we can conclude as agreed the usage of TE node attribute f= or the connectivity matrix. Point 2: Regarding the oeo, creating a new type of TLV is a perfect solutio= n, that I am supporting for sure. Once this being agreed and before jumping too fast in editing http://datatr= acker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/, I am c= onvinced that it is the right time to discuss how the encodings provided in= http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-07.txt can be = organized in the newly created top level TLV. Actually, for my part I see d= ifferent options to take the best of this novelty concerning this layout of= encodings. Hence, as a WG, we have here a genuine opportunity to examine these options= , thus possibly addressing during this review how those difference in layou= ts can influence the size of the corresponding LSA in order for those to fi= t in a single MTU as often as possible, while insuring OSPF scalability. [For clarification needs, I do not mean changing the inner content of the e= ncodings, I would just make sure that the way they are gathered inside the = newly created top-level TLV is addressing everyone needs.] Any comments? Regards to all, Pierre ________________________________ De : Greg Bernstein [mailto:gregb@grotto-networking.com] Envoy=E9 : mercredi 12 janvier 2011 19:23 =C0 : Acee Lindem Cc : Leeyoung; Fatai Zhang; PELOSO, PIERRE (PIERRE); CCAMP Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensio= ns to OSPF (long) Hi Acee, Young, Fatai and Pierre, the approach outlined below by Young and Acee below sounds great to me! Best Regards Greg On 1/11/2011 5:34 PM, Acee Lindem wrote: Hi Young, Fatai, and Greg, I'm not too concerned about lifting the restriction on the single TE LSA co= ntaining the TE Node Attribute TLV. In fact, we are removing this restricti= on for ASON single in order for a control place node to advertise reachabil= ity information for more than one node in the transport place. However, I s= till don't think that the WSON switching capabilities belong here. As for t= he general constraints document, this looks more along the lines of what co= uld go here. Thanks, Acee On Jan 11, 2011, at 5:21 PM, Leeyoung wrote: Hi Pierre, Greg and Fatai, I tend to agree with Fatai. Since the connectivity matrix is a generic aspe= ct, we still can use existing TOP-level Node Attribute TLV. Please make sur= e that the connectivity matrix is non-WSON property. I think it was the int= ention of the CCAMP co-chairs to delineate WSON specific from Generic stuff= s. If we can agree with this, I think we can create ONE new TOP level TLV, "No= de Attribute for Optical Resources" (tentative name) in which to advertise = all Optical Resource related information. Although I still have problem understanding the RFC 5786 restriction on why= the TE LSA wouldn't allow more than one Node Attribute TLV, I want to reso= lve this issue and move the stalled OSPF extensions. So Pierre, Greg and Fatai, can we agree on this discussion. In summary: * Use existing Node Attribute TLV for the connectivity matrix encod= ing * Create ONE NEW top level node TLV (name to TBD) to encode all the= optical resource related information. If we can agree, I think we can move on. If that is the case, I will update= current WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf= -ccamp-wson-signal-compatibility-ospf/) to recommend use of a new top level= node TLV for the encoding of all optical resource related information. And there is no change in Fatai's draft (http://datatracker.ietf.org/doc/dr= aft-zhang-ccamp-general-constraints-ospf-ext/) I look forward to hearing from you. Best Regards, Young ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Fatai Zhang Sent: Sunday, January 09, 2011 7:59 PM To: PELOSO, PIERRE (PIERRE); Greg Bernstein; Acee Lindem Cc: CCAMP Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensi= ons to OSPF (long) Hi Pierre and Greg, I need to remind you both that [OSPF-Gen] ("draft-zhang-ccamp-general-const= raints-ospf-ext-00.txt") is general (not specific to WSON). "Connectivity Matrix" defined in [OSPF-Gen] is a kind of node attribute, an= d it is static like "IPv4/v6 Local Address" defined in RFC5786, so we can r= esue "Node Attribute" top TLV to advertise Connectivity Matrix information = without breaking the existing rules/restrictions defined in RFC5786. For WSON specific information(ie., OEO stuff), I think we should define a n= ew top TLV in order to comply with the rules defined in RFC5786 (or we may = life-up this restriction defined in RFC5786 as Young suggested). Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: PELOSO, PIERRE (PIERRE) To: Greg Bernstein ; Acee Lindem Cc: CCAMP Sent: Saturday, January 08, 2011 1:13 AM Subject: Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensi= ons to OSPF (long) Hi Greg, Acee and Every CCAMPers, My answer is definitively two, Acee mentions there is no issue implementing= one or two regarding OSPF, hence I really see no blocking point against tw= o new Top level TLV. On top of ensuring the split between static and dynamic information. It als= o provides an intrinsic structure of information organization. One type of LSA is structured around the connectivity constraints of the no= des. Another type of LSA is structured around the resources in the node. One ins= tance per ressource block. Hence one LSA of this type updated only at each = time. This feature is achieved with no extra-cost on the overall information to b= e conveyed, while the one to be updated is intrinsically placed in independ= ant LSA. To conclude I am all the more convinced that we need to benefit of the inhe= rent organization of information spread over multiple type of LSAs. It prov= ides an inherent solution to address static and dynamic information inside = nodes, which is altogether efficient regarding the amount of information to= be updated, while providing a clear layout of information for OSPF-TE. Pierre ________________________________ De : Greg Bernstein [mailto:gregb@grotto-networking.com] Envoy=E9 : jeudi 6 janvier 2011 19:17 =C0 : Acee Lindem Cc : PELOSO, PIERRE (PIERRE); CCAMP Objet : Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensio= ns to OSPF (long) Thanks Acee. Okay CCAMPers (Fatai and Pierre in particular) do we need one or two? What= would be the justification for two new Top level TLVs for node related inf= ormation? We've talked before about static versus dynamic information, but for link i= nformation we seemed to have settled on using multiple LSA instances for th= is purpose, i.e., keep the static stuff in LSA instances different from the= dynamic stuff (e.g. wavelength availability). Hence I don't see the need = for two top level TLVs. Greg On 1/6/2011 9:24 AM, Acee Lindem wrote: Hi Greg, I think it is better to get 1 or 2 new top-level TE TLVs than to overload t= he TE Node Attribute TLV" with the optical capabilities information. Thanks, Acee On Jan 3, 2011, at 11:55 AM, Greg Bernstein wrote: Hi Pierre, do you think we should still try to use the "node attribute top = level TLV" from RFC5786? A complete node description may require multiple c= onnectivity matrices and these could potentially become large. RFC5786 has = the constraint: "The Node Attribute TLV MUST NOT appear in more than one TE LSA origina= ted by a router. Furthermore, such an LSA MUST NOT include more than one N= ode Attribute TLV." So we couldn't split them up for MTU purposes. It seems that one new top le= vel TLV for a node without the RFC5786 constraints would suffice. Do you th= ink we need two? How would we justify two new top level TLVs to the OSPF WG= when we have the ability to use multiple instances? Other opinions? Best Regards Greg On 12/20/2010 4:27 AM, PELOSO, PIERRE (PIERRE) wrote: Hi Greg, To start with, I am pretty in-line with the part related to the link TLV, w= hich was already agreed. Regarding the node related information, I am happy to see that you consider= splitting its information over 2 top-level TLVs, which we have been pronin= g in order to ease the scalability and the information organisation. I do encourage you to adopt even more the concepts proned in draft-peloso-c= camp-won-ospf-oeo, by defining this new top-level TLV in a way that allows = to have multiple instance of it, one for each conistent entity of ressoruce= s. To detail my point of view, considering that I bet you would keep inside th= e node attribute top-level TLV the connectivity matrix object, and transfer= the informations concerning the OEO ressources to the new top-level TLV th= at you suggest to name Node Property. I have no hard convinctions on any na= me, and this one can fit with me, it is not the important thing anyway. I insist that, what seems more important to me is really to benefit fully f= rom the advantages brought by introducing a new top-level TLV (which was ap= parently one of the thinks you were reluctant to do), namely the capability= to have one instance of this type per pool. Here a pool, being a consisten= t bunch of OEO resources, sharing the fact that updating the usage of one o= f them will have consequences on the accessibility of the others. Which is = to my mind the smallest information entity that will need a single update o= n the modification of usage of one of its members, hence the most compliant= with scalability. To summarize, once the cost of introducing a new top-level TLV is accepted,= let's use the advantages of the concepts introduced in our solution to the= ir full extent, and then use a layout of information compliant with that. D= oes this sems reasonnable for you, and for the WG ? - pierre P.S. Let's keep aside right now the discussions concerning the administrati= ve group, and TE metric sub-TLVs. ________________________________ De : ccamp-bounces@ietf.org [mailto:ccamp-bo= unces@ietf.org] De la part de Greg Bernstein Envoy=E9 : mardi 14 d=E9cembre 2010 19:24 =C0 : CCAMP Objet : [CCAMP] Top Level TLVs for WSON and General Constraint Extensions t= o OSPF (long) Hi all two weeks ago we updated draft-ietf-ccamp-general-constraint-encode = and draft-ietf-ccamp-rwa-wson-encode based on comments from the list and th= e Beijing meeting. These changes were editorial in nature and consisted of = removing some informational text. To move things forward in general we need to reach agreement on the top lev= el TLVs to be used to carry this information. We have two main types of in= formation: (a) link related, and (b) node related. In addition, depending = on the complexity of the system we may want to split the information for a = particular node or link into multiple LSAs to keep the size of the LSA bel= ow a particular limit or to separate rapidly changing node or link informat= ion from relatively static. In general multiple TE LSA instances provide a = mechanism for this. For Link information RFC3630 defines the "Traffic Engineering LSA". This ha= s area scope. "One new LSA is defined, the Traffic Engineering LSA. This LSA describes r= outers, point-to-point links, and connections to multi-access networks (sim= ilar to a Router LSA)." Multiple instances can exist from a single source: "The Instance field is an arbitrary value used to maintain multiple Traffic= Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be s= ourced by a single system." Two top level TLVs are defined: Router Address TLV (section 2.4.1) and Link= TLV (section 2.4.2). The router address is just as it says. The link TLV i= s the generally useful one for us: "The Link TLV describes a single link. It is constructed of a set of sub-T= LVs. There are no ordering requirements for the sub-TLVs. Only one Link TL= V shall be carried in each LSA, allowing for fine granularity changes in to= pology." There does not appear to be any constraints on breaking up information abou= t a single link into multiple LSAs. For WSON use we may want to keep static= information (port wavelength constraints) separate from dynamic informatio= n (wavelength availability). For Node Level information (such as connectivity matrices, resource block i= nformation, resource block usage state) it seemed like RFC 5786 which has e= xtensions for advertising a routers local addresses in TE extensions would = be useful. It defines the OSPF TE LSA Node TLV and they state: "It is anticipated that the Node Attribute TLV will also prove more general= ly useful." However in section 4.2 (Operation) they state: "The Node Attribute TLV MUST NOT appear in more than one TE LSA originated = by a router. Furthermore, such an LSA MUST NOT include more than one Node = Attribute TLV." The first of these restrictions on use seems to preclude us from separating= traffic matrices, resource block descriptions, and resource block utilizat= ion status into separate LSA instances using this TLV. Unless this rule can= be changed it seems that we will need a new top level "node properties" TL= V for use in both WSON specific and General constraint extensions to OSPF. = Pierre and Giovanni in draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to d= efine a new top level TLV for the resource block information, however it se= ems that we probably should ask for a general "node properties" (or whateve= r better name we can think of) top level TLV that could be applied to the g= eneral constraint node information (connectivity matrices) as well as the v= arious resource related quantities. Pierre and Giovanni does this sound like a reasonable way forward? Or do yo= u have a different suggestion. Comments and suggestions from all are welco= me. Best Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 --_000_CCBFBB7025DF984494DEC3285C058152126A04AB64FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
Point 1: I do agree as well to have a top level TLV for the connec= tivity=20 matrix and another type of top level TLV to place the information related t= o oeo=20 encoding.
Then I feel that we can conclude as agreed the usage of = TE node=20 attribute for the connectivity matrix.
 
Point 2: Regarding the oeo, creating a new type of TLV is a perfec= t=20 solution, that I am supporting for sure.
Once this being agreed and before jumping too fast in editing http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signa= l-compatibility-ospf/,=20 I am convinced that it is the right time to discuss how the encod= ings=20 provided in http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode= -07.txt can=20 be organized in the newly created top level TLV. Actually, f= or my=20 part I see different options to take the best of this novelty=20 concerning this layout of encodings.
 
Hence, as a WG, we have here a genuine opportunity to ex= amine=20 these options, thus possibly addressing during this review h= ow=20 those difference in layouts can influence the size of the corresponding LSA= in=20 order for those to fit in a single MTU as often as possible, while ins= uring=20 OSPF scalability.
 
[For clar= ification=20 needs, I do not mean changing the inner content of the encodings, I=20 would just make sure that the way they are gathered inside the newly=20 created top-level TLV is addressing everyone needs.]
 
Any=20 comments?
 
Regards to all,
 
Pierre
=
De : Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Envoy=E9 : mercredi = 12=20 janvier 2011 19:23
=C0 : Acee Lindem
Cc :=20 Leeyoung; Fatai Zhang; PELOSO, PIERRE (PIERRE); CCAMP
Objet :<= /B>=20 Re: [CCAMP] Top Level TLVs for WSON and General Constraint Extensions to = OSPF=20 (long)

Hi Acee, Young, Fatai and Pierre,
the approach outlined be= low=20 by Young and Acee below sounds great to me!
Best Regards
Greg
On= =20 1/11/2011 5:34 PM, Acee Lindem wrote:=20
Hi Young, Fatai, and Greg, =20

I'm not too concerned about lifting the restriction on the single = TE=20 LSA containing the TE Node Attribute TLV. In fact, we are removing this= =20 restriction for ASON single in order for a control place node to advert= ise=20 reachability information for more than one node in the transport place.= =20 However, I still don't think that the WSON switching capabilities belon= g=20 here. As for the general constraints document, this looks more along th= e=20 lines of what could go here. 

Thanks,
Acee

On Jan 11, 2011, at 5:21 PM, Leeyoung wrote:

Hi Pierre,= Greg=20 and Fatai,

I tend to = agree=20 with Fatai. Since the connectivity matrix is a generic aspect, we sti= ll=20 can use existing TOP-level Node Attribute TLV. Please make sure that = the=20 connectivity matrix is non-WSON property. I think it was the intentio= n of=20 the CCAMP co-chairs to=20 delineate WSON specific from Generic stuffs.

If we can = agree=20 with this, I think we can create ONE new TOP level TLV, =93Node Attri= bute=20 for Optical Resources=94 (tentative name) in which to advertise all O= ptical=20 Resource related information.

Although I= still=20 have problem understanding the RFC 5786 restriction on why the TE LSA= =20 wouldn=92t allow more than one Node Attribute TLV, I want to resolve = this=20 issue and move the stalled OSPF extensions. =

So Pierre,= Greg=20 and Fatai, can we agree on this discussion. In=20 summary:

=B7=    &= nbsp;    =20 Use=20 existing Node Attribute TLV for the connectivity matrix=20 encoding

=B7=    &= nbsp;    =20 Create ONE= NEW=20 top level node TLV (name to TBD) to encode all the optical resource=20 related information.

If we can = agree,=20 I think we can move on. If that is the case, I will update current=20 WSON-specific WG draft (http://datatracker.ietf.org/doc/draft-ietf-c= camp-wson-signal-compatibility-ospf/)=20 to recommend use of a new top level node TLV for the encoding of all= =20 optical resource related information.

And there = is no=20 change in Fatai=92s draft (http://datatracker.ietf.org/doc/draft-zhang-= ccamp-general-constraints-ospf-ext/)=20

I look for= ward to=20 hearing from you.

Best=20 Regards,

Young=

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org<= /A>]=20 On Behalf Of Fatai=20 Zhang
Sent: Sunday= ,=20 January 09, 2011 7:59 PM
To: PELOSO, PIERRE (PIERRE);=20 Greg Bernstein; Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] Top Level TLVs for WSON and Gener= al=20 Constraint Extensions to OSPF (long)

Hi Pierre and=20 Greg,

I need t= o=20 remind you both that [OSPF-Gen]=20 ("draft-zhang-ccamp-general-constraints-ospf-ext-00.txt") is general = (not=20 specific to WSON).

"Connect= ivity=20 Matrix" defined in [OSPF-Gen] is a kind of node attribute, and it is= =20 static like "IPv4/v6 Local Address" defined in RFC5786, so we can res= ue=20 "Node Attribute" top TLV to advertise Connectivity Matrix information= =20 without breaking the existing rules/restrictions defined in=20 RFC5786.

For WSON= =20 specific information(ie., OEO stuff), I think we should define a new = top=20 TLV in order to comply with the rules defined in RFC5786 (or we = may=20  life-up this restriction defined in RFC5786 as Young=20 suggested).


Thanks
 
Fatai=
 
Huawei=20 Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen= =20 518129 P.R.China
Tel: +86-755-28972912
Fax:=20 +86-755-28972935

----- Original Messag= e -----=20

Fr= om: PELOSO, PIERRE (PIERRE)=20

= To= : Greg=20 Bernstein ; A= cee=20 Lindem

= Cc= : CCAMP

= Se= nt:=20 Saturday, January 08, 2011 1:13 AM

= Su= bject:=20 Re: [CCAMP] Top Level = TLVs=20 for WSON and General Constraint Extensions to OSPF=20 (long)

Hi Greg,= Acee=20 and Every CCAMPers,

My answe= r is=20 definitively two, Acee mentions there is no issue implementing one = or=20 two regarding OSPF, hence I really see no blocking point against tw= o new=20 Top level TLV.

On top o= f=20 ensuring the split between static and dynamic information. It also= =20 provides an intrinsic structure of information=20 organization.

One type= of LSA=20 is structured around the connectivity constraints of the=20 nodes.

Another = type of=20 LSA is structured around the resources in the node. One instance pe= r=20 ressource block. Hence one LSA of this type updated only at each=20 time.

This fea= ture is=20 achieved with no extra-cost on the overall information to be convey= ed,=20 while the one to be updated is intrinsically placed in independant= =20 LSA.

To concl= ude I=20 am all the more convinced that we need to benefit of=20 the inherent organization of information spread over multiple = type=20 of LSAs. It provides an inherent solution to address static and dyn= amic=20 information inside nodes, which is altogether efficient regarding t= he=20 amount of information to be updated, while providing a clear layout= of=20 information for OSPF-TE.

<= FONT=20 face=3DArial color=3Dblue size=3D2>Pierre

De : Greg Bernstein [mailto:gregb@grotto-n= etworking.com]=20
Envoy=E9 : jeudi=20 6 janvier 2011 19:17
=C0 : Acee Lindem
Cc : PELOSO, PIERRE=20 (PIERRE); CCAMP
<= B>Objet : Re: [CCAMP] Top Level TLVs for WSON and G= eneral=20 Constraint Extensions to OSPF (long)

Thanks Acee. 
O= kay=20 CCAMPers (Fatai and = Pierre=20 in particular) do we need one or two?  What would be the=20 justification for two new Top level TLVs for node related=20 information? 
We've talked before about static versus dy= namic=20 information, but for link information we seemed to have settled o= n=20 using multiple LSA instances for this purpose, i.e., keep the sta= tic=20 stuff in LSA instances different from the dynamic stuff (e.g.=20 wavelength availability).  Hence I don't see the need for tw= o top=20 level TLVs. 

Greg


On 1/6/2011 9:24 AM,=20 Acee Lindem wrote:=20

Hi Greg, =20

I think it is better to = get 1 or=20 2 new top-level TE TLVs than to overload the TE Node Attribute TL= V"=20 with the optical capabilities=20 information. 

Thanks,

Acee 

On Jan 3, = 2011, at=20 11:55 AM, Greg Bernstein=20 wrote:



Hi Pierre,= do you=20 think we should still try to use the "node attribute top level TL= V"=20 from RFC5786? A complete node description may require multiple=20 connectivity matrices and these could potentially become large.=20 RFC5786 has the constraint:
    "The Node Attribut= e TLV=20 MUST NOT appear in more than one TE LSA originated by a=20 router.  Furthermore, such an LSA MUST NOT in= clude=20 more than one Node Attribute TLV."

So we couldn't split t= hem=20 up for MTU purposes. It seems that one new top level TLV for a no= de=20 without the RFC5786 constraints would suffice. Do you think we ne= ed=20 two? How would we justify two new top level TLVs to the OSPF WG w= hen=20 we have the ability to use multiple instances?

Other=20 opinions?

Best Regards

Greg
On 12/20/2010 4:27 = AM,=20 PELOSO, PIERRE (PIERRE) wrote:

Hi=20 Greg,

To sta= rt=20 with, I am pretty in-line with the part related to the link TLV, = which=20 was already agreed.

Regard= ing the=20 node related information, I am happy to see that you consider=20 splitting its information over 2 top-level TLVs, which we have be= en=20 proning in order to ease the scalability and the information=20 organisation.

I do=20 encourage you to adopt even more the concepts proned in=20 draft-peloso-ccamp-won-ospf-oeo, by defining this new top-level T= LV in=20 a way that allows to have multiple instance of it, one for each=20 conistent entity of ressoruces.

To det= ail my=20 point of view, considering that I bet you would keep inside = the=20 node attribute top-level TLV the connectivity matrix object, and= =20 transfer the informations concerning the OEO ressources to the ne= w=20 top-level TLV that you suggest to name Node Property. I have no h= ard=20 convinctions on any name, and this one can fit with me, it is not= the=20 important thing anyway.

I insi= st=20 that, what seems more important to me is really to benefit fully = from=20 the advantages brought by introducing a new top-level TLV (which = was=20 apparently one of the thinks you were reluctant to do), namely th= e=20 capability to have one instance of this type per pool. Here = a=20 pool, being a consistent bunch of OEO resources, sharing the= fact=20 that updating the usage of one of them will have=20 consequences on the accessibility of the others. Which is to= my=20 mind the smallest information entity that will need a single= =20 update on the modification of usage of one of its members, hence = the=20 most compliant with scalability.

To sum= marize,=20 once the cost of introducing a new top-level TLV is accepted, let= 's=20 use the advantages of the concepts introduced in our solution to = their=20 full extent, and then use a layout of information compliant with = that.=20 Does this sems reasonnable for you, and for the WG=20 ?

- pierre

P.S. L= et's=20 keep aside right now the discussions concerning the=20 administrative group, and TE metric=20 sub-TLVs.

De :=20 ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de Greg Bernstein
Envoy=E9 : mardi 14 d= =E9cembre=20 2010 19:24
=C0 :=20 CCAMP
Objet : [CCAMP] Top Level TLVs for WSON and G= eneral=20 Constraint Extensions to OSPF=20 (long)

Hi all t= wo weeks=20 ago we updated draft-ietf-ccamp-general-constraint-encode and=20 draft-ietf-ccamp-rwa-wson-encode based on comments from the lis= t and=20 the Beijing meeting. These chang= es were=20 editorial in nature and consisted of removing some informationa= l=20 text.
To move things forward in general we need to reach=20 agreement on the top level TLVs to be used to carry this=20 information.  We have two main types of information: (a) l= ink=20 related, and (b) node related.  In addition, depending on = the=20 complexity of the system we may want to split the information f= or a=20 particular node or link into multiple LSAs  to keep the si= ze of=20 the LSA below a particular limit or to separate rapidly changin= g=20 node or link information from relatively static. In general mul= tiple=20 TE LSA instances provide a mechanism for this.

For Link information = RFC3630 defines the "Tra= ffic=20 Engineering LSA". This has area scope.
"One new LSA is defin= ed,=20 the Traffic Engineering LSA.  This LSA describes routers,= =20 point-to-point links, and connections to multi-access networks= =20 (similar to a Router LSA)."

Multiple instances can exist= from=20 a single source:
"The Instance field is an arbitrary value u= sed=20 to maintain multiple Traffic Engineering LSAs.  A maximum = of=20 16777216 Traffic Engineering LSAs may be sourced by a single=20 system."

Two top level TLVs are defined: Router Address = TLV=20 (section 2.4.1) and Link TLV (section 2.4.2). The router addres= s is=20 just as it says. The link TLV is the generally useful one for=20 us:
"The Link TLV describes a single link.  It is=20 constructed of a set of sub-TLVs.  There are no ordering=20 requirements for the sub-TLVs. Only one Link TLV shall be carri= ed in=20 each LSA, allowing for fine granularity changes in=20 topology."

There does not appear to be any constraints o= n=20 breaking up information about a single link into multiple LSAs.= For=20 WSON use we may want to keep static information (port wavelengt= h=20 constraints) separate from dynamic information (wavelength=20 availability).

For = Node=20 Level information (such as connectivity matrices,=20 resource block information, resource block usage state) it seem= ed=20 like RFC 5786 w= hich=20 has extensions for advertising a routers local addresses in TE= =20 extensions would be useful. It defines the OSPF TE LSA Node TLV= and=20 they state:
"It is anticipated that the Node Attribute TLV w= ill=20 also prove more generally useful."
However in section 4.2=20 (Operation) they state:
"The Node Attrib= ute TLV=20 MUST NOT appear in more than one TE LSA originated by a=20 router.  Furthermore, such an LSA MUST NOT= =20 include more than one Node Attribute TLV."

The first of = these=20 restrictions on use seems to preclude us from separating traffi= c=20 matrices, resource block descriptions, and resource block=20 utilization status into separate LSA instances using this TLV.= =20 Unless this rule can be changed it seems that we will need a ne= w top=20 level "node properties" TLV for use in both WSON specific and=20 General constraint extensions to OSPF.  Pierre and Giovann= i in=20 draft-peloso-ccamp-wson-ospf-oeo-02.txt wanted to define a new = top=20 level TLV for the resource block information, however it seems = that=20 we probably should ask for a general "node properties" (or what= ever=20 better name we can think of) top level TLV that could be applie= d to=20 the general constraint node information (connectivity matrices)= as=20 well as the various resource related quantities. =20

Pierre and Giovanni does this sound like a reasonable w= ay=20 forward? Or do you have a different suggestion.  Comments = and=20 suggestions from all are welcome.

Best Regards

Gr= eg=20 B.


-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, G= rotto Networking (510) 573-2237
<=
O:P> 




-- 
=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/SPAN>
<=
SPAN style=3D"FONT-SIZE: 10pt">Dr Greg Bernstei=
n, Grotto Networking (510) 573-2237
 

<ATT00001..txt>= 




-- 
=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/SPAN>
<=
SPAN style=3D"FONT-SIZE: 10pt">Dr Greg Bernstei=
n, Grotto Networking (510) 573-2237
 
=

_________________________________________= ______
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccam= p




--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--_000_CCBFBB7025DF984494DEC3285C058152126A04AB64FRMRSSXCHMBSA_-- From Adrian.Farrel@huawei.com Mon Jan 17 15:06:58 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D315D3A6ED8 for ; Mon, 17 Jan 2011 15:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=-0.941, 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 jQ8k6OKNOjkY for ; Mon, 17 Jan 2011 15:06:58 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0E5A13A6ED7 for ; Mon, 17 Jan 2011 15:06:58 -0800 (PST) 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 <0LF600JS3WBW9U@usaga01-in.huawei.com> for ccamp@ietf.org; Mon, 17 Jan 2011 15:09:32 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF600I4RWBUJ0@usaga01-in.huawei.com> for ccamp@ietf.org; Mon, 17 Jan 2011 15:09:32 -0800 (PST) Date: Mon, 17 Jan 2011 23:09:29 +0000 From: Adrian Farrel To: draft-ietf-ccamp-mpls-tp-cp-framework@tools.ietf.org Message-id: <033401cbb69b$99cdf970$cd69ec50$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu2m5SYojlf4FmyTmKH3OpAC178Qg== Cc: 'CCAMP' Subject: [CCAMP] AD review of draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:06:58 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. Cracking draft, thank you. I have a number of small editorial comments (below), but considering their size I think you should simply handle them as part of the IETF last call which I will issue now. Cheers, Adrian --- A reference to draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of UNIs and NNIs. --- There are a few acronyms not expanded on first use, but which are not well-known according to http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I find: LDP LSP (in the abstract) MS-PW NNI OAM UNI --- How long before Requirement 38 shows up on an RFI? --- Section 6 could usefully include a backpointer to section 2.4. --- I like the text in 4.1.1. I wonder where it came from :-) --- Section 4.1.5 might benefit from a reference to RFC 3468 --- Section 4.2.1 could include an informational reference to draft-ietf-mpls-tp-mib-management-overview From iesg-secretary@ietf.org Mon Jan 17 15:12:05 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A78A28C134; Mon, 17 Jan 2011 15:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 q3IongTH0u5V; Mon, 17 Jan 2011 15:12:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38493A6F28; Mon, 17 Jan 2011 15:12:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110117231204.29930.37051.idtracker@localhost> Date: Mon, 17 Jan 2011 15:12:04 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (MPLS-TP Control Plane Framework) to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:12:05 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'MPLS-TP Control Plane Framework' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-cp-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-cp-framework/ No IPR declarations have been submitted directly on this I-D. From lberger@labn.net Tue Jan 18 08:34:44 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F2E28C0D8 for ; Tue, 18 Jan 2011 08:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 90aScpNpVNWs for ; Tue, 18 Jan 2011 08:34:43 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id E6EB83A6FEC for ; Tue, 18 Jan 2011 08:34:42 -0800 (PST) Received: (qmail 2758 invoked by uid 0); 18 Jan 2011 16:37:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 18 Jan 2011 16:37:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=IAVl8/+hl5xYrULVa5Gi0QDBmOAiRQHaDn9b/dy1lyAF7DoPJmp53psuje9yuFRsoVUMP3uWq3reLpTMy3e0x3q/3/joaN20V37MHCbTbGM9cE+6TvFYbdlCrWu6Zzxh; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PfEYa-0001eD-0I; Tue, 18 Jan 2011 09:37:20 -0700 Message-ID: <4D35C1FD.6050805@labn.net> Date: Tue, 18 Jan 2011 11:38:21 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com References: <033401cbb69b$99cdf970$cd69ec50$@huawei.com> In-Reply-To: <033401cbb69b$99cdf970$cd69ec50$@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: 'CCAMP' , draft-ietf-ccamp-mpls-tp-cp-framework@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:34:44 -0000 Adrian, Much thanks for the comments and kind words. See below for specific responses. Let me know if you want an updated rev submitted or the diffs (they're ready now.) Lou On 1/17/2011 6:09 PM, Adrian Farrel wrote: > Hi, > > Don't panic! > > I have performed my AD review of your draft. The purpose of the > review is to catch any nits or issues before the document goes > forward to IETF last call and IESG review. By getting these issues > out at this stage we can hope for a higher quality review and a > smoother passage through the process. > > Cracking draft, thank you. > > I have a number of small editorial comments (below), but considering > their size I think you should simply handle them as part of the > IETF last call which I will issue now. > > Cheers, > Adrian > > --- > > A reference to draft-ietf-mpls-tp-uni-nni might be appropriate to aid > the discussion of UNIs and NNIs. > Sure. > --- > > There are a few acronyms not expanded on first use, but which are not > well-known according to > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I find: > > LDP > LSP (in the abstract) > MS-PW > NNI > OAM > UNI > thanks! > --- > > How long before Requirement 38 shows up on an RFI? > > --- > > Section 6 could usefully include a backpointer to section 2.4. done. > > --- > > I like the text in 4.1.1. I wonder where it came from :-) > > --- > > Section 4.1.5 might benefit from a reference to RFC 3468 > Sure. > --- > > Section 4.2.1 could include an informational reference to > draft-ietf-mpls-tp-mib-management-overview Sure. From Adrian.Farrel@huawei.com Tue Jan 18 14:43:25 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD98428C13C for ; Tue, 18 Jan 2011 14:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=-0.952, 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 p4UFbSvN6rXX for ; Tue, 18 Jan 2011 14:43:25 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D8A6728C11B for ; Tue, 18 Jan 2011 14:43:23 -0800 (PST) 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 <0LF8007YWPWPOW@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 18 Jan 2011 14:46:01 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF800I3MPWNC8@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 18 Jan 2011 14:46:01 -0800 (PST) Date: Tue, 18 Jan 2011 22:45:58 +0000 From: Adrian Farrel To: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org Message-id: <058b01cbb761$7a6fa940$6f4efbc0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu3YOwqC3PBJvGDT7Gwfw1XWWtxwg== Cc: 'CCAMP' Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:43:25 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. Since I did a substantial review after the first WG last call, I don't find much to worry about. There is a broken citation ( s/[GEN-Encode]/[Gen-Encode] ) , but that can be fixed later. I have entered an RFC editor note. It is a shame that the section header and page footer formatting is mangled, and if you produce another version, I urge you to fix this. I will start the IETF last call. Thanks for the work. Adrian From iesg-secretary@ietf.org Tue Jan 18 14:52:44 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B49728C154; Tue, 18 Jan 2011 14:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 cE+HWrAPCsk8; Tue, 18 Jan 2011 14:52:42 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3036628C0FC; Tue, 18 Jan 2011 14:52:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118225242.29329.33926.idtracker@localhost> Date: Tue, 18 Jan 2011 14:52:42 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)) to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:52:44 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-framework/ No IPR declarations have been submitted directly on this I-D. From adrian@olddog.co.uk Wed Jan 19 03:22:08 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5873A6FD4 for ; Wed, 19 Jan 2011 03:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 YfKEVXJhG7-P for ; Wed, 19 Jan 2011 03:22:07 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id EE1B03A6FD3 for ; Wed, 19 Jan 2011 03:22:06 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0JBOa0u013526; Wed, 19 Jan 2011 11:24:37 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p0JBOZs0013522; Wed, 19 Jan 2011 11:24:36 GMT From: "Adrian Farrel" To: "'Lou Berger'" , References: <033401cbb69b$99cdf970$cd69ec50$@huawei.com> <4D35C1FD.6050805@labn.net> In-Reply-To: <4D35C1FD.6050805@labn.net> Date: Wed, 19 Jan 2011 11:24:35 -0000 Message-ID: <06a501cbb7cb$74258090$5c7081b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHc6g991ucfy4yASFptt9WDxavSOQMPcEGtk51HIJA= Content-language: en-gb Cc: 'CCAMP' , draft-ietf-ccamp-mpls-tp-cp-framework@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 11:22:08 -0000 > Much thanks for the comments and kind words. See below for specific > responses. Let me know if you want an updated rev submitted or the > diffs (they're ready now.) Hang on to the changes until the end of IETF last call, then spin an update. A From Adrian.Farrel@huawei.com Wed Jan 19 06:01:45 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9E93A6F30; Wed, 19 Jan 2011 06:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 odtP5p87BPYr; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C2B843A712B; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900547WFBZN@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900JX1WF9G9@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Date: Wed, 19 Jan 2011 14:04:20 +0000 From: Adrian Farrel To: mpls@ietf.org, 'CCAMP' , pce@ietf.org Message-id: <070501cbb7e1$c6436020$52ca2060$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu34bm7+lB0frMlTquX736g5RjMjQ== Cc: l2vpn@ietf.org, itu-t-liaisons@iab.org, rtg-bfd@ietf.org, pwe3@ietf.org, opsawg@ietf.org Subject: [CCAMP] Proposed liaison response on ITU-T Optical transport Network Work Plan X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:01:45 -0000 Hi, We received a liaison "SG15 OTNT standardization work plan" which you can see at https://datatracker.ietf.org/documents/LIAISON/file1054.pdf The document they would like us to review is "Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 13" visible at https://datatracker.ietf.org/documents/LIAISON/file1055.pdf The liaison is addressed CCAMP, PCE, and MPLS, but it falls to me as liaison on the Optical Control Plane to respond. I am copying this email to BFD, OPSAWG, PWE3, and L2VPN as those WGs are explicitly mentioned in the document. A response is requested by February 1, 2011. Here is a draft of what I plan to send. Please send me any comments by January 28. Thanks, Adrian === The IETF thanks you for your liaison COM15-LS204-E received on 2010-06-24 titled "SG15 OTNT standardization work plan", and thanks you for sharing your plans. We have reviewed the document and have a number of comments. In general, it is becoming less and less clear that the title of this document is accurate! SG15 now embraces a number of non-optical transport technologies including Ethernet and MPLS-TP. Although those packet-based technologies can be transmitted over optical links, they are not limited to that medium. Maybe your document should be titled "Transport Networks & Technologies Standardization Work Plan" or maybe you should remove the non-optical material. The scope text in Section 5 and 5.1 might also need revision. The IETF has not position of this, but simply draws the matter to your attention. Table 5-1 We would like to suggest the inclusion of the MPLS Working Group in this table as that working group is responsible for many elements of the support of Ethernet "carrier-class" pseudowires over MPLS and MPLS-TP networks. Section 5.6.1 begins: "MPLS OAM was originally standardized by ITU-T SG13 (Q.5/13)." Although the section goes on to list IETF standardization of MPLS OAM, it may be considered that this first sentence implies that the ITU-T developed MPLS OAM before any MPLS OAM had been developed within the IETF. This would, of course, be a misrepresentation. Therefore, we suggest that you change this first sentence to read: "Within the ITU-T, MPLS OAM was originally standardized by SG13 (Q.5/13)." Table 5-3 Architectural Aspects of MPLS-TP Add RFC 5921, RFC 5950, RFC 5960 Equipment Functional Characteristics of MPLS-TP Add RFC 5960 OAM and Protection Switching of MPLS-TP Add RFC 5860 Management Aspects of MPLS Add RFC 4221 Management Aspects of MPLS-TP Add RFC 5950, RFC 5951 Performance of ATM Add RFC 3116 Performance of MPLS Add RFC 5695 Table 7-1-2 draft-ietf-mpls-tp-framework is now RFC 5921 draft-ietf-mpls-tp-nm-req is now RFC 5951 draft-ietf-mpls-tp-survive-fwk reached revision -06 and has been approved for publication as an RFC draft-ietf-mpls-tp-oam-framework reached revision -10 and has been approved for publication as an RFC draft-ietf-mpls-tp-nm-framework is now RFC 5950 draft-ietf-mpls-tp-rosetta-stone has reached revision -03 draft-ietf-mpls-tp-data-plane is now RFC 5960 draft-ietf-mpls-tp-identifiers has reached revision -03 draft-ietf-mpls-tp-ach-tlv is now abandoned draft-ietf-ccamp-mpls-tp-cp-framework has reached revision -05 Further relevant Internet-Drafts and RFCs can be found at: http://datatracker.ietf.org/wg/ccamp/ http://datatracker.ietf.org/wg/mpls http://datatracker.ietf.org/wg/pwe3 http://datatracker.ietf.org/wg/bfd http://datatracker.ietf.org/wg/pce Table 7-4-2 draft-ietf-gmpls-ason-routing-ospf is now RFC 5787 Table 7-8 should inherit changes to Table 7-1-2 and be updated according to the document status available at the IETF working group pages as listed above. Table 8-1 entry 3. Please be aware of the work on impairment-aware routing in the CCAMP and PCE working groups. (It may be your intention that this is covered under entry 5.) Annex A might usefully refer readers to RFC 4397 and draft-ietf-mpls-tp-rosetta-stone that provide terminology mapping and have been jointly developed by IETF and ITU-T experts. We would welcome it if you shared any future revisions of this work plan with us. Adrian Farrel IETF Liaison to the IETF on the Optical Control Plane Routing Area Director From lufang@cisco.com Wed Jan 19 06:59:55 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC743A714F; Wed, 19 Jan 2011 06:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 BMGE+g8pmweU; Wed, 19 Jan 2011 06:59:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 467733A7149; Wed, 19 Jan 2011 06:59:52 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAC6MNk2tJXG8/2dsb2JhbACCQKIHc6VnmjKFUASEb4lZ Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 19 Jan 2011 15:02:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p0JF2VK7016974; Wed, 19 Jan 2011 15:02:31 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 09:02:31 -0600 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_01CBB7E9.E57B5E7A" Date: Wed, 19 Jan 2011 09:02:29 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25042A8FA5@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS-TP Security Framework Thread-Index: Acu36eRrzBaDX509RzGnFxOXVsTeLw== From: "Luyuan Fang (lufang)" To: "George Swallow (swallow)" , "Loa Andersson" , "Ross Callon" X-OriginalArrivalTime: 19 Jan 2011 15:02:31.0701 (UTC) FILETIME=[E5921450:01CBB7E9] Cc: mpls@ietf.org, CCAMP , Ben Niven-Jenkins Subject: [CCAMP] MPLS-TP Security Framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:59:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB7E9.E57B5E7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Loa, and Ross,=20 =20 In Beijing IETF 79, we presented draft-fang-mpls-tp-security-framework-04, and mentioned that we planned to request for the draft to be adopted as WG document after the meeting. The authors like to thank to everyone who provided helpful comments and the general feedback on the needs of the this work. =20 The authors would like to request MPLS WG to adopt this draft as WG document. =20 Thanks, Luyuan ------_=_NextPart_001_01CBB7E9.E57B5E7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi George, Loa, and Ross,

 

In Beijing IETF 79, we presented draft-fang-mpls-tp-security-framework-04, and mentioned that we = planned to request for the draft to be adopted as WG document after the = meeting.

The authors like to = thank to everyone who provided helpful comments and the general feedback on the = needs of the this work.

 

The authors would = like to request MPLS WG to adopt this draft as WG = document.

 

Thanks,

Luyuan=

------_=_NextPart_001_01CBB7E9.E57B5E7A-- From vijayc@hcl.com Thu Jan 20 05:52:44 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80D23A71AE for ; Thu, 20 Jan 2011 05:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.346 X-Spam-Level: X-Spam-Status: No, score=0.346 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 2KNwBuZmoNke for ; Thu, 20 Jan 2011 05:52:44 -0800 (PST) Received: from gws08.hcl.com (gws08.hcl.com [203.105.186.26]) by core3.amsl.com (Postfix) with ESMTP id 9D1AD3A7217 for ; Thu, 20 Jan 2011 05:52:42 -0800 (PST) Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE4.HCL.COM (10.249.64.141) with Microsoft SMTP Server id 8.2.254.0; Thu, 20 Jan 2011 19:25:15 +0530 Received: from CHN-HCLT-HT03.HCLT.CORP.HCL.IN (10.108.45.35) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Jan 2011 19:25:20 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::3d0d:efa3:3da8:2ae9]) by CHN-HCLT-HT03.HCLT.CORP.HCL.IN ([::1]) with mapi; Thu, 20 Jan 2011 19:25:19 +0530 From: "Vijayanand C - ERS, HCL Tech" To: "ccamp@ietf.org" Date: Thu, 20 Jan 2011 19:25:16 +0530 Thread-Topic: assym biir lsp bandwidth Thread-Index: Acu4qaqhhjvwyza3TCKaT63/B4p1MQ== Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED3E4293DECD@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DECDCHNHCLTEVS07H_" MIME-Version: 1.0 Subject: [CCAMP] assym biir lsp bandwidth X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 13:52:45 -0000 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DECDCHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Which MIB supports bandwidth configuration for assymetric bidirectional LSP= s wherein the bandwidth in both directions is not identical ? The GMPLS TE MIB does not seem to have support for this. Thanks in advance. Regards Vijay ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DECDCHNHCLTEVS07H_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Which MIB supports bandwidth configuration for assym= etric bidirectional LSPs wherein the bandwidth in both directions is not id= entical ?

The GMPLS TE MIB does not seem to have support for t= his.

 

Thanks in advance.

 

Regards=

Vijay


::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DECDCHNHCLTEVS07H_-- From vijayc@hcl.com Thu Jan 20 03:27:26 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A634E3A7219 for ; Thu, 20 Jan 2011 03:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 O5ToZi8Ohqum for ; Thu, 20 Jan 2011 03:27:25 -0800 (PST) Received: from gws07.hcl.com (gws07.hcl.com [203.105.186.23]) by core3.amsl.com (Postfix) with ESMTP id D7B3B3A6FB0 for ; Thu, 20 Jan 2011 03:27:23 -0800 (PST) Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE3.HCL.COM (10.249.64.140) with Microsoft SMTP Server id 8.2.254.0; Thu, 20 Jan 2011 16:59:00 +0530 Received: from CHN-HCLT-HT03.HCLT.CORP.HCL.IN (10.108.45.35) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Jan 2011 17:00:03 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::3d0d:efa3:3da8:2ae9]) by CHN-HCLT-HT03.HCLT.CORP.HCL.IN ([::1]) with mapi; Thu, 20 Jan 2011 17:00:01 +0530 From: "Vijayanand C - ERS, HCL Tech" To: "ccamp@ietf.org" Date: Thu, 20 Jan 2011 16:59:58 +0530 Thread-Topic: bandwidth config for assym bidir LSP Thread-Index: Acu4lV5JCk9HbthSRLaaeQk+8ZbS0Q== Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED3E4293DCC4@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DCC4CHNHCLTEVS07H_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 20 Jan 2011 08:02:35 -0800 Subject: [CCAMP] bandwidth config for assym bidir LSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 11:27:26 -0000 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DCC4CHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Which MIB supports bandwidth configuration for assymetric bidirectional LSP= s wherein the bandwidth in both directions is not identical ? The GMPLS TE MIB does not seem to have support for this. Thanks in advance. Regards Vijay ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DCC4CHNHCLTEVS07H_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Which MIB supports bandwidth configuration for assym= etric bidirectional LSPs wherein the bandwidth in both directions is not id= entical ?

The GMPLS TE MIB does not seem to have support for t= his.

 

Thanks in advance.

 

Regards=

Vijay


::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E4293DCC4CHNHCLTEVS07H_-- From iesg-secretary@ietf.org Mon Jan 24 11:18:03 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2332C3A6B2A; Mon, 24 Jan 2011 11:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 j8kmxTxo5+Kf; Mon, 24 Jan 2011 11:18:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D278128C0EF; Mon, 24 Jan 2011 11:18:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124191801.24973.49905.idtracker@localhost> Date: Mon, 24 Jan 2011 11:18:01 -0800 Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Generalized Labels for Lambda-Switching Capable Label Switching Routers' to Proposed Standard (draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:18:03 -0000 The IESG has approved the following document: - 'Generalized Labels for Lambda-Switching Capable Label Switching Routers' (draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.txt) as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g-694-lambda-labels/ Technical Summary This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. [RFC3471] defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength semantics is not considered. In order to facilitate interoperability in a network composed of lambda switch-capable equipment, this document defines a standard lambda label format, which is compliant with both [G.694.1](DWDM-grid) and [G.694.2](CWDM-grid). Working Group Summary This document received much attention and discussion in its early revisions. The document has been largely stable for quite some time, mainly needing revisions as part of the publication process. Document Quality There have been no public statements related to intent to implement, but the portions of the extensions are now being used as part of the GMPLS tool set and are expected to implemented (at least) in those contexts. The label format and information have been discussed in depth with ITU-T Q6/15 including at a joint meeting. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From Internet-Drafts@ietf.org Mon Jan 24 14:00:03 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E5B3A698E; Mon, 24 Jan 2011 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 3d1kTBRlt70M; Mon, 24 Jan 2011 14:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C3A3A696F; Mon, 24 Jan 2011 14:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124220002.10132.54426.idtracker@localhost> Date: Mon, 24 Jan 2011 14:00:02 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:00:03 -0000 --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 : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-rsvp-te-eth-oam-ext-04.txt Pages : 19 Date : 2011-01-24 The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK].Requirements Language 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-rsvp-te-eth-oam-ext-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-rsvp-te-eth-oam-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24135245.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Jan 27 17:30:07 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1AD3A6B4F; Thu, 27 Jan 2011 17:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 KDoG3dV17Ade; Thu, 27 Jan 2011 17:30:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC283A6B4D; Thu, 27 Jan 2011 17:30:05 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128013005.8074.20422.idtracker@localhost> Date: Thu, 27 Jan 2011 17:30:05 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:30:07 -0000 --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 : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01.txt Pages : 15 Date : 2011-01-27 This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-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-asymm-bw-bidir-lsps-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-27171815.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Mon Jan 31 04:46:19 2011 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC9B3A6BEC; Mon, 31 Jan 2011 04:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 s71+ngA3MBkK; Mon, 31 Jan 2011 04:46:18 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 0737B3A6BF0; Mon, 31 Jan 2011 04:46:18 -0800 (PST) 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 <0LFW002UP0YJHX@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:32 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFW00GBZ0YHV7@usaga01-in.huawei.com>; Mon, 31 Jan 2011 04:49:31 -0800 (PST) Date: Mon, 31 Jan 2011 12:49:30 +0000 From: Adrian Farrel To: statements@ietf.org, greg.jones@itu.int Message-id: <053201cbc145$4ec727d0$ec557770$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvBRUUBwyLJKIqtQ8+sYanHj6pLeA== Cc: itu-t-liaisons@iab.org, pce@ietf.org, 'CCAMP' , mpls@ietf.org Subject: [CCAMP] Liaison to SG15 : Comments on SG15 OTNT standardization work plan X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:46:19 -0000 From: IETF To: ITU-T SG15 (Attention Q3/15) Point of Contact: Greg Jones (greg.jones@itu.int) Cc: Yoshinori Koike (koike.yoshinori@lab.ntt.co.jp) CCAMP Working Group (ccamp@ietf.org) PCE Working Group (pce@ietf.org) MPLS Working Group (mpls@ietf.org) IETF ITU-T Liaisons (itu-t-liaisons@iab.org) Reply To: Adrian Farrel X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702BE3A6A86; Mon, 31 Jan 2011 19:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 905i2IHCtNjT; Mon, 31 Jan 2011 19:01:02 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id E1BB63A68F1; Mon, 31 Jan 2011 19:01:00 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C1AFF17480C4; Tue, 1 Feb 2011 12:04:11 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCUoOU2vrXiT; Tue, 1 Feb 2011 12:04:11 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [IPv6:2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id E65A51748198; Tue, 1 Feb 2011 12:04:08 +0900 (JST) Received: from miyazawaPC (ebisu.kddilabs.jp [IPv6:2001:200:601:11::214]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 382C7578063; Tue, 1 Feb 2011 12:04:05 +0900 (JST) From: "Masanori Miyazawa" To: "'Joan Cucchiara'" , , "'MIB Doctors (E-mail)'" , "'Tomohiro Otani'" , , "'Thomas D. Nadeau'" References: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> In-Reply-To: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> Date: Tue, 1 Feb 2011 12:04:07 +0900 Message-ID: <005b01cbc1bc$b27733c0$17659b40$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuzTjblYmPrL3F6QjW5rXXyAGGNPAOYfF2Q Content-Language: ja Cc: "'Dan Romascanu \(E-mail\)'" Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:01:03 -0000 Hi, Joan Thank you for your review in this doc. According to your comments, I think we will revise the document. Thank you Masanori > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, January 14, 2011 3:16 AM > To: ccamp@ietf.org; MIB Doctors (E-mail); Tomohiro Otani; Masanori > Miyazawa; ke-kumaki@kddilabs.jp; Thomas D. Nadeau > Cc: Joan Cucchiara; Dan Romascanu (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 > > > Hi Masonori, > > Thank you for the new version of this document. There were many good > updates, particularly, the Conformance section. > > Please see following comments. > > Thanks, > -Joan > > > > COMPILER RESULTS > ------------------------------ > * MIB compiles cleanly with smicngPRO > > * MIB compiles cleanly with smiLint > > > DOCUMENT COMMENTS > ------------------------------------- > *) NIT: Does not strip cleanly with smicPRO's mstrip. > (This does not have to be fixed for MIB Dr. purposes, > only mention as an fyi.) > > > *) Author contact info needs to be updated. > > *) Dates and copyright need to be updated > > *) RFC references probably need to be updated. > > RFC3784 was obsoleted by RFC5305 > RFC4205 was obsoleted by RFC5307 > > IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. > > > > > *) 2. Introduction > > Since this document supports both OSPFv2 and OSPFv3, please > say this explicitly. > > *) The following 2 RFCs should be referenced also. > > a. OSPFv3 MIB is defined in rfc5643 > b. TE extensions to OSPFv3 are described in RFC5329 > > > > *) 3.3 Acronyms > > These should be in alphabetical order (or some order that > is defined at the beginning of this subsection.) > > Should include TED: Traffic Engineering Database > > > > *) Section 4. Motivations > > The motivation statement leads one to believe that this > document will provide "for the management of all of the > extensions to the OSPF and ISIS protocol.". > > There are 2 inconsistencies here: > a) Since this is a read-only MIB, (no configuration) then the > statement should be revised because management includes configuration. > b) As previously mentioned, the use of OSPF and then references > to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 > along with relevant documents. > > > *) Section 5.1 > > s/information of/information for/ > > > *) Section 5.3 > > s/This is also independently utilized,because/Also, this is utilized > independently > because/ > > > *) Section 5.4 > > This is referred to as Switch Capable and also > as Switching Capability, please be consistent. If SwCap is > supposed to be Switching Capability, then please use that > Switching Capablity consistently. > > > > > > COMMENTS ON MIB MODULE > -------------------------------------------- > > > *) TEXTUAL-CONVENTIONS > > The names of these TCs are already used in the OSPFv2 MIB > and while this may have been done intentionally, would prefer > a TED specific name. > > For example: > > RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) > > Could these be renamed to be prefixed with "Ted" > and suffixed with "TC", such as TedRouterIdTC" ? > > > > > *) tedCreateDeleteNotificationMaxRate and > tedStatusChangeNotificationMaxRate > > a) Why are these objects not located closer to the Notifications? > > b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION > clause > does not indicate that 0 has a special value (as it does for > tedStatusChangeNotificationMaxRate, > so just want to check on this? Do you really mean 0 here? > > *) tedInfoStatus object > > I think there is still some confusion about my request for status/state > information. > Obviously, if there are rows in these tables, then > the MIB has been configured by some means other than SNMP, and granted > notifications are sent (unless > they are dropped due to throttling or lost), but what is the Operational > Status > link? > > The RowPointer object, tedLinkInformationData, might provide this > information, however, > the DESCRIPTION clause makes it sound completely optional since it looks > like 0.0 > can be entered under any circumstance, so again, I have to ask, how is an > operator > supposed to know if the TE link is acting as intended? > > If tedLinkInformationData is supposed to provide this, then it needs to > be > rewritten to > be mandatory. That means that there are dependencies on other MIBs also. > That is > unclear in this document. > > In summary, tedInfoStatus object does not provide any additional > information, as > I can see if the MIB is populated. What I'm asking for is Operational > Status/State > information. > > > Please discuss. > > > *) tedSwCapSwitchingType > > Please rename to tedSwCapType. > > > > > *) tedNotificationAreaId and tedNotificationRouterId > > Not sure why these are needed. Couldn't you include > an object from the tedTable (such as tedLinkInformationSource) > rather than have these accessible for Notify objects. Seems like > extra work on all parts and not sure I see the advantage when > you already have this info in a table. > > Please discuss. > > > > *) 8. Security Considerations > > s/read-write../read-write./ > > *) 10.1 Normative References > > a) Some of the Informative References should > probably moved to Normative, specifically, any of the MIB > docs that are IMPORTED or appear in a REFERENCE clause. > > > *) 10.2 Informative References > > a) NIT: should be listed in increasing RFC Order. >