Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

["Adrian Farrel" <[e-mail]>]

Hi Greg,

[snip]

> You've suggested:
>       ". unassigned bits MUST be transmitted as zero and ignored on receipt ."
> in another discussion, it was pointed to me that "transmitted as zero and 
> ignored on receipt" for reserved fields or bits/flags is falling out of favor
as
> accepted form of expression. Would appreciate suggestions on how to
> improve it.

I guess I'm old so stuff I like falls out of favor all the time, but it doesn't
change my opinion :-)

Firstly, there is a difference between truly reserved fields, and fields that
are currently unassigned but which you expect to possibly assign one day.

In the former case, no-one really cares how the fields are set and, of course
(?) no-one will look at such fields.

In the latter case you need to be forward compatible. 
That means that an implementation that can process some new meaning of the
previously unused field must receive a value form a legacy implementation that
it will not misinterpret. The easiest way to handle this is to require legacy
implementations to transmit zero - then the new meaning of the field can include
"zero means not supported".
Similarly, a legacy implementation that receives a non-setting (from a new
implementation) needs to not barf. The easiest way is to simply ignore the
fields that are believed to be unused.

None of this means that a legacy implementation should police the setting of
zero in an unused field it received. Indeed, although it could police the
sender's adherence to "MUST be zero" is should not do so because it is not
supposed to look at the field at all.

Maybe you need to be asking the person who suggested that the concept is falling
out of favor. They might have a suggestion.

A