Subject: CCAMP drafts for adoption

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 16:01:48 -0000

Hi,

Can you please express your opinion on the adoption of the following three 
drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 Dec 2008 11:22:20 -0500

Hi Adrian:

Support oam-conf
Support oam-ext
Abstain wson-encode

Cheers
Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 02, 2008 11:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Can you please express your opinion on the adoption of the following
three drafts as WG drafts.

Thanks,
Adrian

Cheers,
Adrian and Deborah

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 2 Dec 2008 17:39:17 +0100

Hi,

I support wson-encode.

Regards,
Jonas

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: den 2 december 2008 17:02
> To: [email-masked]
> Can you please express your opinion on the adoption of the
> following three drafts as WG drafts.
>
> Thanks,
> Adrian
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 2 Dec 2008 17:44:17 +0100

Yes to all.

BR

Diego

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: martedì 2 dicembre 2008 17.02
> To: [email-masked]

---

From: "Howard Green" <[email-masked]>
Date: Tue, 2 Dec 2008 10:47:41 -0600

Yes to all three.
Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 02, 2008 8:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Thanks,
Adrian

Cheers,
Adrian and Deborah

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 02 Dec 2008 08:51:40 -0800

Support wson-encode. Yes, I'm a co-author...

Greg

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Young Lee <[email-masked]>
Date: Tue, 02 Dec 2008 10:58:15 -0600

Support for all.

