Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Alvaro Retana]

Thanks Donald!

On March 15, 2018 at 1:25:07 AM, Donald Eastlake (d3e...@gmail.com) wrote:

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Alvaro Retana]

On March 7, 2018 at 4:48:35 PM, Donald Eastlake (d3e...@gmail.com) wrote:

Are these changes satisfactory?


Yes, these changes work for me.

Thanks!

Alvaro.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-multilevel-unique-nickname-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/



--
COMMENT:
--

(1) The nickname selection process for multilevel is not backwards compatible
because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
border RBridges can recognize "old" Rbridges (ones that don't support this
specification) in an area. A couple of related comments:

(1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in an
area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
somewhat contradictory (maybe that's not the right word, but the only one that
comes to mind):

- On one hand, non border RBridges could be just be "old" (ones that don't
support this specification).  We can't normatively specify something that by
definition nodes that don't support this specification won't know about.

- On the other hand, if the non border Rbridge does support this specficiation,
then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why isn't
the "SHOULD" a "MUST" instead?  When is it ok to not do it?

All this is to say that I think that "SHOULD" should not be used normatively. 
s/SHOULD/should

(1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
to expect that networks implementing these multilevel extensions will grow from
a single area to multiple.  It would be ideal to include Deployment
Considerations to discuss what a Migration Path would look like.

(2) Maybe I missed it somewhere...  The Security Considerations section says
that "border RBridges need to fabricate the nickname announcements...Malicious
devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
nicknames."  I'm sure that malicious devices don't only include ones that are
unauthenticated, but may include over or under claiming by existing border
RBridges or even non border RBridges originating the NickBlockFlags APPsub-TLV.

(2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to border
RBridges?  If so, why isn't there a check to make sure that the NickBlockFlags
APPsub-TLV came from a border RBridge?

(2.2) rfc8243 talks about the (potential) ability of border RBridges to
"discover each other...by using the IS-IS "attached bit" [IS-IS] or by
explicitly advertising in their LSP "I am a border RBridge".  But I didn't see
these options/mechanisms mentioned in this document.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-multi-topology-05: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-multi-topology-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-multi-topology/



--
COMMENT:
--

The extensions defined in this document are "an optional TRILL switch
capability".  To me, that indicates that the base TRILL specifications rfc6325
and rfc7177 (in this case) are not affected: an RBridge is TRILL-compliant as
long as it implements what rfc6325 specifies (without these optional
extensions).  I would then like to see the formal "Updates" tags removed.

[The publication of this document is not the place to argue about the meaning
of "Updates", so I'll defer to what the Responsible AD decides.]


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Alvaro Retana]

On March 5, 2018 at 3:27:43 PM, Donald Eastlake (d3e...@gmail.com) wrote:

I'm not sure how using "an incorrect mapping" is that different from
just using whatever nicknames it feels like...

Exactly!

The endnode can do anything it wants.  BTW, I just made the same comment
for draft-ietf-trill-smart-endnodes — we should be able to solve both in
one update (to draft-ietf-trill-smart-endnodes).

Thanks!

Alvaro.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-smart-endnodes-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/



--
DISCUSS:
--

This document feels tightly coupled with
draft-ietf-trill-directory-assisted-encap, even though there are no
cross-references.  If I understand the mechanisms correctly, a Smart Endnode
(discussed in this draft) can then do directory assisted encapsulation
(described in draft-ietf-trill-directory-assisted-encap).  In fact, the
encapsulation/decapsulation seems to be the main motivation in defining a Smart
Endnode.

I think then that this document also falls short in the exploration of
potential issues, so I am also balloting DISCUSS.  The same cases that I
pointed at for draft-ietf-trill-directory-assisted-encap [1] are applicable
here -- with the added caveat that the Smart Endnode, in general, has other
sources of information (learning, etc.), which means that there are potentially
more doors to close.

The Multi-homing Scenario (Section 6) adds some complexity to the ability to
check whether the Ingress RBridge is set correctly in the encapsulation.  It
would be nice to explore this case a little further and highlight the issues as
the topologies get more complex.

As I wrote in [1], I don't think that there are easy mitigations for these
issues, but at least mentioning them so that operators are aware of the risk
would be enough to clear this DISCUSS.  Given that the authors partially
overlap, it may be a good idea to solve the issue in this document (which is
the general case) and then just have the other one point this way.

[1]
https://mailarchive.ietf.org/arch/msg/trill/xZvEj_9FtSgHSp4DnKCVxr670gc/?qid=1e5a9496ac80237a3f7cc6aeea09d24d




___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-directory-assisted-encap-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/



--
DISCUSS:
--

I have significant concerns about this document; as currently written, I
believe the technology is underspecified and can cause significant damage to a
DC network where it might be deployed.  I am then balloting a DISCUSS.

The document (including the security considerations) is written assuming that
the TRILL-ENs can be trusted (and are not compromised), and that the directory
information is accurate.  However, I believe there are several cases that have
been overlooked.

(1) There aren't any basic safeguards specified to at least make sure that a
TRILL-EN is doing the right thing (or something sensible).  For example, what
if the Ingress RBridge Nickname field in the TRILL header doesn't correspond to
the first rBridge at the domain boundary?  Should that frame be accepted?

(2) rfc8171 talks about issues with incorrect directory mappings.  Consider the
case where a TRILL-EN uses (on purpose!) an incorrect mapping.  That "can
result in data being delivered to the wrong end stations, or set of end
stations in the case of multi-destination packets, violating security policy."
[rfc8171]  How can this risk be mitigated?

I don't think that there are easy mitigations for these issues, but at least
mentioning them so that operators are aware of the risk would be enough to
clear this DISCUSS.




___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-address-flush-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/



--
COMMENT:
--

I have some non-blocking comments/questions:

(1) Why are the 2 VLAN Block encodings needed?  More important, when should
each be used?  Section 2.2 says that "All RBridges implementing the Address
Flush RBridge Channel message MUST implement types 1 and 2, the VLAN types...",
but I didn't see anything about the VLAN Block Only Case (2.1).  I'm wondering
if there will be cases where the support won't match and the message will then
be ineffective.

(2) In the 2.2.* sections, the description of some of the TLVs says (when the
Length is incorrect) that "...the Address Flush message MUST be discarded if
the receiving RBridge implements Type x".  What if that type is not supported
-- I would assume you still want to discard?  BTW, the Type 5 description
doesn't qualify dropping based on the type support.

(2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding).
 Is there an intended difference in the behavior?

(3) Section 2 says that "Address Flush protocol messages are usually sent as
multi-destination packets...Such messages SHOULD be sent at priority 6".  It is
not clear to me whether unicast packets (mentioned later) should also have the
same priority.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-p2mp-bfd-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-p2mp-bfd/



--
COMMENT:
--

(1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5; please
add one in the Introduction when Multipoint BFD is initially mentioned.

(2) I think that using Normative Language (without quotation marks) to mention
what is specified somewhere else can result in confusion as to which is the
authoritative document.  This seems to be the case in Section 4: "If the M bit
of the TRILL Header of the RBridge channel packet containing a BFD Control
packet is non-zero, the packet MUST be dropped [RFC7175]."  The sentence sounds
as if the behavior is specified in rfc7175, but that document says (in Section
3.2 (BFD Control Frame Processing)): "The following tests SHOULD be
performed...Is the M bit in the TRILL Header non-zero?  If so, discard the
frame."  Note that the behavior specified in rfc7175 doesn't use a "MUST".  The
text in this document seems to be used to explain why a new message is needed,
and not in a Normative way -- please clarify the text so that there is no
inconsistency with respect to rfc7175.

(3) Section 5 says that the "processing in Section 3.2 of [RFC7175]
applies...If the M bit is zero, the packet is discarded."  Section 3.2 has that
"SHOULD" that I mentioned above, and it also mentions potential security
issues, which are not referenced in this document.  Are there reasons to keep
the "SHOULD" and not use "MUST" instead (for the p2mp case)?  If the same
semantics as in rfc7175 are kept, then the Security Considerations should
include the concerns.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-centralized-replication-11: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-centralized-replication-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/



--
COMMENT:
--

I have some non-blocking comments.  I would like to see the ones related to
Normative Language addressed before publication.

- From the Abstract: "RPF checks on each RBridge MUST be calculated as if the
centralized node was the ingress RBridge..."  Using Normative Language in the
Abstract seems strange to me, specially since the same language is not used
later in the text.  The document does get to the same point later, but not with
the same language.

- The Introduction says that "...a centralized node, which SHOULD be a
distribution tree root", but Section 3 says otherwise: "The centralized node
MUST be a distribution tree root."  Suggestion: use Normative Language in just
one place.  IMO, the Introduction may not be the right place for it.

- BTW, what is a "distribution tree root"?  The definition is probably
intuitive since we're talking about replication, but explicitly defining it
would clear any possible confusion.

- I appreciate the background and the description of the problem and the
mechanism, but there's a lot of repetition.  Section 3 presents for the third
time an overview of the mechanism -- Abstract, Introduction, and Section
3...note that even the last paragraph repeats information about the replication
from this same section.

- Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname
flag on the pseudo-nickname it is using. This is already mandatory behavior..."
If "already mandatory" then there's no need to use Normative Language here,
right?

- Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm not
sure if I understand correctly, but because there's a distinction between the
R-nickname and the C-nickname, both bits should not be set at the same time,
right?  What happens if they are?  It seems that the last paragraph tries to
address that question ("due to errors")...but I'm then not sure what the action
is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was
set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set."
Again, what if both are set?  And "RECOMMENDED" implies that there are reasons
not to do it this way...what are those cases?


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-rbridge-multilevel-07: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-rbridge-multilevel-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/



--
COMMENT:
--

This document "enumerates and examines alternatives" related to multilevel
TRILL.  It provides useful information, but I think its publication might be
premature given that, for example, the work on unique and aggregated nicknames
is still in progress in the WG -- even if that work is stable, there's still a
(maybe small) probability of this document falling out of sync.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS)

[Alvaro Retana (aretana)]

Donald:

Thanks for the clarification.

I just cleared.

Alvaro.



On 3/11/17, 5:53 AM, "Donald Eastlake"  wrote:

Could you look at version -05 which is intended to resolve your
DISCUSS as discussed below.

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-rfc6439bis-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/



--
DISCUSS:
--

Section 2.4 (Overload and Appointed Forwarders) talks about potential
Appointed Forwarders which are overloaded.  In IS-IS, a node with the
overload bit set "shall not" (ISO 10589) be considered for transit. 
However, the use of "SHOULD NOT appoint an RBridge in overload" and
"SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential
hole in the proper forwarding of TRILL data packers.  Why aren't MUST
NOT/MUST used?  Is there something in the specific use of IS-IS by TRILL
that I am missing?

I think this should be an easy DISCUSS to clear; either point to the
piece I'm missing, or don't use an overloaded node.




___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-directory-assist-mechanisms-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/



--
COMMENT:
--

I would like to see some more information related to the overall
operation of the network, including guidance on how/when to use different
mechanisms and their location.  Specifically, I think this document
should include more information in these cases:

[1] Server Learning and Advertisement of information in ESADI [RFC7357]
using the Reachable MAC Addresses TLV [RFC6165].

I don't think it is explicit in the document, but I'm assuming that the
Servers (for both Push and Pull) learn using the mechanisms in Section
4.8.1. (Learning End-Station Addresses) of RFC6325.  One of those
mechanisms is to use ESADI...Section 2.5 (Additional Push Details)
says:

   TRILL switches, whether or not they are a Push Directory server, MAY
   continue to advertise any locally learned MAC attachment information
   in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].
   However, if a Data Label is being served by complete Push Directory
   servers, advertising such locally learned MAC attachment generally
   SHOULD NOT be done as it would not add anything and would just waste
   bandwidth and ESADI link state space. An exception might be when a
   TRILL switch learns local MAC connectivity and that information
   appears to be missing from the directory mapping.

It seems to me that a switch advertising information in ESADI using the
Reachable MAC Addresses TLV is independent of whether Push or Pull is
being used on the network (or for a specific Data Label), so I think my
questions/comments below apply to both.

I understand why using the information in the Reachable MAC Addresses TLV
may be redundant, but as the text points out, there are cases where it
may be a good thing.  I would like to see guidelines or suggestions on
the use of "traditional" ESADI learning (RFC7357) in Section 4.
(Directory Use Strategies and Push-Pull Hybrids).  This section already
talks about what a TRILL switch may do if it doesn't have complete
information, but it doesn't talk about what a Directory Server could
do.

Related to the above, if ESADI [RFC7357] using the Reachable MAC
Addresses TLV [RFC6165] does't really add anything to the Push Directory
service, then it seems to me that they would be equivalent (the outcome
is the same) -- when should one be used over the other?  Are there cases
where the centralized service may not scale and is better to adopt a
distributed strategy?  It seems to me than the options in Section 4.
(Directory Use Strategies and Push-Pull Hybrids) may not be just between
Pull and Push...


[2] Location and Priority of Push Directory Servers

Section 2.2 (Push Directory Servers) talks about PushDirPriority, but
there are no guidelines as to how it should be set by an operator.  I
suspect that a higher priority may want to be assigned to Directory
Servers with a higher density of connected high-use stations...or maybe
not, which is why I would like you to provide some guidance.


[3] Location and Number of Requests for Pull Directory Servers

Section 3.(Pull Model Directory Assistance Mechanisms) reads:

   If multiple data reachable TRILL switches indicate in the link state
   database that they are Pull Directory Servers for a particular Data
   Label, pull requests can be sent to any one or more of them but it
is
   RECOMMENDED that pull requests be preferentially sent to the server
   or servers that are lowest cost from the requesting TRILL switch.

Are there guidelines related to the location (and number) of these
servers?

When would a switch not send a request to the server(s) with the lowest
cost?  IOW, why "RECOMMENDED" and not "MUST"?

How many servers should the request be sent to?  For the Push case, a
default of 2 copies is specified -- should 2 requests be enough?  Are
there cases where more are needed?


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-channel-tunnel-10: (with DISCUSS and COMMENT)

[Alvaro Retana (aretana)]

On 8/5/16, 11:46 PM, "Donald Eastlake" 
> wrote:

Version -11 of this draft has been posted which is intended to resolve your 
DISCUSS.

It does.  I'm clearing.  Thanks!

Alvaro.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Alvaro Retana's Discuss on draft-ietf-trill-channel-tunnel-10: (with DISCUSS and COMMENT)

[Alvaro Retana]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-channel-tunnel-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-channel-tunnel/



--
DISCUSS:
--

Even though the IANA Considerations section was just updated (in version
-10), I am putting in this DISCUSS because it is still
incomplete/incorrect.

1. Guidance for managing the SubERR namespace should be included.  Note
that this document only specifies values for ERR 6, but guidance should
be given to IANA for the other ERR values as well.

2. Section 6.2.1 (RBridge Channel Error Codes Subregistry) requests the
creation of a new registry ("RBridge Channel Error Codes”), but that
registry was already created by RFC7178.  This document should then split
the requests in two parts: assignment of the vales 6-8, and the change to
the registration procedure.


--
COMMENT:
--

>From Section 2. (RBridge Channel Header Extension Format), is the RESV4
field a space that is reserved for potential future use?  Why isn’t it
ignored on receipt (similar to the RESV field in Section 4.3)?  If there
is potential for use of this space (RESV is defined as 4 bits, which
makes me think about potential bit-level allocations), then there should
be some guidance in the IANA Considerations.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill