TRILL (Transparent Interconnection of Lots of Links) Over IP Transport
draft-ietf-trill-over-ip-17

[Ballot comment]
This draft has received significant attention from the transport area while I was recovering from pneumonia, so I'm balloting No Objection while noting a couple of things that I'm confused about, that I haven't seen mentioned previously, and trusting people to Do The Right Thing.  Otherwise, I'll sit with my hands folded quietly, and watch the Discussion on Mirja's ballot position with interest.

I have (at a Comment level) the same curiosity that Mirja included in her Discuss ballot about why both UDP and TCP encapsulations are included. My curiosity extends to whether NAT traversal being out of scope for this document makes sense, given that one of the use cases given is

3.1 Remote Office Scenario

  In the Remote Office Scenario, as shown in the example below, a
  remote TRILL network is connected to a TRILL campus across a multihop
  IP network, such as the public Internet.

If NAT traversal were in scope, offering both TCP and UDP encapsulations would make more sense - TCP and UDP are treated differently enough at NATs and firewalls that HTTP/2 over QUIC/UDP uses HTTP/2 over TCP as its fallback. But it might be worth thinking about what would be required to make this work well over the public Internet. That doesn't have to be in this document, of course.

I see that Mirja has asked about the request to allocate two port numbers in this draft, one for TRILL IS-IS, and the other for TRILL Data. I'm reading this text

  The Link Header and Link Trailer in these formats depend on the
  specific link technology. The Link Header contains one or more fields
  that distinguish TRILL Data from TRILL IS-IS. For example, over
  Ethernet, the Link Header for TRILL Data ends with the TRILL
  Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS-
  IS Ethertype; on the other hand, over PPP, there are no Ethertypes in
  the Link Header but different PPP protocol code points are included
  that distinguish TRILL Data from TRILL IS-IS.

as saying that those two types of packets could be distinguished, if they were carried over a single five-tuple. I'd offer that the conversation about allocating two port numbers would terminate more quickly if you could explain whether I'm misreading that text, so that you really can't distinguish between these two packet types, or whether there is some other reason why you'd want to avoid fate-sharing between these two packet types that seem to make up an adjacency.

[Ballot discuss]
Usage of encapsulation schemes
----
The document does not clearly explain and justify why different encapsulations are needed. The document should more extensively discuss the different properties and trade-offs for each encapsulation and give clear recommendations when you to use which encapsulation. E.g. the document does not clearly specify when to use IPSec (besides saying „if security in needed“), however, the document needs to explain more clearly what is meant by this: given the over-the-Internet path is always not trusted, does that mean that IPSec should always be used in that scenario? Why is IPSec specified instead of using TLS or DTLS with the TCP or UDP encapsulations respectively? Why is both UDP and TCP encapsulation needed, given that UDP is the default that is mandatory to implement anyway? Why are the short-comings of UDP and when is it recommended/beneficial to switch to TCP?

DSCP
-----
1) Section 4.3 should also talk about decapsulation as DCSP is often overwritten on the path and therefore the DCSP of the inner and other IP headers can differ on decapsulation. Please see RFC2983 for further guidance. You probably should specify to discard the outer DSCP at tunnel egress in your use case.

2) Further it is not clear to me if the use of CS7 in appropriate for this use case as RFC 4594 says
"  o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class."

3) Moreover, if my understanding is correct, the high priority classes in TRILL are not exclusively reserved for control data. However, CS6 and CS7 is only meant for control and rounting traffic. If those classes are used it must be ensure that the traffic send with these DSCP is not overloading the network. I think further (security) considerations are needed here.


Broadcast Link Encapsulation Considerations
------
Not every transport encapsulation can be used for Broadcast/Multicast. TCP cannot be used. This is mention later but also be consider in the text in section 5.3