Young (I'm co-author of wson-encode)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Tuesday, December 02, 2008 10:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Thanks,
Adrian

Cheers,
Adrian and Deborah

---

From: Lucy Yong <[email-masked]>
Date: Tue, 02 Dec 2008 14:59:07 -0600

Support all to become WG documents.
Cheer,
Lucy

> Of Young Lee
> Sent: Tuesday, December 02, 2008 10:58 AM
> To: 'Adrian Farrel'; [email-masked]
> Subject: RE: CCAMP drafts for adoption
> 
> Support for all.
>

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 13:35:19 -0800

> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

Do not support either of these.

>From the oam-config-fwk draft:
> A new useful application of RSVP-TE is OAM configuration
> and control for transport networks.

LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need
another mechanism? What are the limitations of lsp-ping that warrant
this new mechanism?

> When RSVP-TE is used for LSP establishment it is desirable to bind
> OAM setup to connection establishment signalling to avoid two
> separate management/configuration steps

draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of
BFD-based OAM.
We should go along the same path for Ethernet OAM.

Thanks
Nitin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 02 Dec 2008 16:49:15 -0500

I agree with Nitin and do not support the adoption of these drafts.

    --Tom

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 2 Dec 2008 22:51:49 +0100

Hi Nitin,

Please note that these mechanisms are proposed for GMPLS and as such to
provide support for any data plane technology specific OAM mechanism. As
you noted LSP Ping is for MPLS and BFD only.  

Best regards,
Attila

> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Tuesday, December 02, 2008 10:35 PM
> To: Adrian Farrel; [email-masked]
> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why 
> do we need another mechanism? What are the limitations of 
> lsp-ping that warrant this new mechanism?
> 
> > When RSVP-TE is used for LSP establishment it is desirable 
> to bind OAM 
> > setup to connection establishment signalling to avoid two separate 
> > management/configuration steps
> 
> draft-ietf-bfd-mpls specifies how to use LSP-Ping for 
> automatic setup of BFD-based OAM.

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 14:01:11 -0800

Hi Attlia,

   What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin  

> From: Attila Takacs [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; [email-masked]
> Please note that these mechanisms are proposed for GMPLS and 
> as such to provide support for any data plane technology 
> specific OAM mechanism. As you noted LSP Ping is for MPLS and 
> BFD only.  
> 
> Best regards,
> Attila
> 
> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we 
> > need another mechanism? What are the limitations of lsp-ping that 
> > warrant this new mechanism?
> >

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 Dec 2008 17:08:53 -0500

Hi Nitin:

> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we
need another mechanism? What are the limitations of 
> lsp-ping that warrant this new mechanism? <snipped> We should go along
the same path for Ethernet OAM.

It is not applicable to either a PBB-TE switched path or, if you are of
that persuasion, an MPLS-TP switched path...as it stands today. And it
only goes downhill from there....

I would think the inappropriateness of applying LSP-PING to Ethernet OAM
would be self evident...Ethernet OAM already has it's own LB/LT
functionality so mandating another loopback exclusively for OAM
configuration is gratuitously complex.

As for MPLS-TP, LSP-PING would need recasting as a "non-IP" protocol to
fit the mandated profile from the joint design team and likely would
benefit from a trip to the fat farm to shed the other features it did
not need within said profile...

Dave

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 2 Dec 2008 23:14:01 +0100

Hi Nitin,

I would formulate this form the other way around. If we already have a
technology agnostic solution, read GMPLS, it seems to be straightforward
to continue using it. Then why not? :-)

One key benefit of using RSVP-TE is that OAM configuration is bound to
the actual LSP establishment this simplifies management and avoids
misconfiguration. With LSP Ping we would need one mechanism to setup the
LSPs (read *not* just MPLS) using GMPLS and then apply another solution
say Generalized-LSP Ping to configure OAM; if I understand your proposal
right.

>From another perspective, what would be the use of LSP Ping over, e.g.,
an optical network or Ethernet using CFM?

Best regards,
Attila

> From: Nitin Bahadur [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 11:01 PM
> To: Attila Takacs; Adrian Farrel; [email-masked]
>    What is the limitation of lsp-ping that prevents it from 
> being applied to GMPLS?
> If an existing mechanism can be applied, then why not? If 
> lsp-ping needs extensions to support GMPLS LSPs, feel free to 
> make/specify those extensions.
> 
> Thanks
> Nitin  
> 
> > Please note that these mechanisms are proposed for GMPLS 
> and as such 
> > to provide support for any data plane technology specific OAM 
> > mechanism. As you noted LSP Ping is for MPLS and BFD only.
> > 
> > Best regards,
> > Attila
> >

---

From: <[email-masked]>
Date: Tue, 2 Dec 2008 22:20:52 -0000

You should not be using one DP OAM (heavyweight) function to activate
(deactivate??) another DP OAM (lightweight) function.  However, since
LDP does not create proper connections there is no concept of LSP (path)
set-up/tear-down...ergo LSP ping tries to treat it like a cl-ps mode
network case. This is NOT the case for GMPLS...esp when applied to any
co-cs mode technology (here proper connections are forced), and it is
not the case for the co-ps mode when proper connections are used (eg
RSVP-TE in MPLS).

Hopwever to be very clear here...it is operationally critical to be able
to activate/decativate OAM flows in sync with whatever CP or MP process
is responsible for connection set-up/tear-down in both co-cs and co-ps
mode layer networks....and LSP ping simply does not fit the bill here.

regards, Neil

> Sent: 02 December 2008 22:01

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 2 Dec 2008 14:21:51 -0800 (PST)

Nitin,

The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you?
On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about.

In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own.

Cheers,
Igor

________________________________
From: Nitin Bahadur <[email-masked]>
To: Attila Takacs <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]
Sent: Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for adoption

Hi Attlia,

Thanks
Nitin

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 2 Dec 2008 17:32:18 -0500

Hi Nitin 

> do we need

These drafts support configuration of data plane OAM functions when you
are using RSVP-TE to setup the paths.  The alternative is operator
configuration. It has nothing to do with LSP Ping. 

> draft-ietf-bfd-mpls specifies how to use LSP-Ping for 

So LSP Ping sets up BFD? Interesting.  While I can see this might be
useful in the case of LDP when debugging a problem you do have issues
with LSP-Ping reaching all path combinations and certain error
scenarios. I don't think this is a comprehensive mechanism. 

This is clearly different than what we are specifying in the Ethernet
OAM case. 

Regards,
Don

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 14:35:44 -0800

> I would formulate this form the other way around. If we 
> already have a technology agnostic solution, read GMPLS, it 
> seems to be straightforward to continue using it. Then why not? :-)
> 
> One key benefit of using RSVP-TE is that OAM configuration is 
> bound to the actual LSP establishment this simplifies 
> management and avoids misconfiguration. With LSP Ping we 
> would need one mechanism to setup the LSPs (read *not* just 
> MPLS) using GMPLS and then apply another solution say 
> Generalized-LSP Ping to configure OAM; if I understand your 
> proposal right.

Yes...your understanding of my proposal is correct. 
But it would solve your issue of manual 
OAM configuration. Agreed, it's a 2-step control-plane process.
 
> From another perspective, what would be the use of LSP Ping 
> over, e.g., an optical network or Ethernet using CFM?

Just for setup of the OAM parameters. Ethernet OAM provides a bunch of
capabilities
(like LT/LB) and you would use them as-is. The advantage of using
lsp-ping is that only the LSP egress sees the OAM parmeters. 

If you add a new-TLV to the PATH msg, then you need to send it on every
PATH msg...
You really need to signal the parameters once during LSP-setup time (and
perhaps when the parameters are changed).

LSP-Ping has a whole bunch of stuff defined. Most of it is not
needed/applicable in various scenarios. But the advantage is that it's
all there. As you go ahead with defining a new mechanism, you will
gradually see other requirements/needs and you might end up re-inventing
lsp-ping in another form.

> > If an existing mechanism can be applied, then why not? If lsp-ping 
> > needs extensions to support GMPLS LSPs, feel free to make/specify 
> > those extensions.
> > 
> > Thanks
> > Nitin
> >

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 14:43:21 -0800

> It is not applicable to either a PBB-TE switched path or, if 
> you are of that persuasion, an MPLS-TP switched path...as it 
> stands today. And it only goes downhill from there....

David, all that I am asking is that one can use the basic-bare-bones
definitions 
in lsp-ping to setup the Ethernet OAM params. I am not talking about
applicability nor I am
saying that one needs to use ping and trace based off lsp-ping for
PBB-TE LSPs. 

We have a whole bunch of stuff defined in RSVP. Obviously some of them
are not applicable for GMPLS LSPs. But that does not mean that we go
define G-RSVP (for GMPLS LSPs).
 
> I would think the inappropriateness of applying LSP-PING to 
> Ethernet OAM would be self evident...Ethernet OAM already has 
> it's own LB/LT functionality so mandating another loopback 
> exclusively for OAM configuration is gratuitously complex.

I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM
already has that and indeed once should use that. I am just saying that
the setup can be done using lsp-ping.
 
> As for MPLS-TP, LSP-PING would need recasting as a "non-IP" 
> protocol to fit the mandated profile from the joint design 
> team and likely would benefit from a trip to the fat farm to 
> shed the other features it did not need within said profile...

LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has
a reply-mode of *application channel* which can be used for things like
bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go
on the LSP reverse path (label-switched and not IP forwarded).

Thanks
Nitin

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 Dec 2008 18:01:25 -0500

HI Nitin:

Thanks for replying....
<snipped>

> David, all that I am asking is that one can use the basic-bare-bones
definitions in lsp-ping to setup the Ethernet OAM 
> params. I am not talking about applicability nor I am saying that one
needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. 

But this still requires implementing a new protocol where it does not
already exist, which also requires a *new* bare bones definition...

> We have a whole bunch of stuff defined in RSVP. Obviously some of them
are not applicable for GMPLS LSPs. But that does > not mean that we go
define G-RSVP (for GMPLS LSPs).

Isn't that CCAMPs mandate?
 
<snipped>

> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
OAM already has that and indeed once should use 
> that. I am just saying that the setup can be done using lsp-ping.

I think the point was GMPLS applies to a lot of technologies that cannot
do LSP-PING in the first place, which means such a signalling extension
will be required nonetheless...

