Re: [Pce] Gen-art last call review: draft-ietf-pce-vendor-constraints-11

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 29 November 2013 20:13 UTC

From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Robert Sparks' <rjsparks@nostrum.com>
References: <52950B49.4040209@nostrum.com>
In-Reply-To: <52950B49.4040209@nostrum.com>
Date: Fri, 29 Nov 2013 20:13:34 -0000
Message-ID: <09fc01ceed3f$7ba84170$72f8c450$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJTI9WAWk4TCysAmovI8fZ2raVT55k0M1bA
Content-Language: en-gb
Cc: draft-ietf-pce-vendor-constraints@tools.ietf.org, pce@ietf.org
Subject: Re: [Pce] Gen-art last call review: draft-ietf-pce-vendor-constraints-11
Precedence: list
Reply-To: adrian@olddog.co.uk

Hi Robert,

Thanks for the time.

> Summary: Ready (but I have a couple of comments for consideration)
> 
> Given a quick scan of the list history for this document, I'm surprised
> there's not more discussion about the potential for creating islands of
> non-interoperable equipment, and some recommendation for when to define
> and how to deploy a standard version of a constraint when a common thing
> is found among vendor specific variants of the constraint (are there
> implications if an element include both the standard and vendor specific
> variants?)

I think we are several layers into the "what if" stack here.
Yes, it *is* possible that something that is initially developed by a single
vendor will later become something we want to standardise.
I suspect that this leads to the "normal" type of migration issues for new
features being added to a protocol.
In particular, an implementation that uses vendor-specific options will need to
have code to determine when to handle those options and when to handle the
standards-based ones. But I don't think that is a matter for standardisation: it
feels like an issue for the vendor.
I guess that a new specification that explains how a new standardised option is
to be handled would say "If you receive this you MUST..." and that will
naturally define that any other vendor-specific option takes lower precedence.

> This is probably bigger than this document, and take it for what it's
> worth, but the practice of relisting the definition of <svec-list> when
> you add objects doesn't seem to be working well. For instance, had XRO
> or GC been defined later, you're probably ok with them being used with
> these objects too, right? As it is, I'm having a hard time seeing the
> value in redefining the grammar this way each time you add a new thing.
> It leads to odd artifacts like _this_ document not providing a good
> reference to what XRO and GC are (you have to chase through the
> registry, or look at 5557 or 5521, neither of which are referenced here.

Ah. And here we hit an issue that a number of folk are "debating".
Is the RBNF message format normative? Can it be "compiled"? And, indeed, what
does it mean?

I don't want to trample on the views of the WG (which I should say are "in the
process of forming"), but my opinion is that the RBNF is indicative. Like RSVP,
however, the very strong "lenient in what you receive and strict in what you
send" means that an implementation might adhere closely to the RBNF when
building a message, but should not attempt to use it to police a message.

Furthermore, a lot of the protocol extensions are optional making it hard to
keep up with exactly what the format across the whole protocol is supposed to
look like. There is an effort within the WG to try to collate that - we wait to
see whether it is successful.

Cheers,
Adrian

[Pce] Gen-art last call review: draft-ietf-pce-ve… Robert Sparks
Re: [Pce] Gen-art last call review: draft-ietf-pc… Adrian Farrel
[Pce] Gen-art Telechat review: draft-ietf-pce-ven… Robert Sparks
Re: [Pce] [Gen-art] Gen-art Telechat review: draf… Robert Sparks
Re: [Pce] [Gen-art] Gen-art Telechat review: draf… Jari Arkko