Subject: [Pce] Some thoughts on using RBNF and "completeness"

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Jun 2013 11:48:16 +0100

Hi,

There has been some discussion about this on the list, and Cyril just raised an
Errata Report on the same topic. You won't be surprised to know that this has
come up before and has also shown itself in discussions of RSVP/RSVP-TE/GMPLS.

In my view, it is not the intention that each individual draft or RFC provides
the latest and most complete full definition of the protocol messages. IMHO this
leads to unnecessary complication, and may make documenting new protocol
extensions across multiple documents particularly hard work. It can also hide
the specifics of protocol extensions.

Of course, individual implementers may sit down and construct the full RBNF for
the pieces of the protocol that they are implementing, and it may serve some
value to periodically publish a "global view".

But we need to understand that, like RSVP, PCEP applies the "liberal on what you
receive conservative on what you send" principle, so that it is only when the
order of objects has specific meaning that we need to make sure they are all
present and in the right order.

Thus, and taking Cyril's Errata only as a concrete example for the purposes of
discussion...

RFC 5440 has:
       <svec-list>::=<SVEC>[<svec-list>]

RFC 5541 extends the scope of the construct to add OF and metric-list as:
        <svec-list> ::= <SVEC>
                        [<OF>]
                        [<metric-list>]
                        [<svec-list>]

RFC 5557 thought it was adding three optional objects to the SVEC list: OF, GC,
and XRO even though OF was already added by 5541. Thus it documents:
   <svec-list> ::= <SVEC>
                   [<OF>]
                   [<GC>]
                   [<XRO>]
                   [<svec-list>]

The fact that 5541 needs a metric-list in the svec-list while 5557 does not, is
exactly the point. Each RFC is documenting the constructs that it needs to
enable the function it describes. Each RFC is not attempting to make the latest
and definitive description of the protocol messages.

Actually, I don't even think that the RBNF is really normative. It is
descriptive. The normative stuff is found in the text that says how object types
are handled when they are received, and what presence rules are required.

Does that make sense?

I am not saying that it isn't helpful to have a wider view of the potential
complexity of each message expressed in RBNF, but I do think that trying to
create that for all existing protocol applications (some of which might never be
used in the same implementation and so certainly not in the same message) and
trying to keep that up-to-date, is not realistic.

Cheers,
Adrian

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Thu, 27 Jun 2013 13:03:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Thursday, June 27, 2013 12:48 PM
> To: [email-masked]
> Subject: [Pce] Some thoughts on using RBNF and "completeness"
> 
> Hi,
> 
Hi, 

> There has been some discussion about this on the list, and Cyril just
> raised an Errata Report on the same topic. You won't be surprised to
> know that this has come up before and has also shown itself in
> discussions of RSVP/RSVP-TE/GMPLS.
> 
>
> In my view, it is not the intention that each individual draft or RFC
> provides the latest and most complete full definition of the protocol
> messages. IMHO this leads to unnecessary complication, and may make
> documenting new protocol extensions across multiple documents
> particularly hard work. It can also hide the specifics of protocol
> extensions.

As draft author this makes my work easier, but when checking documents and as implementer I find trying to assemble all the pieces together necessary and showing some inconsistencies. I find helpful trying to have a most complete definition of the message, especially for checking the overall protocol and extensions consistency. 

> 
> Of course, individual implementers may sit down and construct the full
> RBNF for the pieces of the protocol that they are implementing, and it
> may serve some value to periodically publish a "global view".
> 
> But we need to understand that, like RSVP, PCEP applies the "liberal on
> what you receive conservative on what you send" principle, so that it
> is only when the order of objects has specific meaning that we need to
> make sure they are all present and in the right order.
> 
> Thus, and taking Cyril's Errata only as a concrete example for the
> purposes of discussion...
> 
> RFC 5440 has:
> RFC 5557 thought it was adding three optional objects to the SVEC list:
> OF, GC, and XRO even though OF was already added by 5541. Thus it
> documents:
>    <svec-list> ::= <SVEC>
>                    [<OF>]
>                    [<GC>]
>                    [<XRO>]
>                    [<svec-list>]
> 
> The fact that 5541 needs a metric-list in the svec-list while 5557 does
> not, is exactly the point. Each RFC is documenting the constructs that
> it needs to enable the function it describes. Each RFC is not
> attempting to make the latest and definitive description of the
> protocol messages.
> 
>
> descriptive. The normative stuff is found in the text that says how
> object types are handled when they are received, and what presence
> rules are required.
> 
> Does that make sense?

The statement that the RBNF is not really normative bugs me a little, RFC5440 section 6 does indicate that the object order must be followed according to the RBNF, and the text does not specify what is the object order.

This can be problematic for example in RFC6006 for the BANDWIDTH object which may follow the LSPA, RRO, or RRO-LIST elements and in this case there is no text describing the BANDWIDTH object placement rules. 

I understand that the object presence rule may be quite complicated to describe (OF <metric-list> in SVEC is a good example of it), but IMHO the RBNF should be normative for the object order, in addition to the text.

> I am not saying that it isn't helpful to have a wider view of the
> potential complexity of each message expressed in RBNF, but I do think
> that trying to create that for all existing protocol applications (some
> of which might never be used in the same implementation and so
> certainly not in the same message) and trying to keep that up-to-date,
> is not realistic.

For object presence rules I do agree, for object order I think this is possible, for instance (heavily inspired from Ramon) 

<request>         ::= <RP> (<expansion>|<p2p_computation> | <p2mp_computation>)
<expansion>       ::= <PATH-KEY>
<p2p_computation> ::= <ENDPOINTS>[<gen-bw>][<p2p-attributes>...]
<p2p-attributes>  ::= <attributes>|< rro-bw-pair>