<snipped>
> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping
has a reply-mode of *application channel* which can > be used for things
like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies
would go on the LSP reverse path > (label-switched and not IP
forwarded).

OK, I can see that such an approach could be made to work and would be
desirable to some. On that basis, can I suggest you withdraw your
objections to the Eth-Oam draft and move the TP parts of this discussion
over to the MPLS list? That would seem appropriate...

Cheers
Dave

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 15:08:43 -0800

Hi Igor,
 
  I like your clear explanation (no pun intended). I understand your
view-point....my views are as below...
 
> The difference is that GMPLS is a control plane, while OAM is supposed
to work in the data plane. In transport  
> networks  control plane and data plane are separated. In fact, OAM
should work without and should not depend upon 
>  control plane at all. You can not send Ping messages over lambda
layer network connection, can you? 
 
Agreed. 
 
>  On the other hand, you can use GMPLS to consistently configire OAM
function on the connection NEs, and that's what  
> these drafts as I understand are about.
 
I understand the motivation of these drafts and I totally agree with
that.
 
>  In other words, in MPLS ,  LSP Ping is OAM, while GMPLS can only
automate OAM configuration, it can not relalize  
>  OAM  on its own.

I agree that LSP-Ping may not be the OAM mechanism for GMPLS LSPs. All I
am saying is that LSP-Ping can be used to automate the OAM
configuration. There is enough machinery available in lsp-ping to enable
that. So why re-invent a new protocol? One could send lsp-ping messages
(control-plane routed) containing the information needed to automate
OAM.
 
Question: Isn't it simpler to use RSVP path messages to automate this ?
Answer: Yes it looks simpler.
 
Question: Then why is Nitin opposed ?
Answer: Because as this draft progresses, you will end up adding a whole
bunch of TLVs/sub-TLVs and related error codes. And all these have
nothing to do with a RSVP path message. The draft already has 3-4
sub-TLVs. In effect, the 2 drafts are defining a mini-OAM-boot-strapping
protocol on top of RSVP path message.

Nitin 

	

	From: Nitin Bahadur <[email-masked]>
	To: Attila Takacs <[email-masked]>; Adrian Farrel
<[email-masked]>; [email-masked]
	Sent: Tuesday, December 2, 2008 5:01:11 PM
	Subject: RE: CCAMP drafts for adoption

	Hi Attlia,
	
	  What is the limitation of lsp-ping that prevents it from being
	applied to GMPLS?
	If an existing mechanism can be applied, then why not? If
lsp-ping needs
	extensions to support GMPLS LSPs, feel free to make/specify
those
	extensions.
	
	Thanks
	Nitin  
	
	> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why
do we

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 02 Dec 2008 18:41:04 -0500

Dave, 

    As an operator with a very big deployment of MPLS and a lot of money
invested in OSS to manage said network, I do not want a different mechanism
to the one that has been deployed today to control OAM for any MPLS
networks, MPLS-TP included.

    --Tom

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 2 Dec 2008 15:37:46 -0800

Hi David,

> But this still requires implementing a new protocol where it 
> does not already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare 
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg 
along the control-plane. The LSP details can be put in the existing
defined TLVs. The ethernet OAM details can be directly copied from these
new drafts into a lsp-ping based draft.

> I think the point was GMPLS applies to a lot of technologies 
> that cannot do LSP-PING in the first place, which means such 
> a signalling extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you 
> withdraw your objections to the Eth-Oam draft and move the TP 
> parts of this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related. 
They are related to using RSVP Path as a transmission mechanism for 
OAM setup. OAM is complex and tomorrow we might need more TLVs to
indicate remote failure 
or some other condition via the control plane. 
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that
needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 02 Dec 2008 18:54:27 -0500

> scenarios. I don't think this is a comprehensive mechanism.

    Don,

    LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly
sound method of solving the problem it sought to solve. Please take a look
at this draft-ietf-bfd-mpls-07 for a description of how this works if you
are unfamiliar.    

> This is clearly different than what we are specifying in the Ethernet

    While not a comprehensive mechanism for doing Ethernet OAM, don't you
think that defining how Ethernet OAM works (or is configured) should be done
by the IEEE?  What you are proposing here by combining these different
things together is what at least smells like what was thrown out in L2VPN a
number of years ago due to a layer violation when it was tried for
Ethernet/VPLS PWs. 

    --Tom

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 Dec 2008 19:40:55 -0500

Hi Nitin:

My reaction is that spreading state over a number of protocols may keep
one superficially simple but drives up the total cost of the
solution...from the POV of lines of code, amount to test, amount of
state, additional race conditions, delayed setup time etc. so is a
specious optimization....

If the path is not up until OAM says so, it is useful to get there in as
few transactions as possible...

My 2 cents.
Dave

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); [email-masked]
Subject: RE: CCAMP drafts for adoption

Hi David,

> already exist,

> which also requires a *new* bare

I think that would be easy. You just need to send the lsp-ping msg along
the control-plane. The LSP details can be put in the existing defined
TLVs. The ethernet OAM details can be directly copied from these new
drafts into a lsp-ping based draft.

> I think the point was GMPLS applies to a lot of technologies that 
> cannot do LSP-PING in the first place, which means such a signalling 
> extension will be required nonetheless...

> can I suggest you
> withdraw your objections to the Eth-Oam draft and move the TP parts of

> this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related. 
They are related to using RSVP Path as a transmission mechanism for OAM
setup. OAM is complex and tomorrow we might need more TLVs to indicate
remote failure or some other condition via the control plane. 
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Dec 2008 21:07:42 -0700

Do not support.

-shane

On Dec 2, 2008, at 2:49 PM, Thomas D. Nadeau wrote:

>> need

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 2 Dec 2008 23:34:13 -0500

Hi Tom
Please see inline, 

>at this draft-ietf-bfd-mpls-07 for a description of how this works if
you

Tom,

When I read this draft what I read is that an MPLS LSP may take one or 
more paths and that a BFD session is set up for one or more of these
paths. 
Since the network may change, the MPLS LSP may vary the number of paths 
it takes from time to time (ECMP may come and go). So if you have a 
problem you may fined you have not set up the BFD session on a LSP path 
or there may well be even 2 BFD sessions running on what is now a single

LSP path.  In a big network I think this may be a bit of an issue. 

>number of years ago due to a layer violation when it was tried for

We absolutely have left OAM for the IEEE. In fact the whole data plane 
and OAM is specified in the IEEE. All we are proposing is to optionally 
signal a IEEE OAM profile of the type of MIPs and MEPs on the
connection. 
This is the point of GMPLS. Generalized control of other technologies.

RSVP-TE sessions that don't use these objects would use normal RSVP-TE 
processing. That is why we have extensible protocols.  As Attila points 
out OAM for other technologies such as optical could also use these 
GMPLS mechanisms. 

When you setup paths and CCM in this manner there is no doubt it is 
protecting the traffic path. 

Regards,
Don

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Wed, 3 Dec 2008 08:31:18 +0100

I support all of them.

Cheers,
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: martedì 2 dicembre 2008 17.02
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Thanks,
Adrian

Cheers,
Adrian and Deborah

---

From: Anders Gavler <[email-masked]>
Date: Wed, 3 Dec 2008 08:52:26 +0100

Yes to all three.

/Anders

---

From: longhao 48034 <[email-masked]>
Date: Wed, 03 Dec 2008 09:34:52 +0100

Hi,

I support all of the three drafts to become WG drafts.

When I read the mailing discussion, some experts opposed the two I-Ds related to oam configuration:
 draft-takacs-ccamp-oam-configuration-fwk-01.txt
 draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

My understanding is these two I-Ds are very useful for oam deployment. As you know, there are many things are needed to be preconfigured before you activate the oam function. This is actually a tough thing for users because the configuration involoves all the nodes on the lsp and so many parameters, e.g. MEG level, MEP ID, MD name , MA name ..... Some experts argues that this will lead to add more TLVs to RSVP-TE. However, if looking at the
 LSP setup, it is also a way to simplify the configuration. LSP setup and OAM configuration are similar thing. They are both the work of REVP-TE signaling. As this, I support the two I-Ds.

Thanks,
Hao

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2008 09:00:42 -0000

Hi Nitin,

Have you tried running LSP Ping on a lambda?
In practice, many data plane technologies have existing OAM techniques, and 
it is these that the draft proposes to control.

Are you suggesting that the LSP Ping echo request should be sent out of band 
and used to manage data plane OAM?

Thanks,
Adrian
----- Original Message ----- 
From: "Nitin Bahadur" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 02, 2008 9:35 PM
Subject: RE: CCAMP drafts for adoption

Thanks
Nitin

---

From: Mach Chen <[email-masked]>
Date: Wed, 03 Dec 2008 17:55:10 +0800

Yes to all three drafts.

Best regards,
Mach

--------------------------------------------------
From: "Adrian Farrel" <[email-masked]>
Sent: Wednesday, December 03, 2008 12:01 AM
To: <[email-masked]>
Subject: CCAMP drafts for adoption

---

From: Sugang XU <[email-masked]>
Date: Wed, 03 Dec 2008 19:08:53 +0900

Sugang

---

From: "Francesco Fondelli" <[email-masked]>
Date: Wed, 3 Dec 2008 14:04:42 +0100

> Do not support either of these.

Given this statement

a)
--- draft-ietf-mpls-tp-framework-00 ---
The MPLS-TP control plane is based on a combination of
the MPLS control plane for pseudowires and the GMPLS
control plane for MPLS-TP LSPs, respectively.  More
specifically, LDP is used for PW signaling and
*GMPLS based RSVP-TE for LSP signaling*.
---

and this requirement

b)
--- draft-ietf-mpls-tp-requirements-00 --
The MPLS-TP control pane MUST support the configuration
and modification of OAM maintenance points as well as
the activation/deactivation of OAM *when the transport
path is established or modified*.
---

RSVP-TE is the tool that has to be used for OAM
configuration in a MPLS-TP context, IMHO.

Above I-Ds are mpls working group documents... so
my opinion on the adoption of the following two drafts

is yes

and my opinion on the adoption of the following draft

draft-bernstein-ccamp-wson-encode-01.txt

is yes

> Nitin

thanks
Ciao
FF

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Dec 2008 09:36:59 -0500

Tom,
         You might want to look at what's happening with OAM for TP, 
it != LSP Ping.  As TP is currently drafted, Attila's documents will 
make more sense than LSP ping.

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 3 Dec 2008 06:42:15 -0800 (PST)

Dave,

I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and  I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution.

On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework.

Igor

________________________________
From: David Allan <[email-masked]>
To: Nitin Bahadur <[email-masked]>; [email-masked]
Sent: Tuesday, December 2, 2008 7:40:55 PM
Subject: RE: CCAMP drafts for adoption

Hi Nitin:

My 2 cents.
Dave

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); [email-masked]
Subject: RE: CCAMP drafts for adoption

Hi David,

Thanks
Nitin

---

From: "Attila Takacs" <[email-masked]>
Date: Wed, 3 Dec 2008 16:28:00 +0100

Hi Nitin, 

> 
> If you add a new-TLV to the PATH msg, then you need to send 
> it on every PATH msg...
> You really need to signal the parameters once during 
> LSP-setup time (and perhaps when the parameters are changed).
> 

There are some options here. 

First it has clear benefits to have the OAM config bound to the Path
message and so to the actual LSP establishment as this ensures that the
connection and its OAM is coupled. This is something you cannot ensure
with LSP Ping.

