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

[Rajan Rao <[e-mail]>]

Lou,

I am not seeing a big gain by encoding bottom most ODUk in  SC field for the following reasons:

1) it doesn't give full hierarchy picture supported on the link.  Meaning,  sub-ODUj services over this link still requires more than SC field.
2) the only case it simplifies is service creation at ODUk layer.
3) once a sub-ODUj service is created,  the link is no longer capable of service at ODUk layer. So,  you still have to look at available-ODU advertisement  even for  ODUk services.

My preference is like rest of the authors.

Thanks
Rajan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ong, Lyndon
Sent: Monday, December 12, 2011 7:02 AM
To: BELOTTI, SERGIO (SERGIO); John E Drake; Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

+1

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Monday, December 12, 2011 3:00 AM
To: John E Drake; Lou Berger
Cc: CCAMP
Subject: [CCAMP] R: 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)


Hi all,

we agree with John's consideration on keeping switching capability as indicator of the switching technology and not overloading the meaning with layers within the same technology.

Thanks

Sergio and Pietro


-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di John E Drake
Inviato: venerdì 9 dicembre 2011 11.05
A: Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

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
_______________________________________________
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