Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

[Leeyoung <[e-mail]>]

Hi Acee,

Thanks for your input. Regarding your comment on the overhead increase associated with OSPF retransmission when IP fragmentation/reassembly takes place, we don't foresee the need for IP fragmentation/reassembly in the normal case. 

Young

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Acee Lindem
Sent: Wednesday, November 16, 2011 8:00 AM
To: Leeyoung
Cc: [e-mail]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt

Hi Young, Dirk, 

On Nov 16, 2011, at 12:15 AM, Leeyoung wrote:

> Hi Dirk,
> 
> Thanks for your reply. I think this issue is not unique to this particular case as this is a well-known technique in OSPF. If there is legitimate security issue associated with IP fragmentation/reassembly, this needs to be addressed in OSPF in general.
> 
> Hi Acee,
> 
> What is your take on this security issue?

The rumors of OSPF security problems due to LSAs requiring IP fragmentation/reassembly are greatly exaggerated ;^) 

On a more serious note, the overhead and likelihood of OSPF retransmissions is increased when IP fragmentation/reassembly is necessary. Hence, you want to avoid it in the normal case. 

Thanks,
Acee 



> 
> Thanks.
> Young
> 
> -----Original Message-----
> From: Dirk Schroetter [mailto:[e-mail]]
> Sent: Tuesday, November 15, 2011 11:03 PM
> To: Leeyoung
> Cc: Acee Lindem; [e-mail]
> Subject: Re: [CCAMP] I-D Action: 
> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
> 
> Hi Young,
> 
> While not opposed to the idea, wouldn't that give raise to security concerns for IPv4 and a dependency on the operation of ICMPv6 for IPv6 networks ? I am not a security expert, but I think we should get a view from the security experts on that matter.
> 
> Cheers,
> 
> /Dirk
> 
> Sent from a mobile device. Please excuse any spelling errors.
> 
> Am 16.11.2011 um 10:01 schrieb "Leeyoung" <[e-mail]>:
> 
>> Hi,
>> 
>> After talking to Lou and based on Acee's previous email on the issue on how resolve if the Optical Node Property TLV exceeds the IP MTU fragmentation limit (1500 bytes), I have the following suggestion. If this is reasonable, we will update the draft; otherwise, please voice out in the list.
>> 
>> - I suggest the rule specified (using multiple TE LSA's into which sub-TLV's are broken) in the current draft (Section 3) to be removed.
>> 
>> Current rule specifies in a rare case where the TE-LSA containing the Optical Node Property TLV (in which we specified 5 sub-TLVs) exceeds the IP MTU fragmentation limit, then it will be broken into five multiple TE-LSA's in which each TE-LSA contains a sub-TLV (See Section 3.1 for this in the current draft).
>> 
>> Instead of breaking up, what Acee suggested in the attached previous email was: we can rely on IP fragmentation/reassembly capability in case the LSA needs to be broken up.
>> 
>> The rational for this suggestion is four folds:
>> - Optical Node Property TLV will not exceed the IP MTU limit in a normal node configuration.
>> - Splitting information across multiple LSAs will result in some added complexity.
>> - IP fragmentation/reassembly can be used as a last resort, which is an acceptable method.
>> - This is consistent with the resolution made in the parallel draft (OPSF extension for general constraint, Fatai's).
>> 
>> Thanks.
>> 
>> Young
>> 
>> -----Original Message-----
>> From: Acee Lindem [mailto:[e-mail]]
>> Sent: Friday, October 28, 2011 4:19 PM
>> To: Leeyoung
>> Cc: Andrea Zanardi; [e-mail]
>> Subject: Re: [CCAMP] I-D Action: 
>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>> 
>> Hi Young,
>> 
>> On Oct 27, 2011, at 9:46 AM, Leeyoung wrote:
>> 
>>> Hi Andrea and Acee,
>>> 
>>> What I am proposing is this:
>>> 
>>> In Section 2, we have the following statement:
>>> 
>>> All sub-TLVs defined here may occur at most once in any given 
>>> Optical Node TLV. These restrictions need not apply to future sub-TLVs.
>>> Unrecognized sub-TLVs are ignored.
>>> 
>>> I will change the above statement to the following:
>>> 
>>> All sub-TLVs defined here may occur at most once in any given 
>>> Optical Node TLV. "At most once" means that if there is sub-TLV 
>>> related information, it will be always included. These restrictions 
>>> need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.
>>> 
>>> This statement assures that all the related sub-TLVs are always 
>>> included in any given Optical Node TLV leaving no room not to 
>>> include such sub-TLVs in the Optical Node TLV.
>>> 
>>> In Section 3.2, we have the following statement:
>>> 
>>> In the highly unlikely event that a WSON sub-TLV by itself would 
>>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs 
>>> in this document provide mechanisms that allow them to be subdivided 
>>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
>>> 
>>> I will change the above statement to the following:
>>> 
>>> In the highly unlikely event that a WSON sub-TLV by itself would 
>>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs 
>>> in this document provide mechanisms that allow them to be subdivided 
>>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
>>> 
>>> What is suggested as below is the only option allowed when dividing 
>>> up the current set of sub-TLVs into separate OSPF TE LSAs. This 
>>> means each sub-TLV will be packaged as the sole element in an OSPF 
>>> TE LSA with a unique LSA instance number. When such division is 
>>> implemented, then the source node must flush the existing LSA (i.e., 
>>> the original OSPF TE LSA with all sub-TLV's packaged together as described in Section 2).
>>> This will avoid duplicating the same information being advertised 
>>> across multiple LSAs.
>> 
>> s/LSA instance number/Link State ID/
>> 
>> So, it is not expected that a sub-TLV will exceed the IP MTU and, if it does, we simply rely on IP fragmentation/reassembly as we do in situations where the Router-LSAs and many interfaces in a single area. Correct?
>> 
>> Thanks,
>> Acee
>> 
>>> 
>>> Please let me know if these texts will remove any ambiguity of the 
>>> current Texts.
>>> 
>>> Best Regards,
>>> Young
>>> -----Original Message-----
>>> From: Acee Lindem [mailto:[e-mail]]
>>> Sent: Monday, October 10, 2011 9:18 AM
>>> To: Andrea Zanardi
>>> Cc: Leeyoung; [e-mail]
>>> Subject: Re: [CCAMP] I-D Action: 
>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>> 
>>> Hi Andrea,
>>> On Oct 4, 2011, at 3:03 PM, Andrea Zanardi wrote:
>>> 
>>>> Hi Acee,
>>>> 
>>>> On 10/04/2011 07:03 PM, Acee Lindem wrote:
>>>>> Hi Andrea,
>>>>> 
>>>>> On Oct 4, 2011, at 10:10 AM, Andrea Zanardi wrote:
>>>> ....
>>>>> 
>>>>>> 
>>>>>> My point is in avoiding ambiguities: if the support for multiple 
>>>>>> LSA instances for the same entity top TLV is requested, it should 
>>>>>> be explicitly stated as mandatory (possibly providing explicit rules for the subdivision, as in Chap. 3 of the draft).
>>>>> 
>>>>> There are not multiple instances of the same LSA. Rather they are 
>>>>> unique LSAs, as identified by the (Type, Link State ID, Advertising Router) tuple.
>>>>> In this case, they have different Link State IDs.
>>>>> One thing that is confusing is that RFC 3630 refers to the portion 
>>>>> of the Link State ID providing uniqueness as "Instance".
>>>>> Also note that 
>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt doesn't include any additions to the Link TLV so I'm not sure why you are citing it in discussions of the new top-level TLVs.
>>>> 
>>>> I was replying to Young email providing the Link TLV and RFC 3630 
>>>> as an example of the usage of multiple LSAs and of sending LSA 
>>>> updates with missing sub-TLVs; I was discussing about the 
>>>> correctness of the example, that's why I was citing the Link TLV.
>>> 
>>> Ok.
>>> 
>>>> 
>>>> The usage of the word "instance" is probably not correct.
>>>> 
>>>> What I meant by "multiple LSA instances" was different LSAs (with 
>>>> distinct LS ID and both present in the TE DB at the same time) 
>>>> describing the same entity (e.g. the same link by including the 
>>>> same Link Type / Link ID sub-TLVs) each one providing a subset of the information (e.g. a subset of the other sub-TLVs).
>>>> 
>>>> Considering the draft TLVs, this should be the case of Chap. 3.2.1 "Sub-Division by Options", e.g.:
>>>> two LSAs with a Resource Block Information sub-TLV with the same RB 
>>>> Set Field and different sub-sets of optional sub-sub-TLVs.
>>>> 
>>>> To avoid ambiguities, it should be clear that the options described 
>>>> in Chap. 3 are the only options and that, even if they "can" be 
>>>> used when generating the LSAs, they "must" all be supported when receiving and 'using' the LSAs.
>>> 
>>> Agreed. Splitting information across multiple LSAs will result in some added complexity.
>>> For TLVs or sub-TLVs that are required for a single WSON computation, the WSON path computation must concatenate them when doing that computation.
>>> Today, multiple OSPFv3 Router-LSAs may be originated and implementation MUST use the concatenation when doing the OSPFv3 SPF computation.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Andrea
>>>> 
>>>>> Thanks,
>>>>> Acee
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Andrea
>>>>>> 
>>>>>> On 10/03/2011 09:34 PM, Leeyoung wrote:
>>>>>>> Hi Andrea,
>>>>>>> 
>>>>>>> Thanks for your interest and input to this issue.
>>>>>>> 
>>>>>>> My overall point was that the current GMPLS TE LSA (per RFC 3630) does not specify detail implementations as to how to divide up the TE Link TLVs into static vs. dynamic nor how to use multiple TE LSAs. The current WSON document follows a similar document philosophy with the GMPLS predecessor.
>>>>>>> 
>>>>>>> Regarding your point on how the TE DB works in regard to missing sub-TLVs are deleted seems to me a particular implementation, which is most simplistic in nature.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Young
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>>>>> Behalf Of Andrea Zanardi
>>>>>>> Sent: Monday, October 03, 2011 9:14 AM
>>>>>>> To: Leeyoung
>>>>>>> Cc: [e-mail]
>>>>>>> Subject: Re: [CCAMP] I-D Action: 
>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>> 
>>>>>>> Hi Young,
>>>>>>> 
>>>>>>> I was following the discussion and I have a doubt about your 
>>>>>>> example related to the TE Link TLV.
>>>>>>> 
>>>>>>> It's true that the attributes sub-TLV are not mandatory per RFC 
>>>>>>> 3630, but I don't think that means that they can be not included 
>>>>>>> in an LSA update if unchanged (implying that the previous value persists).
>>>>>>> 
>>>>>>> As for my understanding of how OSPF-TE works, the managed TE DB entity is the LSA.
>>>>>>> When an LSA update is processed, the previous version is deleted 
>>>>>>> from the TE DB and it is replaced by the new one: link 
>>>>>>> attributes related to missing sub-TLV are deleted, so they must be present even if unchanged.
>>>>>>> 
>>>>>>> In theory, the set of link attributes could be statically 
>>>>>>> divided in two different LSAs instances (updated independently), 
>>>>>>> but I don't think current implementations handle this scenario 
>>>>>>> (also because, in my opinion, it's not suggested by RFC 3630 and 
>>>>>>> it gives no rule on how to divide them).
>>>>>>> 
>>>>>>> But I ask to the mailing list if this is the correct interpretation.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Andrea
>>>>>>> 
>>>>>>> On 09/30/2011 11:16 PM, Leeyoung wrote:
>>>>>>>> Hi Pierre,
>>>>>>>> 
>>>>>>>> I got your point. Let me ask you this question. In the current GMPLS OSPF TE Link TLV are defined under Opaque TE LSA with the following attributes:
>>>>>>>> 
>>>>>>>> - TE Metric
>>>>>>>> - max B/W
>>>>>>>> - max reservable b/w
>>>>>>>> - unreserved b/w
>>>>>>>> - Admin Group
>>>>>>>> - Link Protection Type
>>>>>>>> - SRLG
>>>>>>>> - ISCD
>>>>>>>> - etc.
>>>>>>>> 
>>>>>>>> And these are a mixture of static and dynamic information and yet they are assembled together as one TE Link TLV. For instance the ISCD is quite similar to Resource Block Info in that it does not change often unless there are new elements added in the node or configuration changes and yet it is packaged together with other dynamic information.
>>>>>>>> 
>>>>>>>> Why?
>>>>>>>> 
>>>>>>>> There are many ways to keep static/unchanged information from being flooded. Only the Link Type and Link ID which are mandatory in the TE Link TLV per RFC3630. All other sub-TLV are optional and may occur at most once (when there are enough changes from the previous period that deserve an update) and need not be included in the TE Link TLV when there is no need for updating.
>>>>>>>> 
>>>>>>>> I really don't see the need for a separate top-level TLV and/or a separate LSA for the Resource Block information.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Young
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: PELOSO, PIERRE (PIERRE) 
>>>>>>>> [mailto:[e-mail]]
>>>>>>>> Sent: Friday, September 30, 2011 9:39 AM
>>>>>>>> To: Leeyoung; [e-mail]
>>>>>>>> Subject: RE: [CCAMP] I-D Action: 
>>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>>> 
>>>>>>>> Hi Young,
>>>>>>>> 
>>>>>>>> I understand the content of your answer, but I'm not satisfied with it.
>>>>>>>> My concern deals with providing a unique reading/interpretation of the OSPF-TE extensions.
>>>>>>>> We would like to make sure that any implementation complying to the drafts would provide the same LSAs when applied to the same network.
>>>>>>>> With this perspective in mind, we wish to get drafts with sufficient documentation to make sure the LSA design process to be depicted, by design rules.
>>>>>>>> 
>>>>>>>> Hence the content of your answer leaving me the "opportunity to do as I wish", is not pleasing me, I would rather have strict rules, and discussions with the WG on the design of those.
>>>>>>>> That is why a first design rule, we could agree on is: to gather the Resource Block Information TLVs inside a dedicated LSA, possibly with a dedicated top-level TLV (which in my mind allows to enforce this design rule).
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> - Pierre
>>>>>>>> 
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : Leeyoung [mailto:[e-mail]] Envoyé : mercredi 28 
>>>>>>>> septembre 2011 00:06 À : PELOSO, PIERRE (PIERRE); 
>>>>>>>> [e-mail] Objet : RE: [CCAMP] I-D Action: 
>>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>>> 
>>>>>>>> Hi Pierre,
>>>>>>>> 
>>>>>>>> Please see-inline for my reply to your first point.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Young
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: PELOSO, PIERRE (PIERRE) 
>>>>>>>> [mailto:[e-mail]]
>>>>>>>> Sent: Tuesday, September 27, 2011 3:28 AM
>>>>>>>> To: Leeyoung; [e-mail]
>>>>>>>> Subject: RE: [CCAMP] I-D Action: 
>>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>>> 
>>>>>>>> Hi Young, and CCAMPers,
>>>>>>>> 
>>>>>>>> I was off the mailing lists for the last two weeks and being back I notice a lot of exchanges, which I'm very glad of.
>>>>>>>> I've also noticed many drafts have been updated.
>>>>>>>> Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06, I wanted to comment section 3.
>>>>>>>> Back in Quebec, I expressed my point of view (shared with Cyril, Julien and Giovanni) that current drafts were lacking guidance regarding the way to design LSAs that were to depict an WSON node with OEOs.
>>>>>>>> This section 3 provides additional material to help designing the LSA.
>>>>>>>> I would like to know whether authors are willing to pursue further in this direction, which is to my mind a real corner stone, that would help everyone agree on a solution.
>>>>>>>> A first point could concern the Resource Block Information (reminder:<ResourceBlockInfo>    ::= ([<ResourceSet>]<InputConstraints>    <ProcessingCapabilities>    <OutputConstraints>):
>>>>>>>>    We all agree that these information are static, that we should not replicate this TLV whatever the number not the layout of OEO boards of a given type.
>>>>>>>> Then, we could dedicate a specific independant flooding entity. This would be defined once for all, and that would not leave room to different interpretations.
>>>>>>>> What about this first point?
>>>>>>>> 
>>>>>>>> YOUNG>>    If I understand you correctly, what you are saying is since the Resource Block Info sub-TLV is very static in nature, advertisement of this sub-TLV should be treated differently from the rest of static-TLVs (which may change over time). Is this what you are saying?
>>>>>>>> 
>>>>>>>> If my interpretation of your comment is correct,
>>>>>>>> 
>>>>>>>> - The current mechanism allows what you want: Please see the 
>>>>>>>> first paragraph in Section 3.2  "In the highly unlikely event 
>>>>>>>> that a WSON sub-TLV by itself would  result in an LSA exceeding 
>>>>>>>> the MTU, all five WSON specific sub-TLVs  in this document 
>>>>>>>> provide mechanisms that allow them to be subdivided  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."
>>>>>>>> 
>>>>>>>> According to this clause, you can separate the Resource Block 
>>>>>>>> Info Sub-TLV as the sole entry defined in the Optical Node 
>>>>>>>> property TLV in a separate TE LSA from the rest if you will. 
>>>>>>>> Nothing prevents this particular way of packaging. (Isn't this 
>>>>>>>> what you meant "a specific independent flooding entity"?)
>>>>>>>> 
>>>>>>>> - Please let me know if this explanation satisfies you. Thanks 
>>>>>>>> --- Young
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> Pierre
>>>>>>>> 
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : [e-mail] [mailto:[e-mail]] De 
>>>>>>>> la part de Leeyoung Envoyé : jeudi 15 septembre 2011 21:59 À : 
>>>>>>>> [e-mail] Objet : Re: [CCAMP] I-D Action: 
>>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> After 05 version publication, Acee provided a number of valuable comments and suggestions. This revision (06) reflects those changes. Please note the following updates:
>>>>>>>> 
>>>>>>>> - Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rather than the base OSPF.
>>>>>>>> 
>>>>>>>> - Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] and editorial change including avoiding "multiple instances of TE LSA" to "multiple TE LSAs".
>>>>>>>> 
>>>>>>>> Your comments are always appreciated. Thanks.
>>>>>>>> 
>>>>>>>> Best Regards.
>>>>>>>> Young
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>>>>>> Behalf Of [e-mail]
>>>>>>>> Sent: Thursday, September 15, 2011 2:48 PM
>>>>>>>> To: [e-mail]
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: [CCAMP] I-D Action: 
>>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.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           : GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
>>>>>>>>  Author(s)       : Young Lee
>>>>>>>>                         Greg M. Bernstein
>>>>>>>>  Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
>>>>>>>>  Pages           : 14
>>>>>>>>  Date            : 2011-09-15
>>>>>>>> 
>>>>>>>>  This document provides GMPLS OSPF routing enhancements to 
>>>>>>>> support  signal compatibility constraints associated with WSON 
>>>>>>>> network  elements. These routing enhancements are required in 
>>>>>>>> common optical  or hybrid electro-optical networks where not 
>>>>>>>> all of the optical  signals in the network are compatible with 
>>>>>>>> all network elements  participating in the network.
>>>>>>>> 
>>>>>>>>  This compatibility constraint model is applicable to common 
>>>>>>>> optical  or hybrid electro optical systems such as OEO 
>>>>>>>> switches, regenerators,  and wavelength converters since such 
>>>>>>>> systems can be limited to  processing only certain types of WSON signals.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> A URL for this Internet-Draft is:
>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signa
>>>>>>>> l-compatibility-ospf-06.txt
>>>>>>>> 
>>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>>> 
>>>>>>>> This Internet-Draft can be retrieved at:
>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal
>>>>>>>> -compatibility-ospf-06.txt 
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> --------------------------------------------------------
>>>>>> Andrea Zanardi
>>>>>> CREATE-NET
>>>>>> Engineering&  Fast Prototyping (ENGINE) Area Senior Engineer Via 
>>>>>> alla Cascata 56/D - 38123 Povo Trento (Italy)
>>>>>> e-mail: [e-mail]
>>>>>> Tel: [phone] - interno/extension 1407
>>>>>> Mobile: [phone]
>>>>>> Fax: [phone]
>>>>>> Skype: zanardi_andrea
>>>>>> www.create-net.org
>>>>>> --------------------------------------------------------
>>>>>> 
>>>>>> The information transmitted is intended only for the person or 
>>>>>> entity to which it is addressed and may contain confidential 
>>>>>> and/or privileged material. Any review, retransmission, 
>>>>>> dissemination or other use of, or taking of any action in 
>>>>>> reliance upon, this information by persons or entities other than 
>>>>>> the intended recipient is prohibited according to the Italian Law 
>>>>>> 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer.
>>>>>> 
>>>>>> Le informazioni contenute in questo messaggio di posta 
>>>>>> elettronica e nei file allegati sono da considerarsi strettamente 
>>>>>> riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita'
>>>>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio 
>>>>>> senza esserne il destinatario, Vi preghiamo cortesemente di 
>>>>>> darcene notizia via e-mail e di procedere alla cancellazione del 
>>>>>> messaggio stesso dal Vostro sistema. Trattenere il messaggio 
>>>>>> stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita'
>>>>>> diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs.
>>>>>> 196/2003.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> --------------------------------------------------------
>>>> Andrea Zanardi
>>>> CREATE-NET
>>>> Engineering & Fast Prototyping (ENGINE) Area Senior Engineer Via 
>>>> alla Cascata 56/D - 38123 Povo Trento (Italy)
>>>> e-mail: [e-mail]
>>>> Tel: [phone] - interno/extension 1407
>>>> Mobile: [phone]
>>>> Fax: [phone]
>>>> Skype: zanardi_andrea
>>>> www.create-net.org
>>>> --------------------------------------------------------
>>>> 
>>>> The information transmitted is intended only for the person or 
>>>> entity to which it is addressed and may contain confidential and/or 
>>>> privileged material. Any review, retransmission, dissemination or 
>>>> other use of, or taking of any action in reliance upon, this 
>>>> information by persons or entities other than the intended 
>>>> recipient is prohibited according to the Italian Law 196/2003 of 
>>>> the Legislature. If you received this in error, please contact the sender and delete the material from any computer.
>>>> 
>>>> Le informazioni contenute in questo messaggio di posta elettronica 
>>>> e nei file allegati sono da considerarsi strettamente riservate. Il 
>>>> loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita'
>>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio 
>>>> senza esserne il destinatario, Vi preghiamo cortesemente di darcene 
>>>> notizia via e-mail e di procedere alla cancellazione del messaggio 
>>>> stesso dal Vostro sistema. Trattenere il messaggio stesso, 
>>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita'
>>>> diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs.
>>>> 196/2003.
>>>> 
>>> 
>> 
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>