Re: CCAMP drafts for adoption

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 <dallan@nortel.com>
To: Nitin Bahadur <nitinb@juniper.net>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 7:40:55 PM
Subject: RE: CCAMP drafts for adoption

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:nitinb@juniper.net]
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); ccamp@ops.ietf.org
Subject: RE: CCAMP drafts for adoption

Hi David,

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

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.

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

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