TCP Encapsulation
-----
If my understanding is correct than TRILL does not know that the connect of a TRILL data packet is. That means the data could can also contain traffic that is running over TCP, right? Encapsulating TCP in TCP should generally avoided if possible and need further considerations as loss in the outer control loop that is used on the TRILL IP link appears as strongly varying delays to the inner control loop and therefore can have very negative effects.

TCP Connection Establishment (section 5.6.1)
-----
This section seem to assume for all configured or discovered tunnel endpoints should  immediately (at node start up time) and permanently open one/multiple TCP connections. I'm in general uncertain if this is the right approach. However, even if the connection is not closed, it might not be usable after an idle time, as middlebox on the path may have removed their state. Therefore, to keep a connection permanently open, the endpoint need probably to send keep-alives, or alternative a mechanism to detect such a failure (quickly) and re-establish the connection such be used. Alternative, a connection could be open and closed when needed. In this case also more recommendation is needed when to open and close the connection(s).

Fragmentation
----
The fragmentation problem for Internet links is not sufficiently addressed. trill requires a minimum size of 1,470 bytes while most Internet paths only support an MTU of 1,470 bytes which will automatically lead to fragmentation when encapsulation is added. It can not be assumed that all Internet path support IPv6, therefore the recommendation "if fragmentation is anticipated with the encapsulations specified in this document, the use of IPv6 is RECOMMENDED" is often hard to realize. I assume that many trill IS-IS packets are smaller than 1,470 bytes thus fragmentation might not occur, however, for larger packets I would rather recommend to implement an additional mechanism to enable segmentation above UDP (+ PMTU discovery) or the use of TCP. In any case more clear recommendation is needed.

Port assignment
----
Only one port per service can be assigned (see principles in rfc6335 and guidelines in rfc7605). Therefore the spec should be changed to the use of one ports and describe how different kinds of packets can be distinguished by other means (which should be easily possible to my understanding). Further, it is expected that the document confirms that any new security added later on will also use the port assigned (i.e., future versions will not be eligible for new ports
e.g. for a “TLS” variant).

[Ballot comment]
Based on my conversation with DEE, I understand that the HMAC is always computed over a value which is disjoint with the HKDF-Label. This is not really cryptographically ideal -- as I stated in my review, you should be HKDFing two keys off the same key -- but it does imply that the trivial attack doesn't work, so I'm removing my DISCUSS. As we discussed, please add some explanation of why this is a non-issue to the document.

[Ballot discuss]
Hopefully this is easy to resolve. In the best case, you will be
able to demonstrate that this is not a problem in practice and
document that. If not, the actual fix is straightforward, though
incompatible.

S 7.1.1.
I am concerned about the use of the IS-IS key in this way. First, on
general principles, you should not use a single key both as input to a
KDF and directly as a working key. Specifically, however, RFC 5310
defines the use of HMAC authentication with IS-IS-key as the HMAC
key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
was able to observe (or cause to be created) an IS-IS packet that
happened to have the same contents as the HKDF Info value you
provide would then know the IKE PSK.

The correct practice here is to separately expand both the IS-IS
key *and* the IKE PSK from the same original value. If you cannot
do that, you should at least generate an Info value which is
guaranteed to not be the input to any RFC 5310 MAC.

  When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
  incorporates the IS-IS shared key in order to bind the TRILL data
  session to the IS-IS session.  The pre-shared key that will be used

The technique you provide does not guarantee a binding between the
sessions. It merely ensures (modulo the caveat above) that both sides
know the IS-IS Key. It's easy to see this by noting that you could
move IS-IS traffic from one IPsec association to another. If you
actually want to bind these sessions, you must do something different.

[Ballot comment]
I see that native encapsulation is incompatible with NATs (S 8).
That's probably worth stating upfront to minimize confusion.

S 5.4.2.

      f. No middleboxes are allowed in the TRILL over IP transport link
        because middlebox support is beyond the scope of this document.

How would you know if no middleboxes were in the link?

S 5.5.
Can you use VXLAN with IPsec?

S 5.6.
What security mechanism do you expect to use for TCP? IPsec again?

  the timing and implementation details may be such that P! and P2 each

Nit: P1, right?

[Ballot discuss]
DSCP
-----
1) Section 4.3 should also talk about decapsulation as DCSP is often overwritten on the path and therefore the DCSP of the inner and other IP headers can differe on decapsulation. Please see RFC2983 for further guidance. You probabably should specify to discard the outer DSCP at tunnel egress in your use case.

2) Further it is not clear to me if the use of CS7 in appropriate for this use case as RFC 4594 says
"  o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class."

3) Moreover, if my understanding is correct, the high priority classes in TRILL are not exclusively reserved for control data. However, CS6 and CS7 is only meant for control and rounting traffic. If those classes are used it must be ensure that the traffic send with these DSCP is not overloading the network. I think further (security) considertations are needed here.


Broadcast Link Encapsulation Considerations
------
Not every transport encapsualtion can be used for Broadcast/Multicast. TCP cannot be used. This is mention later but also be consider in the text in section 5.3

TCP Encapsulation
-----
If my understanding is correct than TRILL does not know that the connect of a TRILL data packet is. That means the data could can also contain traffic that is runing over TCP, right? Encapsulating TCP in TCP should generally avoided if possible and need further considerations as loss in the outer control loop that is used on the TRILL IP link appears as strongly varying delays to the inner control loop and therefore can have very negative effects.

TCP Connection Establishment (section 5.6.1)
-----
This section seem to assume for all configured or discovered tunnel endpoints there should be immeditately (at node start up time) and permantly a/multiple open TCP connections. I'm in general uncertain if this is the right approach. However, even if the connection is not closed, it might not be usable after an idle time, as middlebox on the path may have removed their state. Therefore to keep a connection permanently the endpoint need probaly to send keep-alives, or alternative a meachism to detect such a failure (quickly) and re-establish the connection such be used.  However,

[Ballot comment]
Editorial coments:
1) It is really confusing that the whole document is talking about ports as tunnel endpoints while it also often talks about transport (TCP/UDP) ports. It makes it really hard to read this document. Maybe these things can be better distighlished somehow.

2) This document should not re-specify the UDP header (5.4). At minimum the text should be changed the following way.
OLD
"Where he UDP Header is as follows:"
NEW
"Where he UDP Header is as follows as specified in [RFC0768] :"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-trill-over-ip-14. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are six actions which we must complete.

First, the authors request two port assignments as follows:

Service Name: TRILL-IS-IS
Transport Protocol: udp, tcp
Assignee: iesg@ietf.org
Contact: chair@ietf.org
Description: Transport of TRILL IS-IS control PDUs.
Reference: [ RFC-to-be ]
Port Number: (TBD1)

Service Name: TRILL-data
Transport Protocol: udp, tcp
Assignee: iesg@ietf.org
Contact: chair@ietf.org
Description: Transport of TRILL Data packets.
Reference: [ RFC-to-be ]
Port Number: (TBD2)

IANA Question --> Can we ask that you fill out the form below and we can have the experts review them now for permanent registrations?

https://www.iana.org/form/ports-services

Second, a single address is to be assigned from the IPv4 Multicast Address Space Registry located at:

https://www.iana.org/assignments/multicast-addresses/

for All-RBridges

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Third, a single address is to be assigned from the IPv6 Multicast Address Space Registry located at:

https://www.iana.org/assignments/ipv6-multicast-addresses/

for All-RBridges

IANA notes that the authors have suggested a value of [FF0X:::15D] for this registration and that the hex digit "X" in the IPv6 variable scope address indicates the scope and defaults to 8. The IPv6 All-RBridges IP address may be used with other values of X.

Because this registry also requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Fourth, the RBridge Channel Protocols registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at:

https://www.iana.org/assignments/trill-parameters/

is to be renamed from the

RBridge Channel Protocols registry

to the

RBridge Channel Protocols and Link Technology Specific Flags registry.

and the reference for this registry shall also be amended from RFC 7178 to both RFC 7178 and [ RFC-to-be ].

Fifth, in the newly renamed registry, the registration rules at the top of the registry are changed to the following:

Range Registration Note
----------- ---------------- ----------------------------
0x002-0x0FF Standards Action
0x100-0xFCF RFC Required allocation of a single value
0x100-0xFCF IESG Approval allocation of multiple values
0xFD0 0xFF7 see Note link technology dependent,
see subregistry

Sixth, in the newly renamed registry, a single modification is made as follows:

Before:
0x007-0xFF7 Unassigned

After modification:
0x007-0xFCF Unassigned
0xFD0-0xFF7 (link technology dependent, see subregistry)

Seventh, a new subregistry is to be created called the TRIPP over IP Transport Link Flags registry. The new registry will be a subregistry of the newly renamed RBridge Channel Protocols and Link Technology Specific Flags registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at:

https://www.iana.org/assignments/trill-parameters/

The new subregistry will be managed via Expert Review as defined by RFC 8126.

There are initial registrations in the new registry as follows:

Name: TRILL over IP Transport Link Flags
Registration Procedure: Expert Review
Reference: [ RFC-to-be ]

Flag Meaning Reference
---------- ------------------------------ --------------
0xFD0 Native encapsulation fully supported [ RFC-to-be ]
0xFD1 VXLAN encapsulation fully supported [ RFC-to-be ]
0xFD2 TCP encapsulation fully supported [ RFC-to-be ]
0xFD3-0xFF7 Unassigned


The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: shares@ndzh.com, trill-chairs@ietf.org, trill@ietf.org, draft-ietf-trill-over-ip@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL (Transparent Interconnection of Lots of Links) Over IP Transport) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'TRILL (Transparent
Interconnection of Lots of Links) Over IP Transport'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The TRILL (Transparent Interconnection of Lots of Links) protocol
  supports both point-to-point and multi-access links and is designed
  so that a variety of link protocols can be used between TRILL switch
  ports. This document specifies transmission of encapsulated TRILL
  data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP
  network as a TRILL link in a unified TRILL campus. This document
  updates RFC 7177 and updates RFC 7178.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream)
    draft-ietf-tsvwg-le-phb: A Lower Effort Per-Hop Behavior (LE PHB) (None - IETF stream)

Version: 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Proposed standard

This RFC does not change the status of any existing RFC. It does,
however, as listed on the title page and in the abstract, updates two
RFCs: 7177 and 7178. These updates are as described in Sections 5 and
11.3.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The TRILL (Transparent Interconnection of Lots of Links) protocol
  supports both point-to-point and multi-access links and is designed
  so that a variety of link protocols can be used between TRILL switch
  ports. This document specifies transmission of encapsulated TRILL
  data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP
  network as a TRILL link in a unified TRILL campus. This document
  updates RFC 7177 and updates RFC 7178.

Working Group Summary

Consensus is strong with one outlier: Joe Touch
regarding use of IPSEC + TCP/UDP
See mail thread:
https://www.ietf.org/mail-archive/web/trill/current/msg08185.html

Why did we choose this approach:
In our working group investigation of this draft,
the WG was visited by vendors implementing TRILL
(most noteable at IETF 91).  The vendors requested
the IPSEC + Transport approach. 
While there are other approaches, no
vendor of TRILL equipment has requested the approach.

Document Quality

Are there existing implementations of the protocol? 
See comments above, hardware vendors looking for line rate speed
came to IETF 91 to give feedback to TRILL.
These vendors were in addition to the Huawei and IPInfusion implementations.

Personnel
Document Shepherd: Susan Hares
AD: Alia Atlas
RTG-QA review: Ines Robles
https://datatracker.ietf.org/doc/review-ietf-trill-over-ip-08-rtgdir-early-robles-2016-12-27/
TSV-Area review: Magnus WEstlund
https://datatracker.ietf.org/doc/review-ietf-trill-over-ip-10-tsvart-early-westerlund-2017-06-15/
[note: Shepherd believes according to Email that Magnus has agreed to all changes]

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Reviewed Draft
2) Discussed the draft concerns with Joe Touch (outlier) via phone
Joe's issuses: Name of draft, and use of GRE with hardware offload, quality of draft.
3) Reviewed resolution to TSV Review and INT review

On name of draft - requested - propose change.
On GRE + Hardware offload - vendors at IETF 91 specifically asked for something else.
Time has gone on, but the WG chooses to go with Trill vendors stated goal.
On quality of writing, authors have addressed technical issues from RTG-QA review,
and TSV-QA review.  More is possible, but we are reaching diminishing returns.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No additional forms.  IANA review should occur during IETF LC.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? 
Discussion above covers it.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Donald Eastlake
https://mailarchive.ietf.org/arch/msg/trill/1zjCvNpD_PejMJOjl8Gj9ljNUDE

Mingui Zhang
https://mailarchive.ietf.org/arch/msg/trill/1eoTyUzdSrBCIKkbusxjenlYFH4

Dacheng Zhang
https://mailarchive.ietf.org/arch/msg/trill/cmeBtvnwvRjcqiU-8fE2drVVCXY

Margaret Cullen
https://www.ietf.org/mail-archive/web/trill/current/msg07773.html

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Major of WG has worked on the issues since IETF 89.
The "please ship it" is the majority view.
I've given you the minority view in discussion above.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Joe Touch (who is the outlier vote) will not block or appeal.
Joe has not actively particpate in IETF discussions since IETF 89.
He has contributed on email list regarding this draft.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits complains about ISO 10589 - (IDNITS folks - please fix)
Normative drafts that is not RFC:
  draft-ietf-tsvwg-le-phb - WG draft only, expected to go RFC

Informative drafts that are not RFC, and expected from other WGs:
draft-ietf-trill-ecn-support -- past WG , at IESG resolution (revised ID needed)
draft-ietf-intarea-tunnels -  expected to head toward RFC

TRILL WG:
draft-ietf-trill-link-gk-profiles- group keying protocol TRILL profile

The last draft deserves a comment.  The security ADs during the
life of this draft have asked about secure key distribution for multicast groups.
The draft-ietf-trill-group-keying was the general purpose protocol the
WG designed to handle this issue. 
The draft-ietf-trill-link-gk-profiles is the adaption of the general purpose
protocol to TRILL.

As TRILL is closing, the draft-ietf-group-keying draft we hope will be
taken on by the security dispatch group.  The draft needs review by
security expert.  If the security dispatch group picks it up as important,
the rtgwg can handle the draft-ietf-trill-link-gk-profiles.
If the security Area feels it is unimportant, then this information reference can be
deleted by the RFC editor.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

One normative reference is not RFC:
    draft-ietf-tsvwg-le-phb - is a WG draft, and expected to progress.
    recommended to deal with congestion.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

See #14 -

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed.

This RFC does not change the status of any existing RFC. It does,
however, as listed on the title page and in the abstract, updates two
RFCs: 7177 and 7178. These updates are as described in Sections 5 and
11.3.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA Considerations look good. This document allocates an IPv4
multicast address, an IPv6 multicast address, and two ports. It also
makes changes to the "RBridge Channel Protocols" registry as descirbed
in item 18 below.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This draft performs surgery on the "RBridge Channel Protocols"
registry on the TRILL Parameters IANA web page. It is renamed to be
the "RBridge Channel Protocols and Link Technology Specific Flags"
registry and a range of the code points in that registry are changed
into a link-technology-dependent set of flag bits. A sub-registry is
then added for the IP technology link type where the flags indicate
encapsulation support and 3 of these flag bit initially
allocated. Future allocations in this new sub-registry are by Expert
Review. Appropriate expertise for this sub-registry is expertise in
TRILL and IP.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.