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

[Lou Berger <[e-mail]>]

John,
	You're redefining 'a' (i.e., dropping "intra-type hierarchy
indicator").  We've already agreed that your position is that this
capability (and PSC 2-N) should be deprecated, i.e., 'b'.

I think this is a good to general discussion to have/continue, but IMO,
it goes beyond just OTN.

BTW We had lost of discussion on use of SC in the context of the
relatively recent ethernet/PBB RFCs.  At the time, there was general
agreement to use different SC values to identify hierarchy level  Given
that different label formats were involved as well, this
point/discussion may been obscured.

Lou


On 12/9/2011 5:04 AM, John E Drake wrote:
> Lou,
> 
> I think I would argue with your characterization of a.  Other than
> PSC 1-4, which as I have previously stated was an abject failure,
> switching capability was never used to indicate layers within the
> same switching technology.  So, I would argue that what we are doing
> in OTN is really a.  I.e., keep switching capability as it is, an
> indicator of the switching technology.
> 
> Thanks,
> 
> John
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Thursday, December 08, 2011 7:16 AM
>> To: John E Drake
>> Cc: Zhangfatai; Julien Meuric; 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