Re: 54th IETF Meeting - Common Control and Measurement Plane (ccamp)

["Adrian Farrel" <afarrel@movaz.com>]

> I read the draft, and don't see much new in it.  So, instead of
> presenting it again, I would suggest that we start/continue a
> discussion on the mailing list.

Well, I'm sure Atsushi didn't plan to present it :-)
If there is time in the agenda (ho, ho) and interest from the crowd, then 'm
sure kick-starting the discussion in Yokohama would be no bad thing.

> So, here goes.  Folks that think that this work is interesting
> (especially non-authors) please respond.

Sorry, I'm an author.

> First off, I think this is useful work (I didn't need to be hit
> over the head with "Crankback has been identified by the ITU-T as
> requirement" -- although that is good to know).
>
> My question is, do we need a 32 page draft with quite so many
> extensions to get there?

Good question.
The history of this draft includes much debate about whether/why we need
crankback.  This has lengthened the draft with explanations.  Ideally these
would be removed into another draft or completely if the question has been put
to bed.

> As the draft itself says, "full crankback information should
> indicate the node, link and other resources which have been
> attempted but have failed".  The current notify message has some,
> but not all, of this information.  It seems to me that starting
> with new error codes, and an indication of where the error was
> would be sufficient (for now).
>
> Can we apply Occam's Razor, please?  (It's generally a good idea.)
> If the extensions *are* needed, can we have justifications?

So there are three distinct features:
- requesting crankback information
- supplying crankback information
- controlling the use of crankback information

[The fourth point - using crankback information - may be discussed but doesn't
need protocol changes]

The bulk of the draft is (as you suggest) devoted to supplying crankback
information.  There is a lot of commonality with the extended (c-type 3) Error
Spec.  Perhaps a happier solution would be to look at the TLVs for that Error
Spec and see which others are needed/useful for crankback.

Questions I have are
- is this going the right way with regard to requesting/controlling crankback?
- is it valuable to have a protocol agnostic TLV-based solution?

Cheers,
Adrian