Re: [CCAMP] Overlay model framework and context

Snigdho Bardalai <sbardalai1@gmail.com> Thu, 20 December 2012 21:33 UTC

Return-Path: <sbardalai1@gmail.com>
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 AD5F121F8920 for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 13:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.196
X-Spam-Level:
X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[AWL=1.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjvNeJvi748c for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 13:33:48 -0800 (PST)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBB821F88DD for <ccamp@ietf.org>; Thu, 20 Dec 2012 13:33:47 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id c10so5222657ieb.39 for <ccamp@ietf.org>; Thu, 20 Dec 2012 13:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ICGTsFA3RMsVIHsRf4iRQk5E6I4jKjxSKRBlXDLwoN0=; b=wE1Lopx82ADH+YDNQEaAmFVa5ddgktdONpatMj8M4pRZsjqB3QNVyHP7VpGb6TqX5J vbyzjfnRKhneObxEe+vikDZ744jK93WvayXH3B2YZEeJVGWtlyPFY/8Fr4diq6wLanOb XP3Il3dvbwKepLtgQgmZ/lOmEP6UwwfrI/P4iXwYHi9bQSs/bRawrIZYxwpDVXC1Zq/b lrQMgWFfSzHJrIZudFyx5MnbdShBNAZj0T6lBqBrlNknyhb2hGfeEyroiAdf9akeCePx JNjJSPeGxbH426R6DyganhT29UX+VK7nBWrGwlsLPLgwMRrFGWkPrjC/4fO+dlwCtQ2z tNeQ==
MIME-Version: 1.0
Received: by 10.50.0.140 with SMTP id 12mr11793606ige.63.1356039227619; Thu, 20 Dec 2012 13:33:47 -0800 (PST)
Received: by 10.64.12.164 with HTTP; Thu, 20 Dec 2012 13:33:47 -0800 (PST)
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A1910154B@atl-srv-mail10.atl.advaoptical.com>
References: <305443B66F0CD946A3107753337A031103FAA66E@CH1PRD0511MB431.namprd05.prod.outlook.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A19100EDA@atl-srv-mail10.atl.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE48045190@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191012BC@atl-srv-mail10.atl.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE48045653@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A1910154B@atl-srv-mail10.atl.advaoptical.com>
Date: Thu, 20 Dec 2012 13:33:47 -0800
Message-ID: <CAD-y1-f_b=x2iKaZYYf546-mctifRteCVQdSQ=NgoX0DZVEh6w@mail.gmail.com>
From: Snigdho Bardalai <sbardalai1@gmail.com>
To: Igor Bryskin <IBryskin@advaoptical.com>
Content-Type: multipart/alternative; boundary=e89a8f646e0d76b94f04d14f7c31
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] Overlay model framework and context
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: Thu, 20 Dec 2012 21:33:50 -0000

Igor,

I think depending on what the capabilities of the OE are there may be many
possibilities. Expanding on your VN examples.

Another example could be:

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
OC3-----VN2======VL2======VN4-----OC4

Since virtual-links are potential links the topology would have to be a
mesh between the VNs. The other question that is applicable here is whether
hair-pinning is allowed in a VN?

OC1-----VN1                              VN3-----OC2
            VN1======VL1======VN3
OC5-----VN1                              VN3-----OC6
            VN1======VL3======VN4
            VN1======VL4======VN5
OC3-----VN2======VL2======VN4-----OC4
           VN2======VL5======VN5
           VN2======VL6======VN3

Regards
Snigdho

On Thu, Dec 20, 2012 at 8:01 AM, Igor Bryskin <IBryskin@advaoptical.com>wrote;wrote:

> Daniele,
> It seems we have a disconnect here.
>
> OC1-----OE1======VL1======OE2-----OC2
> OC3-----OE1======VL2======OE2-----OC4
>
> Generally speaking OEs are blocking switches, and the connectivity
> matrices need to be advertised by OEs, so that the client path computer
> will know , for example, that OC1-OE1 access link can be switched to VL1
> (but not to VL2). One way to alleviate the client path computation from
> dealing with connectivity matrices is by presenting OEs as sets of
> independent fully symmetrical Virtual Nodes:
>
> OC1-----VN1======VL1======VN3-----OC2
> OC3-----VN2======VL2======VN4-----OC4
>
> Igor
>
> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Thursday, December 20, 2012 4:41 AM
> To: Igor Bryskin; Gert Grammel; CCAMP
> Subject: RE: [CCAMP] Overlay model framework and context
>
> Hi Igor,
>
> Unfortunately your drawing is totally misaligned, is this a correct
> re-drawing?
>
> OC1------If1:OE1                          OE2:IF4---------OC2
>              OE1:If2----------------- If3:OE2
>
> answer : is neither a), b) nor c)
>
> OC1------If1:OE1========== VL =========== OE2:IF4---------OC2
>              OE1:If2----------------- If3:OE2
>
> With respect to Q2:
>
> >Q2: if on the other side we considered the virtual link being
> >B) (i.e. From IF1 to IF4 hence with an "implicit" node
> >connectivity matrix) which would be the drawbacks of this solution?
> >
> >IB>>  VL cannot start on a customer facing interface. OE is a
> >(blocking)
> >IB>> switch between access and virtual TE links
>
> I still believe the tranffic matrix can be implicitely advertised as part
> of the VL. Consider this:
>
> OC3------If5:OE1========== VL1 =========== OE2:IF6---------OC4
> OC1------If1:OE1========== VL2 =========== OE2:IF4---------OC2
>              OE1:If2-------------------If3:OE2
>
> OE1 is a blocking node because only allows OC3 to be connected to VL1 and
> OC1 to VL2. But if you just advertise VL1 to OC3 (not VL2) and VL2 to OC1
> (not VL1) aren't you implicitely hiding the blocking nature of OE1?
>
> Cheers,
> Daniele
>
>
> >-----Original Message-----
> >From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> >Sent: mercoledì 19 dicembre 2012 18.03
> >To: Daniele Ceccarelli; Gert Grammel; CCAMP
> >Subject: RE: [CCAMP] Overlay model framework and context
> >
> >Daniele,
> >Please, see in line.
> >
> >-----Original Message-----
> >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> >Sent: Wednesday, December 19, 2012 9:53 AM
> >To: Igor Bryskin; Gert Grammel; CCAMP
> >Subject: RE: [CCAMP] Overlay model framework and context
> >
> >Hi Igor,
> >
> >Just focusing on the virtual links for a while; i must admit
> >that i'm a bit confused by your last mail. Let's pick the
> >figure i sent.
> >
> >>OC1                               OC2
> >>  \    +---+IF2       IF3+---+    /
> >>   \IF1|OE1|-------------|OE2|IF4/
> >>       +---+             +---+
> >>
> >>A) Virtual link is from OC1 to OC2
> >>B) Virtual link is from IF1 to IF4
> >>C) Virtual link is from IF2 to IF3
> >
> >IB>> My understanding of your picture is this:
> >
> >OC1------If1:OE1
> >OE2:IF4---------OC2
> >                       OE1:If2----------------- If3:OE2 My
> >answer : is neither a), b) nor c)
> >
> >OC1------If1:OE1  ===== VL ======= OE2:IF4---------OC2
> >                       OE1:If2----------------- If3:OE2
> >
> >VL is between OE1 and OE 2, potential server trail is between
> >IF2 and IF3
> >
> >According to the definition given:
> >"A virtual link is a potential path between two virtual or
> >real network elements in a client layer"
> >I would say that a virtual link is from OC1 to OC2, which is A).
> >
> >IB>> See above
> >
> >Then, from your latest definition:
> >" a potential path between two virtual or real server domain
> >network elements"
> >I would say that a virtual link can be either B) or C).
> >IB>> See above
> >
> >Then you speak about access links, which implies that the link
> >between OC1 and OE1 has its own dignity and hence that the
> >virtual link is C) in picture above.
> >
> >IB>> Links OC1- OE1 and OC2-OE2 are access links
> >
> >Now i have 2 questions:
> >
> >Q1: can you confirm that a virtual link is C)? Then we need to
> >update the definition of a virtual link removing any
> >misleading reference to client/server domain Network elements
> >and speak about OCs and OEs.
> >
> >Q2: if on the other side we considered the virtual link being
> >B) (i.e. From IF1 to IF4 hence with an "implicit" node
> >connectivity matrix) which would be the drawbacks of this solution?
> >
> >IB>>  VL cannot start on a customer facing interface. OE is a
> >(blocking)
> >IB>> switch between access and virtual TE links
> >
> >
> >Thanks
> >Daniele
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> >>Sent: lunedì 17 dicembre 2012 21.12
> >>To: Gert Grammel; Daniele Ceccarelli; CCAMP
> >>Subject: RE: [CCAMP] Overlay model framework and context
> >>
> >>Gert,
> >>
> >>Please, see in line. I disagree with pretty much everything you say.
> >>Igor
> >>
> >>-----Original Message-----
> >>From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
> >On Behalf
> >>Of Gert Grammel
> >>Sent: Monday, December 17, 2012 8:27 AM
> >>To: Daniele Ceccarelli; CCAMP
> >>Subject: Re: [CCAMP] Overlay model framework and context
> >>
> >>Daniele,
> >>
> >>Thank you for summarizing the current state of discussion. To move
> >>forward and to encourage comments, let me point to some of the issues
> >>that are debated:
> >>
> >>1) Virtual Link: in the terminology statement a virtual link seems to
> >>connect two client elements.
> >>IB>> The definition says:
> >>"1. Virtual Link: A virtual link is a potential path between two
> >>virtual or real network elements in a client layer", what makes you
> >>think that anyone ever applied that this is a path between client
> >>devices? The definition should say, though: " a potential
> >path between
> >>two virtual or real server domain network elements"
> >>
> >> However later on the 3) virtual topology is composed of access links
> >>and virtual links. Hence. Virtual links connect server nodes, not
> >>client nodes.
> >>IB>> see above
> >>
> >> By doing so, segments (AL and VL) are created.
> >>
> >>2) The scalability consideration in the appendix for VL is based on
> >>terminology 1) rather than on virtual topology
> >>
> >>IB>> I completely disagree with this, see below
> >>
> >>3). This way it doesn't describe then the  scalability of a virtual
> >>topology (which doesn't necessitate a full mesh) but rather that of a
> >>virtual node (which implies a full connectivity matrix).
> >>
> >>To sum up:
> >>1) we have to come up with a crisp definition of a VL in a virtual
> >>topology that is different from a terminology 1) VL.
> >>Here is a gap
> >>2) A Model based on a vitual node or 'terminology 1) links'
> >>create n**2 problems on client side and does not scale.
> >>3) 'VNT'-virtual-links 3) and access links are supposed to
> >address the
> >>scaling problem. We need to clean up our terminology.
> >Otherwise we end
> >>up associating limitations of terminology 1) links with
> >VNT-links that
> >>address those limitations.
> >>
> >>IB>> It seems to me that you completely misunderstand current
> >>IB>> definitions
> >>
> >>Now looking at the appendix it sadly reflects the terminology
> >confusion
> >>and jumps to assessment and conclusions. That's unfortunate:
> >>
> >>The first line says:
> >>Some notes on the Virtual Node:
> >>1.      Virtual Link Model along, sadly,
> >>--> is it now about virtual nodes or virtual links or VNT links?
> >>IB>> Virtual Link Model includes access, inter-domain and
> >>virtual links
> >>IB>> but does not include virtual nodes
> >>
> >>2.      The only way to avoid full-mesh of Virtual Links is by
> >>having intermediate nodes interconnecting Virtual Links in the middle
> >>of the virtual topology
> >>--> that's why access links are so useful. They end at server nodes
> >>--> which are connected via virtual links
> >>
> >>IB>> A combination of access and virtual links alone *does not
> >>address N**2 problem*.
> >>Consider 1000 client devices connected via 1000 access links to the
> >>network that need to be fully interconnected. You will need
> >1000000 VLs
> >>to do so. You need to have one or more Virtual Nodes in the middle of
> >>the virtual topology to solve this issue. Overlay Network Topology is
> >>no different from real network topology, and real network
> >topologies do
> >>include Ps, not just PEs
> >>
> >>3.      These intermediate nodes cannot be real server domain
> >>switches, because, generally speaking:
> >>--> in case of VNT-VLs no intermediate nodes are necessarily required
> >>IB>> See  above, IMO you are dead wrong
> >>
> >>4.  --> No need to comment, this way doesn't scale anyway.
> >>IB>> ONTs with virtual nodes scale no worse that real network
> >>topologies
> >>
> >>5.      If you want to compute SRLG-disjoint paths that could
> >>potentially go through a real server domain switch, the latter's
> >>connectivity matrix must expose "internal" SRLGs, so that the two
> >>services traversing the switch will not simultaneously fail
> >if a single
> >>internal element shared by the services fails
> >>--> who is 'you' that computes? A client selects among VNT
> >>virtual links based on exposed SRLGs, VLs are computed by the server
> >>with full knowledge of constraints. So what does an 'internal' SRLG
> >>mean to a server path computation?
> >>
> >>IB>> You is the client path computer. If the two paths are
> >>going through
> >>IB>> the same node, they may overlap inside the node, which
> >means they
> >>IB>> can be brought down by a single network failure. That's why you
> >>IB>> need to expose  node's internal SRLGs or try to find node
> >>disjoint
> >>IB>> paths (which may not be available)
> >>
> >>6.      If you walk through all cases that need to be
> >>addressed when you are traffic engineering topologies with blocking
> >>switches, you will understand that there is absolutely no difference
> >>between a virtual node and real blocking real node.
> >>--> I suggest to model a complete network of say 5 nodes in a
> >>single VN and compare it with the model of a single real node.
> >>
> >>IB>> Please, do that
> >>
> >>--> The assessments made have used a terminology definition
> >>that doesn't really capture the case made for VNT-VLs.
> >>That's why I would have had appreciated to split definitions and work
> >>items agreed among a group from individual assessments in separate
> >>emails.
> >>Nevertheless I consider the first part of your email (all except the
> >>appendix) as a good starting point for further clarification.
> >>
> >>Gert
> >>________________________________________
> >>From: ccamp-bounces@ietf.org on behalf of Daniele Ceccarelli
> >>Sent: Monday, December 17, 2012 12:17:08 PM
> >>To: CCAMP
> >>Subject: [CCAMP] Overlay model framework and context
> >>
> >>Dear CCAMPers,
> >>
> >>In the last weeks several off-line discussions on the Overlay model
> >>framework and related works took place. Some discussions led to some
> >>sort of agreemet among a small group of people, some others
> >to a set a
> >>viable options, some others to totally open issues. I tried to
> >>summarize the output of such discussions below so to progress the
> >>discussions into a single thread on the WG ML.
> >>
> >>Please note that the aim of this mail is not to present a well shaped
> >>and conclusive idea to the WG but rather to provide the basis for
> >>starting a discussion from a barely shaped idea (step 1) instead of
> >>starting it from scratch (step 0).
> >>
> >>In addition you can find attached a slide depicting a proposal of the
> >>overlay scenario.
> >>
> >>Thanks,
> >>Daniele
> >>
> >>+ Disclaimer:
> >> 1. Packet opto integration is often considered but the work can be
> >>extented to any type of SC. Eg. TDM over LSC.
> >>
> >>+ Terminology:
> >>
> >> 1. Virtual Link: A virtual link is a potential path between two
> >>virtual or real network elements in a client layer network  that is
> >>maintained/controlled in and by the server domain control
> >plane (and as
> >>such cannot transport any traffic/data and protected from being
> >>de-provisioned) and which can be instantiated in the data plane (and
> >>then can carry/transport/forward traffic/data) preserving previously
> >>advertised attributes such as fate sharing information.
> >> 2.  Virtual Node: Virtual node is a collection of zero or
> >more server
> >>network  domain nodes that are collectively represented to
> >the clients
> >>as a single node that exists in the client layer network and
> >is capable
> >>of terminating of access, inter-domain and virtual links.
> >> 3.Virtual Topology: Virtual topology is a collection of one or more
> >>virtual or real server network domain nodes that exist in the client
> >>layer network and are interconnected via 0 or more virtual links.
> >> 4. Overlay topology:  is a superset of virtual topologies
> >provided by
> >>each of server network domains, access and inter-domain links.
> >> 5. Access Link: Link between OC and OE. GMPLS runs on that link. It
> >>can support any of the SCs supported by the GMPLS.
> >> 6. Overlay Customer (OC): Something like the CN in RFC4208
> >teminology
> >>but (i) receiving virtual topology from the core network and
> >requesting
> >>the set up of one of them or (ii) requesting the computation and
> >>establishment of a path accordingly to gien constraints in the core
> >>network and receiving the parameters characterizing such
> >path. (ii) ==
> >>UNI.
> >> 7. Overlay Edge (OE): Something like the EN in RFC4208 but able to
> >>deal with (i) and (ii) above.
> >> 8. ONI : Overlay network interface: Interface allowing for signaling
> >>and routing messages exchange between Overlay and Core
> >network. Routing
> >>information consists on virtual topology advertisement. When there is
> >>no routing adjacency across the interface it is equivalent to
> >the GMPLS
> >>UNI defined in 4208.
> >>Signaling messages are compliant with RFC4208. Information related to
> >>path carachteristics, e.g. TE-metrics, collected SRLG, path
> >delay etc,
> >>either passed from OE to OC via signaling after the LSP establishment
> >>in the core network or from OC to OE to be used as path computation
> >>constraints, fall under the definition of signaling info and not
> >>routing info).
> >> 9. O-NNI (name to be found,maybe reused): Interface on the links
> >>between different core networks in the overlay model environment, i.e.
> >>Between border OEs. Same features of the ONI apply to this interface.
> >>Could it be an E-NNI? A ONI? A new name is needed?
> >>
> >>+ Statements
> >> 1. In the context of overlay model we are aiming to build an overlay
> >>topology for the client network domains  2. The overlay topology is
> >>comprised of:
> >>    a) access links (links connecting client NEs to the
> >server network
> >>domains). They can be PSC or LSC.
> >>    b) inter-domain links (links interconnecting server network
> >>domains)
> >>    c) virtual topology provided by the server network
> >domains. Virtual
> >>Links + Virtual Nodes (TBD) + Connectivity Matrix (with a set of
> >>parameters e.g. SRLG, optical impairments, delay etc for each entry)
> >>describing connectivity between access links and virtual links.
> >> 3. In the context of overlay model we manage  hierarchy  of overlay
> >>topologies with overlay/underlay relationships  4. In the context of
> >>overlay model multi-layering and inter-layer relationships are
> >>peripheral at best, it is all about horizontal network integration  5.
> >>The overlay model assumes one instance for the client network and a
> >>separate instance for the server network and in the ONI case
> >the server
> >>network also surreptitiously participates in the client network by
> >>injecting virtual topology information into it.
> >> 6. L1VPN (and LxVPN) in general is a service provided over
> >the ONI (it
> >>falls under the UNI case as no routing adjacency is in place
> >between OC
> >>and OE).
> >>
> >>+ Open issues/questions
> >>
> >> 1. PCE-PCEP - do we need to include considerations about PCE
> >and PCEP
> >>into the overlay framework context?
> >> 2. BGP-LS needs to be considered
> >> 3. Should potentials be included? E.g. I2RS?
> >>
> >>+ Appendix:
> >>Some notes on the Virtual Node:
> >>1.      Virtual Link Model along, sadly, does not scale
> >>because of N**2 problem. IP over ATM and single-segment PWs have the
> >>same issue, that's why people invented multi-segment PWs
> >>2.      The only way to avoid full-mesh of Virtual Links is by
> >>having intermediate nodes interconnecting Virtual Links in the middle
> >>of the virtual topology
> >>3.      These intermediate nodes cannot be real server domain
> >>switches, because, generally speaking:
> >>  a)Real switches belong to different layer network;
> >>  b)Real switches are named from different naming space
> >>  c)real switches individually may not have sufficient resources to
> >>terminate virtual links (while a group of real switches collectively
> >>will have)
> >>  d)Presenting a group of real switches as a single virtual node have
> >>better scalability qualities
> >>4.      Even if you map a virtual node on a single real node,
> >>you need to keep in mind that real server domain switches are,
> >>generally speaking, blocking switches and as such must expose their
> >>connectivity matrices
> >>5.      If you want to compute SRLG-disjoint paths that could
> >>potentially go through a real server domain switch, the latter's
> >>connectivity matrix must expose "internal" SRLGs, so that the two
> >>services traversing the switch will not simultaneously fail
> >if a single
> >>internal element shared by the services fails
> >>6.      If you walk through all cases that need to be
> >>addressed when you are traffic engineering topologies with blocking
> >>switches, you will understand that there is absolutely no difference
> >>between a virtual node and real blocking real node.
> >>7.      Even in case of pure VL model, client NEs connected to
> >>server network domain must be upgraded so that they could understand
> >>the connectivity matrices advertised by the border nodes describing
> >>connectivity constraints between access links and virtual links they
> >>terminate.
> >>
> >>
> >>
> >>===================================
> >>DANIELE CECCARELLI
> >>System & Technology - PDU Optical & Metro
> >>
> >>Via E.Melen, 77
> >>Genova, Italy
> >>Phone +390106002512
> >>Mobile +393346725750
> >>daniele.ceccarelli@ericsson.com
> >>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
> >>
> >>
> >>_______________________________________________
> >>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
>