Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

[Lou Berger <[e-mail]>]

Daniele,
	I agree we have conflicting precedent.  I also agree we should try to
quickly make a decision on this.  I think we should make a 'generalized'
and 'common control' consensus call and not a (OTN) technology specific
call, so we don't have to revisit this for the next technology.

Lou

On 12/12/2011 5:30 AM, Daniele Ceccarelli wrote:
> Hi all,
> 
> I think whatever we do we are not consisted with what have been done
> up to now. If we define multiple values of switching capability we're
> no longer consistent with the SDH switching capability case, while on
> the other hand if we use a single value we're no longer consistent
> with the PSC case, so from this point of view I think the issue can't
> be solved.
> 
> Hence I'd prefer to keep a single OTN value for the same reasons
> already expressed by John.
> 
> Thanks
> Daniele
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Lou Berger
>> Sent: giovedì 8 dicembre 2011 16.16
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82
>> (Issue 1/2)
>>
>> John,
>>       As I'm sure you are aware, hierarchy within the same
>> technology layer has been around for a while.  When we defined
>> GMPLS, there was a desire to represent level of hierarchy
>> within a switching technology.  (This requirement came in the
>> context of PSC).  At the time we choose to represent both
>> switching switching technology and level of hierarchy (within
>> the technology) in the SC field.
>>
>> On one hand one can argue (as was our thinking at the time)
>> that there was only a need to represent a few per-technology
>> hierarchies and that it simplified GMPLS routing to operate on
>> a minimum number of generic
>> fields.   On the other hand, one could argue that the SC field should
>> not be overloaded and there should be a separate
>> per-technology hierarchy indicator field.  Hindsight leaves me
>> feeling that the latter choice may have been the better one.
>> I don't recall exactly how we came to this conclusion, but
>> there were lots or related discussions among the
>> authors/editors (which includes you too!).  My bet is that it
>> came from Yakov, myself or Peter... Perhaps your memory is
>> better than mine, but either way please feel free to blame me ;-)
>>
>> No matter what, you now raise a good question.  Where do we go
>>from here?
>> a. Keep SC as it is, with it's overloaded semantics as both a
>>   common (across technologies) label/ISCD type indicator and
>>   intra-type hierarchy indicator.
>> b. Deprecate use of SC as an intra-type hierarchy indicator, and
>>   add such indication to technology-specific ISCDs.
>> c. Something else.
>>
>> I (and I believe Julien) are proposing (a), I believe you and
>> the OTN co-authors are proposing/implying (b).
>>
>> Lou
>>
>> On 12/7/2011 8:21 AM, John E Drake wrote:
>>> Hi,
>>>
>>> I am unaware of any requirement to indicate layers in a multi-layer
>>> scenario - I went back and looked at both RFC5339 and RFC6001 and
>>> didn't see anything.  And just to be clear, layers are technology
>>> specific.
>>>
>>> Since you mention RFC6001, I think it should be pointed out
>> that that
>>> RFC does not address multi-layer networking, but only multi-region
>>> networking.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]]
>>>> Sent: Tuesday, December 06, 2011 12:29 PM
>>>> To: Zhangfatai
>>>> Cc: Julien Meuric; John E Drake; CCAMP
>>>> Subject: Re: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>>>> 1/2)
>>>>
>>>>
>>>> I think Julien has it right (and as I've said on this list), it's a
>>>> question of leveraging or deprecating the use of SC as an indicator
>>>> of hierarchy.  Deprecating this use means that we need to
>> move into a
>>>> technology specific hierarchy indicator, which is what
>> you're saying
>>>> ST provides.
>>>>
>>>> The move from generic to technology-specific mechanisms,
>> really runs
>>>> counter to the basic principals of GMPLS and is likely to have some
>>>> nasty ripple effects.  (For example do we just obsolete
>> 6001, or do a
>>>> bis which allows for / requires carrying the technology-specific
>>>> layer
>>>> identifier?)
>>>>
>>>> Lou
>>>>
>>>> On 12/6/2011 2:34 PM, Zhangfatai wrote:
>>>>> Hi Julien,
>>>>>
>>>>> For TDM networks, Signal Type has beed introduced in RFC4606 or
>>>> RFC4328 or G.709V3 drafts to address what you need.
>>>>>
>>>>> Anything is missed in routing or signaling?
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Fatai
>>>>>
>>>>>
>>>>> _______________________________________
>>>>> 发件人: [e-mail] [[e-mail]] 代表 Julien
>>>> Meuric [[e-mail]]
>>>>> 发送时间: 2011年12月6日 23:31
>>>>> 到: John E Drake; Lou Berger
>>>>> Cc: CCAMP
>>>>> 主题: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>>>>
>>>>> Hi John, hi Lou.
>>>>>
>>>>> On the one hand, SONET/SDH and OTN are close: it is highly tempting
>>>> to
>>>>> prolong control of the former to the latter. Nevertheless,
>> the GMPLS
>>>>> deployments on SONET/SDH I am aware of only control high order
>>>>> containers (i.e. SDH VC-4/VC-4-nc or SONET
>> STS-1/STS-1-nc). In that
>>>>> context, I do not think we can easily generalized protocol
>>>>> extensions from an almost single-stage control to a highly
>> multi-stage control.
>>>>>
>>>>> On the other hand, it seems that PSC-1 to PSC-4 have not been
>>>>> implemented much. Reasons behind are only guesses. Mine is that
>>>>> upgrading implementations and deployments of MPLS-TE was not worth
>>>> the
>>>>> pain with respect to the added value of moving to the GMPLS flavor
>>>>> of IGPs and RSVP-TE (especially for packet-only operations).
>>>>> Whatever
>>>> the
>>>>> actual reason for having so few implementations, PSC-n are part of
>>>> the
>>>>> original GMPLS specification.
>>>>>
>>>>> Let me quote the section about PSC in RFC 4202: "The various levels
>>>> of
>>>>> PSC establish a hierarchy of LSPs tunneled within LSPs."
>> This really
>>>>> looks like what we are doing in OTN. Yes, the discrete
>> nature of the
>>>>> technology will introduce one more information into the SC field,
>>>>> but doing otherwise would depreciate existing GMPLS specification.
>>>>>
>>>>> Furthermore, RFC 4203 says: "When the Switching Capability field is
>>>> TDM,
>>>>> the Switching Capability specific information field
>> includes Minimum
>>>> LSP
>>>>> Bandwidth..." In other words, even if not included in the SC field
>>>>> so far, one cannot really say that a value per ODUk layer would
>>>>> overload the ISCD definition.
>>>>>
>>>>> Thus, we have legacy vs. depreciation: my understanding of
>> IETF work
>>>> is
>>>>> to put emphasis on consistency and avoid defining new
>> solutions when
>>>>> they already exist, even if not absolutely optimized (we are not
>>>>> building G.709 control from scratch).
>>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 30/11/2011 22:37, John E Drake a écrit :
>>>>>>  Comments inline. I still think this is a terrible idea
>> and I would
>>>>>> like to see what the rest of the WG thinks.
>>>>>>
>>>>>>> -----Original Message----- From: Lou Berger
>>>>>>> [mailto:[e-mail]]
>>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> see below
>>>>>>>
>>>>>>>
>>>>>>> On 11/30/2011 2:59 PM, John E Drake wrote:
>>>>>>>> Using Switching Capability to indicate link bandwidth seems
>>>>>>>> ill-considered at best, especially since this information is
>>>>>>>> carried in other fields, and as Daniele noted, it significantly
>>>>>>>> overloads to intended meaning of Switching Capability.
>>>>>>>
>>>>>>> I agree with the point on BW, but my point was related to the
>>>>>>> layer&hierarchy implications of the different ODUk values. I'd
>>>>>>> think that using values that are TDM-1 -> TDM-n should make this
>>>>>>> clear and remove any ambiguity related to bandwidth. It is also
>>>>>>> completely consistent with the base GMPLS definition, i.e., PSC-1
>>>>>>> -> PSC-n.
>>>>>>
>>>>>>  [JD] You are simply asserting that this is a good idea
>> and further
>>>>>> asserting that there is "ambiguity related to bandwidth',
>> without
>>>>>> providing any evidence.
>>>>>>
>>>>>>  To the best of my knowledge no one ever implemented or deployed
>>>>>> the
>>>>>>  PSC-1 -> PSC-4 hierarchy, simply because no one could figure out
>>>> what
>>>>>>  it meant. To quote from you, below, "Well hopefully we have a
>>>> better
>>>>>>  understanding of the technologies involved than we had in the
>>>> past.".
>>>>>>  I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea
>>>>>>  (tm) and move on.
>>>>>>
>>>>>>>
>>>>>>>> It also is inconsistent with the usage of Switching
>> Capability in
>>>>>>>> SDH/SONET.
>>>>>>>
>>>>>>> Well hopefully we have a better understanding of the
>> technologies
>>>>>>> involved than we had in the past.
>>>>>>
>>>>>>  [JD] I think we had a very good understanding of SDH/SONET then
>>>>>> and  we have a very good understanding of OTN now, and in both
>>>>>> cases the  authors saw no requirement to overload switching
>>>>>> capability in the  manner you are suggesting.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> A more extensive quote from RFC4202 is the following,
>> which seems
>>>>>>>> clear enough to me:
>>>>>>>>
>>>>>>>> "In the context of this document we say that a link is
>> connected
>>>>>>>> to a node by an interface. In the context of GMPLS
>> interfaces may
>>>>>>>> have different switching capabilities. For example an interface
>>>>>>>> that connects a given link to a node may not be able to switch
>>>>>>>> individual packets, but it may be able to switch
>> channels within
>>>>>>>> an SDH payload. Interfaces at each end of a link need not have
>>>>>>>> the same switching capabilities. Interfaces on the same
>> node need
>>>>>>>> not have the same switching capabilities."
>>>>>>>
>>>>>>> Not sure how this helps clarify anything...
>>>>>>
>>>>>>  [JD] I think it clarifies that switching capabilities is
>> meant to
>>>>>> describe how a given interface switches the information with which
>>>> it
>>>>>>  is provided. This has nothing to do with the interface's
>> bandwidth.
>>>>>>
>>>>>>>
>>>>>>> Lou
>>>>>>>>
>>>>>>>>> -----Original Message----- From: Lou Berger
>>>>>>>>> [mailto:[e-mail]] Sent: Wednesday, November 30, 2011
>>>>>>>>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject:
>>>>>>>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>>>>>>> 1/2)
>>>>>>>>>
>>>>>>>>> Great. Care to substantiate your point?
>>>>>>>>>
>>>>>>>>> On 11/30/2011 11:14 AM, John E Drake wrote:
>>>>>>>>>> I completely disagree.
>>>>>>>>>>
>>>>>>>>>>> -----Original Message----- From: [e-mail]
>>>>>>>>>>> [mailto:[e-mail]] On
>>>>>>>>> Behalf
>>>>>>>>>>> Of Lou Berger Sent: Wednesday, November 30, 2011 7:22 AM
>>>>>>>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re:
>> [CCAMP] OSPF OTN
>>>>>>>>>>> considerations post IETF 82 (Issue
>>>>>>>>> 1/2)
>>>>>>>>>>>
>>>>>>>>>>> Hi Daniele, Since I raised the point, I guess I need to
>>>>>>>>>>> champion it! (With chair hat off.)
>>>>>>>>>>>
>>>>>>>>>>> All,
>>>>>>>>>>>
>>>>>>>>>>> Daniele said:
>>>>>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most
>>>>>>>>>>>> ODUk of
>>>>>>>>> the
>>>>>>>>>>>> muxing hiearachy in the Switching Capability field of the
>>>>>>>>>>>> ISCD.
>>>>>>>>> After
>>>>>>>>>>>> a quick talk with the other authors of the ID, the idea was
>>>>>>>>>>>> to
>>>>>>>>> reject
>>>>>>>>>>>> the proposal as it would lead to an overloading of the
>>>>>>>>>>>> meaning of
>>>>>>>>> the
>>>>>>>>>>>> Switching Capability field. (even if the definition of
>>>>>>>>>>>> PSC1-2-3-4 already overloads the meaning of the switching
>>>>>>>>>>>> capability field)
>>>>>>>>>>>
>>>>>>>>>>> This really goes to the interpretation of the intent of
>>>>>>>>>>> Switching Capability Types. So we have a few definitions:
>>>>>>>>>>> 3471 says "the
>>>>>>> type
>>>>>>>>> of
>>>>>>>>>>> switching that should be performed", 4202 says "describes
>>>>>>> switching
>>>>>>>>>>> capability of an interface." 3945 doesn't really define the
>>>>>>>>>>> term
>>>>>>> (it
>>>>>>>>>>> just references 4202), but does equate it with a "layer".
>>>>>>>>>>> While it allows for hierarchy within a "layer" it also says
>>>>>>>>>>> hierarchy
>>>>>>> occurs
>>>>>>>>>>> "between interface types".
>>>>>>>>>>>
>>>>>>>>>>> So I interpret Switching Capability Types to represent (a)
>>>>>>> different
>>>>>>>>>>> switching/technology layers and (b) different levels of
>>>>>>>>>>> hierarchy
>>>>>>> --
>>>>>>>>>>> even within a layer. I think (a) is identifiable in the
>>>>>>> definition
>>>>>>>>> of
>>>>>>>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC,
>>>>>>>>>>> TDM
>>>>>>> LSC,
>>>>>>>>>>> and FSC), and (b) is identifiable in the original types plus
>>>>>>>>>>> the
>>>>>>>>> definition
>>>>>>>>>>> of PSC-1 through PSC-4.
>>>>>>>>>>>
>>>>>>>>>>> So how does this apply to our current OTN work?
>>>>>>>>>>>
>>>>>>>>>>> To me, the first question to ask relates to (a), and
>> is should
>>>>>>> each
>>>>>>>>>>> ODUk be modeled as a separate layer?
>>>>>>>>>>>
>>>>>>>>>>> I know this has been a much debated point, and it
>> seems to me
>>>>>>>>>>> that
>>>>>>>>> they
>>>>>>>>>>> are, but more for the perspective of switching layers than
>>>>>>>>> technology
>>>>>>>>>>> layers (i.e., they are clearly the same technology but are
>>>>>>> different
>>>>>>>>>>> granularity of swicthing.) So this is a yes for me.
>>>>>>>>>>>
>>>>>>>>>>> I think the second question to ask relates to (b),
>> and is does
>>>>>>> each
>>>>>>>>>>> ODUk represent a different level of hierarchy?
>>>>>>>>>>>
>>>>>>>>>>> I see this as simply yes, and no different than what
>> has been
>>>>>>>>>>> done
>>>>>>>>> more
>>>>>>>>>>> recently with Ethernet or, even if we do continue to
>> model OTN
>>>>>>>>>>> as
>>>>>>> a
>>>>>>>>>>> single layer, no different than PSC-1 -> PSC-4.
>>>>>>>>>>>
>>>>>>>>>>> There's also a minor processing efficiency gained by this
>>>>>>>>>>> approach
>>>>>>>>> for
>>>>>>>>>>> nodes that support a smaller set of ODUks than are advertised
>>>>>>> within
>>>>>>>>> an
>>>>>>>>>>> IGP.
>>>>>>>>>>>
>>>>>>>>>>> Based on all this, I believe different ODUk's should use
>>>>>>>>>>> different Switching Types. In particular, I'm proposing:
>>>>>>>>>>> (1) that either the framework or info documents
>> identify that
>>>>>>>>>>> a per-OTUk Switching Capability Types will be used
>> to support
>>>>>>>>>>> G.709v3. (2) that
>>>>>>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3 define a different
>>>>>>>>>>> Switching Cap field value for each ODUk, and that it state
>>>>>>>>>>> that the value corresponding to the signal type
>> identified in
>>>>>>>>>>> the #stages=0 of the ISCP be set. (Without any other changes
>>>>>>>>>>> to the current definition of ISCD.) (3) that
>>>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to match
>>>>>>>>>>> above.
>>>>>>>>>>>
>>>>>>>>>>> To keep thinks generic, we probably should use TDM-1 through
>>>>>>>>>>> TDM-n
>>>>>>>>> as
>>>>>>>>>>> the new Switching Capability Types, but this is a secondary
>>>>>>>>> discussion.
>>>>>>>>>>>
>>>>>>>>>>> Comments?
>>>>>>>>>>>
>>>>>>>>>>> Lou
>>>>>>>>>>>
>>>>>>>>>>> PS While the above is an important change, it doesn't
>>>>>>> significantly
>>>>>>>>>>> impact encoding and won't take much text to make the
>>>>>>>>>>> actual
>>>>>>> change,
>>>>>>>>> so
>>>>>>>>>>> this is a discussion that can continue until Paris if we
>>>>>>>>>>> really
>>>>>>> need
>>>>>>>>> a
>>>>>>>>>>> face to face to resolve the discussion.
>>>>>>>>>>>
>>>>>>>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote:
>>>>>>>>>>>> Hi CCAMP,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> During the OTN OSPF draft presentation at the IETF
>>>>>>>>>>>> meeting in
>>>>>>>>> Taipei
>>>>>>>>>>> two
>>>>>>>>>>>> comments were raised with respect to the following
>>>>>>>>>>>> issues:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - Issue 1: Using different switching caps for each ODU
>>>>>>>>>>>> type
>>>>>>>>>>>>
>>>>>>>>>>>> - Issue 2: Type 2 (unres bandwidth for variable
>>>>>>>>>>>> containers) and
>>>>>>>>> Type
>>>>>>>>>>> 3
>>>>>>>>>>>> (MAX LSP bandwidth foe variable containers always used in
>>>>>>>>>>>> tandem?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most
>>>>>>>>>>>> ODUk of
>>>>>>>>> the
>>>>>>>>>>>> muxing hiearachy in the Switching Capability field of the
>>>>>>>>>>>> ISCD.
>>>>>>>>> After
>>>>>>>>>>> a
>>>>>>>>>>>> quick talk with the other authors of the ID, the idea was
>>>>>>>>>>>> to
>>>>>>> reject
>>>>>>>>>>> the
>>>>>>>>>>>> proposal as it would lead to an overloading of the
>>>>>>>>>>>> meaning of the Switching Capability field. (even if the
>>>>>>>>>>>> definition of PSC1-2-3-4 already overloads the meaning of
>>>>>>>>>>>> the switching capability field)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft
>>>>>>>>>>>> (version
>>>>>>> -
>>>>>>>>>>> 00).
>>>>>>>>>>>> I'm copying it below for your convenience
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In this example the advertisement of an ODUflex->ODU3
>>>>>>> hierarchy
>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> shown. In case of ODUflex advertisement the MAX LSP
>>>>>>>>>>>> bandwidth
>>>>>>>>>>> needs
>>>>>>>>>>>>
>>>>>>>>>>>> to be advertised but in some cases also information about
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> Unreserved bandwidth could be useful. The amount of
>>>>>>> Unreserved
>>>>>>>>>>>>
>>>>>>>>>>>> bandwidth does not give a clear indication of how many
>>>>>>>>>>>> ODUflex
>>>>>>>>> LSP
>>>>>>>>>>>>
>>>>>>>>>>>> can be set up either at the MAX LSP Bandwidth or at
>>>>>>>>>>>> different
>>>>>>>>>>> rates,
>>>>>>>>>>>>
>>>>>>>>>>>> as it gives no information about the spatial allocation
>>>>>>>>>>>> of the
>>>>>>>>>>> free
>>>>>>>>>>>>
>>>>>>>>>>>> TSs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> An indication of the amount of Unreserved bandwidth could
>>>>>>>>>>>> be
>>>>>>>>>>> useful
>>>>>>>>>>>>
>>>>>>>>>>>> during the path computation process, as shown in the
>>>>>>>>>>>> following
>>>>>>>>>>>>
>>>>>>>>>>>> example. Supposing there are two TE-links (A and B) with
>>>>>>>>>>>> MAX
>>>>>>>>> LSP
>>>>>>>>>>>>
>>>>>>>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of
>>>>>>>>>>>> Unreserved
>>>>>>>>>>>>
>>>>>>>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and
>>>>>>>>>>>> 3
>>>>>>>>> ODUflex
>>>>>>>>>>>>
>>>>>>>>>>>> LSPs of 10 GBps each, have to be restored, for sure only
>>>>>>>>>>>> one
>>>>>>> can
>>>>>>>>>>> be
>>>>>>>>>>>>
>>>>>>>>>>>> restored along Link B and it is probable (but not sure)
>>>>>>>>>>>> that
>>>>>>> two
>>>>>>>>>>> of
>>>>>>>>>>>>
>>>>>>>>>>>> them can be restored along Link A.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Early proposal was to have, in the case of variable
>>>>>>>>>>>> containers advertisements (i.e. ODUflex), the MAX LSP
>>>>>>>>>>>> bandwidth TLV (Type 3)
>>>>>>>>> as
>>>>>>>>>>> a
>>>>>>>>>>>> mandatory piece of information and the Unreserved
>>>>>>>>>>>> bandiwdth TLV
>>>>>>>>> (Type
>>>>>>>>>>> 2)
>>>>>>>>>>>> as an optional piece of information.
>>>>>>>>>>>>
>>>>>>>>>>>> The comment received is that optional information can
>>>>>>>>>>>> lead to interworking issues and the counter proposal was
>>>>>>>>>>>> to have both
>>>>>>>>> pieces
>>>>>>>>>>> of
>>>>>>>>>>>> information as mandatory and, as a consequence, merge the
>>>>>>>>>>>> two
>>>>>>> TLVs
>>>>>>>>>>> into
>>>>>>>>>>>> a single one.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We'd like to hear the opinion of the WG on both issues
>>>>>>>>>>>> before
>>>>>>>>>>> proceeding
>>>>>>>>>>>> with any modification to the document.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Daniele
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP &
>>>>>>>>>>>> Broadband*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Via L.Calda, 5 Genova, Italy Phone [phone] Mobile
>>>>>>>>>>>> [phone] [e-mail]
>>>>>>>>>>>> www.ericsson.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <http://www.ericsson.com/>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This Communication is Confidential. We only send and
>>>>>>>>>>>> receive
>>>>>>> email
>>>>>>>>> on
>>>>>>>>>>>> the basis of the term set out at
>>>>>>> www.ericsson.com/email_disclaimer
>>>>>>>>>>>> <http://www.ericsson.com/email_disclaimer>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________ 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>