RE: CCAMP drafts for adoption

["David Allan" <dallan@nortel.com>]

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