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

John E Drake <jdrake@juniper.net> Wed, 07 December 2011 13:24 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7121F8B0E for <ccamp@ietfa.amsl.com>; Wed, 7 Dec 2011 05:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level:
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-4.493, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VKxdTxXJT4l for <ccamp@ietfa.amsl.com>; Wed, 7 Dec 2011 05:24:28 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4B21F84AE for <ccamp@ietf.org>; Wed, 7 Dec 2011 05:24:27 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTt9o+r+SulN08PrxySuEZfdJYkMJETcl@postini.com; Wed, 07 Dec 2011 05:24:27 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 7 Dec 2011 05:21:12 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>, Zhangfatai <zhangfatai@huawei.com>
Date: Wed, 07 Dec 2011 05:21:08 -0800
Thread-Topic: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
Thread-Index: Acy0VawszvKy4qZyQO6+1dExkH3DzAAi0U/w
Message-ID: <5E893DB832F57341992548CDBB333163A4B682A99E@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4EDE354F.20803@orange.com> <F82A4B6D50F9464B8EBA55651F541CF825CC18C0@SZXEML520-MBS.china.huawei.com> <4EDE7B04.5000804@labn.net>
In-Reply-To: <4EDE7B04.5000804@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2011 13:24:29 -0000

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:lberger@labn.net]
> 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
> >
> >
> > _______________________________________
> > 发件人: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 Julien
> Meuric [julien.meuric@orange.com]
> > 发送时间: 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:lberger@labn.net]
> >>>
> >>> 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:lberger@labn.net] 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: ccamp-bounces@ietf.org
> >>>>>>> [mailto:ccamp-bounces@ietf.org] 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 +390106002512 Mobile
> >>>>>>>> +393346725750 daniele.ceccarelli@ericsson.com
> >>>>>>>> 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 CCAMP@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>>> _______________________________________________ CCAMP
> >>>>>>> mailing list CCAMP@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>  _______________________________________________ CCAMP mailing list
> >>  CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
> >>
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp