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

[John E Drake <[e-mail]>]

We currently have two granularities with the aim of getting to one, but how does that have the slightest bearing on advertising an individual interface's bit rate?

> -----Original Message-----
> From: Julien Meuric [mailto:[e-mail]]
> Sent: Tuesday, December 20, 2011 8:31 AM
> To: John E Drake
> Cc: Zhangfatai; CCAMP
> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
>
> Hi John.
>
> I hear your argument and agree that it is not inconsistent with
> SONET/SDH. My point is that deployments of GMPLS-controlled SONET/SDH
> cover a single granularity of containers (and relevant concatenations),
> thus GMPLS-controlled SONET/SDH is not enough as a starting point to be
> mechanically generalized into OTN (otherwise we would not be arguing).
>
> Regards,
>
> Julien
>
>
> Le 20/12/2011 16:53, John E Drake a écrit :
> > Julien,
> >
> > I would also like to observe that what we are doing in OTN is exactly
> the same as we did in SDH/SONET, viz, advertising the types of client
> LSPs a given interface supports.
> >
> > Thanks,
> >
> > John
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >> Of Julien Meuric
> >>
> >> Hi Fatai.
> >>
> >> About the IGP, I believe we agree on several things:
> >> - we are dealing with the ODUk layers within the OTN
> >> technology/regions;
> >> - the ISCD is an appropriate place to put the information on ODUk
> >> capabilities of nodes.
> >>
> >> What we disagree on:
> >> - using the term "extension" to refer to encoding the hierarchy
> level
> >> in
> >> the SC field: the _fact_ is that PSC-[1~4] are part of existing RFCs
> >> (e.g. 4203);
> >> - selecting the SC field as an information on the hierarchy level.
> >>
> >> This leaves us with an open discussion on the latter. We already
> have 2
> >> options on the table for the ISCD in IGPs:
> >> a) multiple SC values,
> >> b)"Switching Cap&  Signal Type (&  Encoding Type as well)".
> >>
> >> First of all, I do not believe the original intend of SC alone was
> to
> >> reflect the notion of region: xSC acronyms may map to "regions", but
> >> from a codepoint perspective we can have several values behind a
> single
> >> xSC (e.g. x=P).
> >>
> >> Then you propose to use the "[OTN] Signal Type": as opposed to a)
> >> above,
> >> this is a new extension, created in
> >> draft-ietf-ccamp-gmpls-ospf-g709v3-00. As emphasized by Kireeti, the
> SC
> >> field should allow to constrain path computation into a range or a
> >> sub-part of the hierarchy (without necessarily specifying a full
> list).
> >> The I-D uses a single SC (OTN-TDM) for the whole OTN, which means
> the
> >> SC
> >> field is useless to prune the network graph when routing an ODUk:
> even
> >> for pruning, a CSFP implementation needs to parse some OTN-specific
> >> sub-TLVs. Hence I prefer the "old-fashion" approach which represent
> the
> >> hierarchy information at a higher level in the IGP, like it was done
> >> for
> >> PBB-TE (RFC 6060).
> >>
> >> Regards,
> >>
> >> Julien
> >>
> >>
> >> Le 06/12/2011 20:21, Zhangfatai a écrit :
> >>>   Hi Julien,
> >>>
> >>>   I agree the requirement that you mentioned, but it can be
> resovled
> >>>   without extending Switching Cap.
> >>>
> >>>   It is known that there are two cases described in RFC5212 and
> >>>   RFC5339, one is MRN, another one is MLN. In RFC5212, it says:
> >>>
> >>
> =======================================================================
> >> ========
> >>>
> >> Thus, a control plane region, identified by its switching type value
> >> (e.g., TDM), can be sub-divided into smaller-granularity component
> >> networks based on "data plane switching layers".  The  Interface
> >> Switching Capability Descriptor (ISCD) [RFC4202],  identifying the
> >> interface switching capability (ISC), the encoding type, and the
> >> switching bandwidth granularity, enables the characterization of the
> >> associated layers.
> >>>   In this document, we define a multi-layer network (MLN) to be a
> >>>   Traffic Engineering (TE) domain comprising multiple data plane
> >>>   switching layers either of the same ISC (e.g., TDM) or different
> ISC
> >>>   (e.g., TDM and PSC) and controlled by a single GMPLS control
> plane
> >>>   instance. We further define a particular case of MLNs. A multi-
> >>>   region network (MRN) is defined as a TE domain supporting at
> least
> >>>   two different switching types (e.g., PSC and TDM), either hosted
> on
> >>>   the same device or on different ones, and under the control of a
> >>>   single GMPLS control plane instance.
> >>>
> >>
> =======================================================================
> >> ==============
> >>>
> >> Therefore, for MRN case, we can use Switching Cap to differentiate
> the
> >> different "layers"; for MLN case (same ISC with different
> granularity),
> >> we can use Switching Cap&  Signal Type (&  Encoding Type as well) to
> >> differentiate the different granularity.
> >>>   So, come back to your question, it can be achived by using
> Switching
> >>>   Cap&Encoding Type&Signal Type to identify the granularity
> requested
> >>>   in OTN networks(e.g., this information can be carried in
> >>>   SERVER_LAYER_INFO sub-object) .
> >>>
> >>>   Lastly, in my opinion, if there is no issue based on the existing
> >>>   mechnism or definition without extending Switching Cap, I don't
> >> think
> >>>   we need to extend Switching Cap.
> >>>
> >>>
> >>>   Thanks
> >>>
> >>>   Fatai
> >>>
> >>>
> >>>
> >>>   ________________________________________ 发件人: Julien Meuric
> >>>   [[e-mail]] 发送时间: 2011年12月7日 0:08 到:
> Zhangfatai
> >> Cc:
> >>>   CCAMP; [e-mail] 主题: Re: [CCAMP] R: OSPF OTN considerations
> >> post
> >>>   IETF 82 (Issue 1/2)
> >>>
> >>>   Hi Fatai.
> >>>
> >>>   As co-author of draft-ietf-pce-inter-layer-ext, I believe you
> will
> >>>   agree on the fact that having a Switching Capability per ODUk
> layer
> >>>   would make the use of objects including a Switching Cap field
> rather
> >>>   straightforward and enables a fine-grained resource description,
> >> e.g.
> >>>   in: - REQ-ADAP-CAP object, to precisely identify the type of
> >>>   adaptation requested by a higher layer, or to get a clear
> feedback
> >> on
> >>>   the missing adaptation for unsuccessful path computations; -
> >>>   SERVER_LAYER_INFO sub-object, to precisely identify the type of
> >>>   server layer within the ERO.
> >>>
> >>>   Do not you think that summarizing G.709 by a single Switching Cap
> >>>   value would take some capabilities away? What would you suggest
> so
> >> as
> >>>   to achieve the same level of details in that scenario?
> >>>
> >>>   Regards,
> >>>
> >>>   Julien
> >>>
> >>>
> >>>   Le 02/12/2011 09:51, Zhangfatai a écrit :
> >>>> Hi all,
> >>>>
> >>>> I agree that there is no need to overload Switching Cap.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Fatai
> >>>>
> >>>>
> >>>> -----Original Message----- From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of BELOTTI, SERGIO
> >>>> (SERGIO)
> >>>>
> >>>> John, as co-authors, we shared completely your thoughts.
> >>>>
> >>>> Thanks Sergio and Pietro
> >>>>
> >>>> SERGIO BELOTTI
> >>>>
> >>>> ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio
> >>>> Evolution
> >>>>
> >>>> via Trento 30 , Vimercate(MI) Italy T: [phone]
> >>>> [e-mail]
> >>>>
> >>>>
> >>>>
> >>>> -----Messaggio originale----- Da: [e-mail]
> >>>> [mailto:[e-mail]] Per conto di John E Drake Inviato:
> >>>> mercoledì 30 novembre 2011 22.37 A: Lou Berger Cc: CCAMP Oggetto:
> >>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
> >>>>
> >>>> 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]] Sent: Wednesday, November 30, 2011
> >>>>> 1:09 PM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject:
> >>>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
> >>>>>
> >>>>>
> >>>>> 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