Hi Jeff,
Thanks very much for your support and your always valuable inputs. We
will take all of them into account to improve the text of the document.
On the packing part, we are in-sync & indeed, yes: TLVs and E-bit
support for TLVs are all optional. However, on the E-bit part, maybe not
yet well-specified in the document and we should improve that, the
"Stats Reports" message is itself a sequence of TLVs and we authors do
see applicability of the E-bit there too. That is to say the E-bit
applicability may transcend just the context of trailing TLVs in Route
Monitoring messages: so perhaps the Operational Considerations section
is more suited for the draft-ietf-grow-bmp-tlv-03 document.
Paolo
On 27/10/2020 20:50, Jeffrey Haas wrote:
Paolo,
On Mon, Oct 26, 2020 at 02:15:45PM +0100, Paolo Lucente wrote:
I would like to get some feedback / encourage some conversation
around the topic of supporting Enterprise-specific TLVs in BMP (or
draft-lucente-grow-bmp-tlv-ebit-01) so to see whether it is
appropriate to ask the Chairs for WG adoption.
[...]
Motivation: i would like to supplement what is already written in
the Introduction section of the draft "Vendors need the ability to
define proprietary Information Elements, because, for example, they
are delivering a pre-standards product, or the Information Element
is in some way commercially sensitive.", in short prevent TLV code
point squatting.
[...]
Approach: reserving the first bit of a TLV type to flag whether what
follows is a private or a standard TLV and, if private, provide the
PEN in the first 4-bytes of the TLV value is a simple and successful
mechanism to achieve the motivation that was merely copied from
IPFIX, a case of nothing new under the Sun.
Firstly, I'm supportive of adding enterprise specifc information into the
BMP protocol. I'm also supportive of using PENs to create the necessary
code space.
I will, however, offer a bit of repetitive advice I'd given at one of the
last in-person GROW sessions we'd had: This information will in many cases
degrade the packing of information in BMP route monitoring messages. This
will have specific impacts on the memory and CPU used in an implementation.
That said, as long as the features are optional - if it hurts, don't do
that. But I'd offer advice that whatever document this goes into contains
an Operational Considerations section that notes the impact. A BMP
implementation should be able to disable such features to mitigate the
impact on the receiver.
With regard to the use of this to prevent squatting, I'll offer two prior
inputs I've given IETF on such things:
https://tools.ietf.org/html/draft-haas-idr-extended-experimental-01
https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02
The two salient points here are:
- If the thing should be standardized, don't stick it in your enterprise
space. This means that a FCFS registry should be available for the stuff.
- Stability of a feature is the awkward, even if you're using FCFS. If you
choose an encoding, changing it has impact. If you don't want to move the
code point, at least consider a versioning field.
-- Jeff
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