<attributes>      ::= <CLASSTYPE>|<LSPA>|<metric-list>|<OF>|<vendor-info-list>|<IRO>|<BNC>|<XRO>|<LOADBALANDING> 
--> here makes them all optional and order does not matter, except for rro-bw-pair 

<gen-bw> ::= <BANDWIDTH>[<GENERALIZED-BANDWIDTH>...]  -- per RFC5440 section 7.7 

<p2mp_computation> ::= <tree-list>[<p2mp-attributes>...]
<p2mp-attributes> ::= <attributes>
<tree-list> ::= <tree> [<tree-list>]
<tree> ::= <ENDPOINTS> <rro_bw_pair> 

> Cheers,
> Adrian
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 28 Jun 2013 08:40:06 +0200

Adrian, all

Only my two cents/opinion (and speaking only in the scope of very
specific issues within PCEP)
I am afraid we are mixing different things:

a) The fact that, currently, most PCEP RFCs describe specific protocol 
extensions
and, as such, they focus on their constructs only extending, typically, some
base RFC.

b) The fact that, unfortunately, some glitches and issues appear that render
some of these RFCs hard to combine (I don't dare to say contradictory) 
and some
details are missed in the big picture.

With regard to a) I could agree with your view, and as Cyril said, it makes
also the draft authorship "easier", and allows an implementor to select just
the desired functionalities to implement and to refer to the RFCs it 
supports,
individually, rather than implementing the "whole thing". At least in theory

However, I think that, in the past mails, we are more referring to b) 
and the
fact that, to address b) the whole picture and the actual implementation 
of several
RFCs at the same time, considering the full message definition is indeed 
helpful.

Unfortunately, such issues appear just then, when implementing them at the
same time. It also happens, that in the process of writing an RFC that 
extends
another RFC does not fully capture all the implications, as in our 
particular
example. In the specific case of PCEP some of such RFCs appeared in a short
period of time, with changes in the latest drafts that were not captured in
sibling documents.

The canonical example is (just made out of my mind)
RFC X - p ::= A
RFC Y - object C MUST follow object A
RFC Z - object D MUST follow object A

As someone willing to a PCE with most features, having a formal, complete,
strict and normative document with most (all?) extensions would be helpful.
That said, it is a huge task, rendered somehow obsolete the same moment it
gets published.

Some other comments inline

 > Thus, and taking Cyril's Errata only as a concrete example for the 
purposes of
 > and XRO even though OF was already added by 5541. Thus it documents:

[Ramon] In this particular case, it may be the case that RFC5557 was 
extending
RFC5541, not RFC5440 ("Note that this requirement is covered by"synchronized
objective functions" in Section 5.1.7 [RFC4657] and  that [RFC5541]") so I
believe it should have extended RFC5541 and that the metric-list was
inadvertently missed.

 > descriptive. The normative stuff is found in the text that says how 
object types
 > are handled when they are received, and what presence rules are required.

[Ramon] To me that is unfortunate. In my limited experience, sometimes 
one find, within
the text, clauses that are hard to understand or contradictory, possibly
written by (as yours truly) non-English native  or non-descriptive enough.

As implementer, I tend to consider the RBNF as a formal notation. And in 
case
of doubt that is where I first look in the RFC. In the specific case of 
PCEP I personally find / regret
(mostly as Robert and Cyril) that:

- RBNF as used does not capture the semantics/intent of the messages.
What do I mean with that?  Consider
<response>::=<RP>
             [<NO-PATH>]
             [<attribute-list>]
             [<path-list>]

A quick glance at this makes me think that, if I write a parser / 
grammar for
that message (I use Boost spirit.qi, but one could use ANTLR, bison, x...) a
message of the form <RP><NO-PATH><ERO><..> (that is a No-PATH object 
followed
by a path) then as per that grammar (and I like to write my grammars as 
close
to the spec as possible) the message is correct and successfully parsed. 
Is it
valid? not really. Also, according to that grammar, a reponse with 
*just* an RP
object is valid. So here, I agree with you, one hast to read the whole 
text to make sure
of the intent.

What  would I like? (I am sorry, I know it is easy to talk, way harder 
to write...).  Keep the
text but then :*)

<response>::=<RP> (<success> | <failure>)

<success>::=<path-list>

<failure>::=<NO-PATH>[<attribute-list>]

The problem is that each implementor I know is doing the second part on 
its own, and the
interpretations are different.

- Lax object ordering constraints.

This is a topic for another debate, but, in my personal opinion, I find 
strict
ordering easier to implement, and to error check, although it may go 
against the
meme of "be lax in what you accept...."

 > trying to keep that up-to-date, is not realistic.

It is a daunting task, indeed. I should do it myself? probably :*) but I 
know
that if I had an "Implementation Agreement 1.0 for PCEP" or a "PCEP v2" that
integrates published documents I would use it as reference.

Thanks and best regards

Ramon

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01

---

From: Julien Meuric <[email-masked]>
Date: Fri, 28 Jun 2013 18:08:36 +0200

Hi Ramon.

Your point is legitimate and is certainly shared by several 
implementers. I personally like the way you try to disambiguate syntax 
below. I tend to interpret this like volunteering for putting that into 
an I-D: it would be helpful to efficiently share with the WG and decide 
about the interest of the approach (it would not have to tackle all PCEP 
extensions in an early revision)...

I am glad to see several people agreeing to work towards the same 
direction within a single week! ;-)

Cheers and nice week-end,

Julien

On 06/28/2013 08:40, Ramon Casellas wrote:
> [...]
> The problem is that each implementor I know is doing the second part 
> on its own, and the
[...]