Alternatively, if one just wants to configure MEPs one may carry the
proposed TLVs as part of Call establishment, this way only the endpoints
will take part in signaling.

On the other hand, if one needs to configure MIPs, the signaling needs
to pass intermediate nodes hence the need to use the Path message is
obvious.

> LSP-Ping has a whole bunch of stuff defined. Most of it is 
> not needed/applicable in various scenarios. But the advantage 
> is that it's all there. As you go ahead with defining a new 
> mechanism, you will gradually see other requirements/needs 
> and you might end up re-inventing lsp-ping in another form.
> 

How would you configure MIPs with LSP Ping? I assume you would need to
use at least as many transactions (and as such have as many failure
scenarios) as many intermediate nodes the LSP has. (Not to mention that
you need to get the list of intermediate nodes and the info on the
success/failure of LSP establishment from another protocol.)

Compare this to a single Path message in the case of RSVP-TE.

Best regards,
Attila

> lsp-ping

---

From: Rebecca Han <[email-masked]>
Date: Wed, 03 Dec 2008 09:39:34 -0600

Rebecca Han

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:41:43 -0800

Attila,

Very well put.  I think I-Ds in question should become working group
drafts.

Thanks,

John 

>Sent: Wednesday, December 03, 2008 7:28 AM
>To: Nitin Bahadur; [email-masked]
>> If you add a new-TLV to the PATH msg, then you need to send it on 
>> every PATH msg...
>> You really need to signal the parameters once during LSP-setup time 
>> (and perhaps when the parameters are changed).
>> 
>
>First it has clear benefits to have the OAM config bound to 
>the Path message and so to the actual LSP establishment as 
>this ensures that the connection and its OAM is coupled. This 
>is something you cannot ensure with LSP Ping.
>
>Alternatively, if one just wants to configure MEPs one may 
>carry the proposed TLVs as part of Call establishment, this 
>way only the endpoints will take part in signaling.
>
>On the other hand, if one needs to configure MIPs, the 
>signaling needs to pass intermediate nodes hence the need to 
>use the Path message is obvious.
>
>> gradually see other requirements/needs and you might end up 
>> re-inventing lsp-ping in another form.
>> 
>
>How would you configure MIPs with LSP Ping? I assume you would 
>need to use at least as many transactions (and as such have as 
>many failure
>scenarios) as many intermediate nodes the LSP has. (Not to 
>mention that you need to get the list of intermediate nodes 
>and the info on the success/failure of LSP establishment from 
>another protocol.)
>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:41:43 -0800

Attila,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:41:43 -0800

Attila,

Thanks,

John

---

From: "Greg Mirsky" <[email-masked]>
Date: Wed, 3 Dec 2008 14:19:35 -0500

Support oam-configuration and eth-oam
Abstain wson-encode

Regards,
Greg

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 04 Dec 2008 10:34:00 +0900

Hi,

Yes to All.

Kenichi

---

From: hejia 48726 <[email-masked]>
Date: Thu, 04 Dec 2008 00:03:21 -0800

Support All to become WG drafts. 
Thanks!

B.R.
Jia

---

From: <[email-masked]>
Date: Thu, 4 Dec 2008 15:55:50 +0100

Hello.

I support the 3 of them.

I also think that some of the arguments highlighted by Attila, Igor, Dave, Adrian... may deserve to be incorporated in the 1st I-D to avoid looping again on this kind of clarification.

Regards,

Julien

-----Original Message-----

Hi,

Thanks,
Adrian

Cheers,
Adrian and Deborah

---

From: Loa Andersson <[email-masked]>
Date: Tue, 09 Dec 2008 11:53:34 +0100

support for all

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Redback Networks                      phone: +46 8 632 77 14
An Ericsson Company

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Dec 2008 10:18:17 -0000

Hi,

draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group
draft.

Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to 
indicate
that the problem space you address is just the RWA portion of WSON.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Dec 2008 10:31:54 -0000

Hi,

Deborah and I have listened to the discussion about accepting the two OAM 
configuration I-Ds (draft-takacs-ccamp-oam-configuration-fwk-01.txt and 
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working group drafts.

We see reasonable consensus for adoption, but are aware that several people 
expressed a concern that this work would deprecate LSP Ping as a bootstrap 
mechanism for OAM in certain environments.

We believe that it is not the authors' intention to deprecate the use of LSP 
Ping in this way, and that it would not be wise to make such a change.

Therefore, we accept these two I-Ds as working group drafts, but request the 
authors to add to draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:

The mechansim described in this document provides an additional option for 
bootstrapping OAM that is not intended to replace or deprecate the use of 
other OAM bootstrapping techniques such as LSP Ping [RFC4379]. The 
procedures specified in this document are intended only for use in 
environments where RSVP-TE signaling is already in use to set up the LSPs 
that are to be monitored using OAM.

We believe that this text goes some way to address the concerns raised and 
we note that the draft will be the property of the working group allowing 
additional changes to be made according to working group consensus.

Authors, please make the textual change and submit

draft-takacs-ccamp-oam-configuration-fwk-01.txt
as
draft-ietf-ccamp-oam-configuration-fwk-00.txt

and
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
as
draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt

Thanks,
Adrian and Deborah

---

From: "Attila Takacs" <[email-masked]>
Date: Thu, 18 Dec 2008 15:40:36 +0100

Hi Adrian,

> We see reasonable consensus for adoption, but are aware that 
> several people expressed a concern that this work would 
> deprecate LSP Ping as a bootstrap mechanism for OAM in 
> certain environments.
> 
> We believe that it is not the authors' intention to deprecate 
> the use of LSP Ping in this way, and that it would not be 
> wise to make such a change.
> 

Agreed.

> Therefore, we accept these two I-Ds as working group drafts, 
> but request the authors to add to 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:
> 
> The mechansim described in this document provides an 
> additional option for bootstrapping OAM that is not intended 
> to replace or deprecate the use of other OAM bootstrapping 
> techniques such as LSP Ping [RFC4379]. The procedures 
> specified in this document are intended only for use in 
> environments where RSVP-TE signaling is already in use to set 
> up the LSPs that are to be monitored using OAM.
> 

Will add the note and resubmit.

Thanks and best regards,
Attila

> Sent: Thursday, December 18, 2008 11:32 AM
> To: [email-masked]
> Subject: Accepting OAM Configuration I-Ds
> 
> Hi,
> 
> Deborah and I have listened to the discussion about accepting 
> the two OAM configuration I-Ds 
> (draft-takacs-ccamp-oam-configuration-fwk-01.txt and
> We see reasonable consensus for adoption, but are aware that 
> several people expressed a concern that this work would 
> deprecate LSP Ping as a bootstrap mechanism for OAM in 
> certain environments.
> 
> We believe that it is not the authors' intention to deprecate 
> the use of LSP Ping in this way, and that it would not be 
> wise to make such a change.
> 
> Therefore, we accept these two I-Ds as working group drafts, 
> but request the authors to add to 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:
> 
> The mechansim described in this document provides an 
> additional option for bootstrapping OAM that is not intended 
> to replace or deprecate the use of other OAM bootstrapping 
> techniques such as LSP Ping [RFC4379]. The procedures 
> specified in this document are intended only for use in 
> environments where RSVP-TE signaling is already in use to set 
> up the LSPs that are to be monitored using OAM.
> 
> 
> We believe that this text goes some way to address the 
> concerns raised and we note that the draft will be the 
> property of the working group allowing additional changes to 
> be made according to working group consensus.
> 
>

---

From: Young Lee <[email-masked]>
Date: Thu, 18 Dec 2008 10:52:21 -0600

We will submit the update with the clear scope spelled out. Thanks.

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Thursday, December 18, 2008 4:18 AM
To: [email-masked]
Cc: Greg Bernstein
Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D

Hi,

Thanks,
Adrian