Subject: [secdir] Secdir review of draft-ietf-trill-multilevel-unique-nickname-05

From: Roman Danyliw <[email-masked]>
Date: Sat, 3 Mar 2018 02:00:30 +0000

Reviewer: Roman Danyliw
Review result: Ready with nits

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with nits.

My feedback is as follows:

(1) Section 4.1, Multilevel TRILL Basics, Page 8

Thus Level 1 link state
information stays within a Level 1 area and Level 2 link state
information stays in Level 2 unless there are specific provisions for
leaking (copying) information between levels.

** What are these provisions where such leakage of information should occur beyond expected routing behavior?

(2) Section 4.2, Nickname Allocation, Page 8-9.

Level 2 RBridges contend for nicknames in the range from 0xF000
through 0xFBFF the same way as specified in [RFC6325], using Level 2
LSPs. The highest priority border router for a Level 1 area should
contend with others in Level 2 for smallish blocks of nicknames for
the range from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of
64 boundaries are RECOMMENDED in this document.

** This text provides guidance to allocate nicknames from the range 0x0001 - 0xFBFF (0x0001 - 0xEFFF and 0xF000 - 0xFBFF); and Section 3.7 of RFC6325 says that 0xFFC0 - 0xFFFF and 0x0 are reserved.  Collectively, these two documents leave the range of 0xFC00 - 0xFFBF unspecified.  If that's intentional, describe how these values should be handled. Or, perhaps there a typo and L2 Rbridges should allocate from 0xF000 - 0xFFBF (i.e., s/0xFBFF/0xFFBF/)?
** (Editorial) The language "smallish blocks of nicknames" seems imprecise.

(3) Section 6, Security Considerations, Page 12.

With TRILL multilevel, flooding of control traffic for link state
information of Level 1 and Level 2 is separated. This addresses the
TRILL scalability issues as specified in Section 2 of [RFC8243] and
also confines the effective scope of possible malicious events.

** Per the sentence "With TRILL ... is separated", I recommend clarifying the language on what and in what way there is separation
** Per the follow-up sentence, "... also confines the effective scope of possible malicious events", I recommend discussing in more detail how the scope of malicious events is reduced with this approach.

(4) Section 6, Security Considerations, Page 12.

However, due to the nature that unique nickname areas share a unique
nickname space, border RBridges still have to leak nickname
information between levels. For this purpose, border RBridges need to
fabricate the nickname announcements as specified in Section 4.3.

** As it is raised as an issue with a mitigation, I recommend articulating the implication of leaking nicknames across levels.

(5) Section 6, Security Considerations, Page 12.

Malicious devices may also fake the NickBlockFlags APPsub-TLV to
announce a range of nicknames. By doing this, the attacker can
attract TRILL data packets that are originally to reach a bunch of
other RBridges.

** Recommend articulating the implications of a rogue device changing the path -- it might deny service, expose traffic to inspection, etc.
** (Editorial) Recommend alternate language for the colloquial "... bunch of other RBridges"

(6) Section 6, Security Considerations, Page 12.

For this reason, RBridges SHOULD be configured to
include the IS-IS Authentication TLV (10) in the IS-IS PDUs that
contains the NickBlockFlags APPsub-TLV, so that IS-IS security
([RFC5304] [RFC5310]) can be used to secure the network.

** Should a preference be expressed for RFC5310 over RFC5304?  To quote RFC5310, "[while at the time of this writing there are no openly published attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a], [Dobb96b]) create concern about the ultimate strength of the MD5 cryptographic hash function."

** Recommend being more specific with the language "to secure the network".  Perhaps "For this reason, RBridges SHOULD authenticate their peer by using the IS-IS Authentication TLV (10) in the IS-IS PDUs that contains the NickBlockFlags APPsub-TLV."

(7) Section 6, Security Considerations, Page 12.

If border RBridges do not prune multi-destination distribution tree
traffic in Data Labels that are configured to be area local, then
traffic that should have been contained within an area might be
wrongly delivered to end stations in that Data Label in other areas.
This would generally violate security constraints.

** Recommend being more specific on the security constraints being violated.

(8) There appear to be a few instances of key protocol behavior not using RFC2119 language.  I'd suggest:

Section 3.2.2, Global Distribution Tree, Page 6
(old) Also, this border RBridge needs to advertise the set of local distribution trees by providing another set of nicknames
(new) Also, this border RBridge MUST advertise the set of local distribution trees by providing another set of nicknames

Section 3.2.2, Global Distribution Tree, Page 6
(old) If a border RBridge has been assigned both as a global tree root and a local tree root, it has to acquire both a global tree root nickname(s) and local tree root nickname(s)
(new) If a border RBridge has been assigned both as a global tree root and a local tree root, it MUST acquire both a global tree root nickname(s) and local tree root nickname(s)

Section 4.3, Nickname Announcements, Page 9
(old) Besides its own nickname(s), a border RBridge needs to announce, in its area, the ownership of all external nicknames that are reachable from this border RBridge.
(new) Besides its own nickname(s), a border RBridge MUST announce, in its area, the ownership of all external nicknames that are reachable from this border RBridge.

Section 4.3, Nickname Announcements, Page 9
(old) Also, a border RBridge needs to announce, in Level 2, the ownership of all nicknames within its area. From listening to these Level 2 announcements, border RBridges can figure out the nicknames used by other areas.
(new) Also, a border RBridge MUST announce, in Level 2, the ownership of all nicknames within its area. From listening to these Level 2 announcements, border RBridges can figure out the nicknames used by other areas.

Section 4.3, Nickname Announcements, Page 9
(old) To address this issue, border RBridges should make use of the NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive range of nicknames that are available or not for self allocation by the Level 1 RBridges in that area.
(new) To address this issue, border RBridges SHOULD use the NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive range of nicknames that are available or not for self allocation by the Level 1 RBridges in that area.

Section 4.4, Capability Indication, Page 11
(old) If there are RBridges that do not understand the NickBlockFlags APPsub-TLV, border RBridges of the area will also use the traditional Nickname Sub-TLV [RFC7176] to announce into the area those nicknames covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK is 0.
(new) If there are RBridges that do not understand the NickBlockFlags APPsub-TLV, border RBridges of the area MUST also use the traditional Nickname Sub-TLV [RFC7176] to announce into the area those nicknames covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK is 0.

Section 5, Mix with Aggregated nickname Areas, Page 11
(old) Usage of nickname space must be planed so that nicknames used in any one unique nickname area and Level 2 are never used in any other areas which includes unique nickname areas as well as aggregated nickname areas.
(new) Usage of nickname space MUST be planed so that nicknames used in any one unique nickname area and Level 2 are never used in any other areas which includes unique nickname areas as well as aggregated nickname areas.

Section 5, Mix with Aggregated nickname Areas, Page 11
(old) Border RBridges of an aggregated area need to announce nicknames heard from Level 2 into their area like just like an unique nickname border RBridge.
(new) Border RBridges of an aggregated area MUST announce nicknames heard from Level 2 into their area like just like an unique nickname border RBridge.

Regards,
Roman

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 4 Mar 2018 13:58:10 -0500

Hi Roman,

Thanks for doing a review. See responses below.

> ** What are these provisions where such leakage of information should occur beyond expected routing behavior?

Typically "link state" information stays within a Level 1 area or
within the Level 2 routers. Occasionally there is information that it
is desirable to  flood throughout the domain at both Level 1 and Level
2. IS-IS "link state" information is in the form of TLVs. Typically
this domain wide flooding is accomplished by using two flags in the
value portion of the TLV. One flag indicates the the TLV is to be
flooded domain wide while the other is initially zero and is set when
the TLV is flooded from Level 2 to Level 1 -- this second flag is to
stop a TLV from being flooded from Level 2 to Level 1 and then back to
Level 2 again resulting in TLV looping. See, for example, the IS-IS
Router Capabilities TLV D and S flags as specified in Section 2 of RFC
7981.  This is all standard IS-IS machinery that someone familiar with
IS-IS would know -- there is nothing TRILL specific about it.

> ** This text provides guidance to allocate nicknames from the range 0x0001 - 0xFBFF (0x0001 - 0xEFFF and 0xF000 - 0xFBFF); and Section 3.7 of RFC6325 says that 0xFFC0 - 0xFFFF and 0x0 are reserved.…

I believe it's a typo and is should by 0xF000 - 0xFFBF.

> ** (Editorial) The language "smallish blocks of nicknames" seems imprecise.

I think we could just delete the word "smallish".

> ** Per the sentence "With TRILL ... is separated", I recommend clarifying the language on what and in what way there is separation

This is basic to multilevel IS-IS and anyone familiar with that would
understand. We could add a reference to IS-IS.

> ** Per the follow-up sentence, "... also confines the effective scope of possible malicious events", I recommend discussing in more detail how the scope of malicious events is reduced with this app…

I suggest the following replacement text:

   Since TRILL multilevel uses the existing IS-IS multilevel
facilities [IS-IS], flooding of control traffic for link state
information is automatically confined to a Level 1 area or to Level 2
except (for limited types of information that can be specifically
flagged for wider flooding). This addresses the TRILL scalability
issues as specified in Section 2 of [RFC8243] and also, except of the
wider flooding case, this confines the scope of the effects of
malicious events that could be communicated through the link state.

> ** As it is raised as an issue with a mitigation, I recommend articulating the implication of leaking nicknames across levels.

Since nicknames must be unique across the multi-level domain, and
nicknames in TRILL are auto-allocated, clearly RBridges inside an area
need to know what nicknames are in use, which is the effect and
purpose of leaking nickname claim information across levels. I suggest
the following wording:

    However, due to the nature that unique nickname areas share a
common nickname space, border RBridges still have to leak nickname
information between levels. Such leaking means that nickname related
events in one area can affect other areas. For this purpose, border
RBridges need to fabricate the nickname announcements as specified in
Section 4.3.

> ** Recommend articulating the implications of a rogue device changing the path -- it might deny service, expose traffic to inspection, etc.

This is not that much different from an RBridge announcing low cost to
some MAC address to attract data packets. It is typical that all
routers in some routing domain have to be, to a reasonable extent,
trusted since there is a large variety of information they could
maliciously announce to cause problems. If a rogue router makes false
announcements to attract traffic, typically the traffic goes to that
router and not to the intended destination. Anyone familiar with
common routing techniques would be aware of this.

> ** (Editorial) Recommend alternate language for the colloquial "... bunch of other RBridges"

bunch -> number

> ** Should a preference be expressed for RFC5310 over RFC5304?  To quote RFC5310, "[while at the time of this writing there are no openly published attacks on the HMAC-MD5 mechanism, some reports ([…

I would agree that RFC 5310 security is superior to RFC 5304 security.
Perhaps references to 5304 can be removed.

> ** Recommend being more specific with the language "to secure the network".  Perhaps "For this reason, RBridges SHOULD authenticate their peer by using the IS-IS Authentication TLV (10) in the IS-I…

Suggest replacing "to secure the network" with "to authenticate those
PDUs and discard them if they are forged."

> ** Recommend being more specific on the security constraints being violated

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Mon, 5 Mar 2018 03:49:47 +0000

Hi Donald, Roman,

Thanks a lot for the review! The comments have been incorporated in the 06 version which has been uploaded.

Thanks,
Mingui

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Monday, March 05, 2018 2:58 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
> 
> Hi Roman,
> 
> > I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> >
> Typically "link state" information stays within a Level 1 area or within the Level
> 2 routers. Occasionally there is information that it is desirable to  flood
> throughout the domain at both Level 1 and Level 2. IS-IS "link state"
> information is in the form of TLVs. Typically this domain wide flooding is
> accomplished by using two flags in the value portion of the TLV. One flag
> indicates the the TLV is to be flooded domain wide while the other is initially
> zero and is set when the TLV is flooded from Level 2 to Level 1 -- this second flag
> is to stop a TLV from being flooded from Level 2 to Level 1 and then back to
> Level 2 again resulting in TLV looping. See, for example, the IS-IS Router
> Capabilities TLV D and S flags as specified in Section 2 of RFC 7981.  This is all
> standard IS-IS machinery that someone familiar with IS-IS would know -- there
> is nothing TRILL specific about it.
> 
> > ** This text provides guidance to allocate nicknames from the range 0x0001 -
> 0xFBFF (0x0001 - 0xEFFF and 0xF000 - 0xFBFF); and Section 3.7 of RFC6325 says
> that 0xFFC0 - 0xFFFF and 0x0 are reserved.  Collectively, these two documents
> leave the range of 0xFC00 - 0xFFBF unspecified.  If that's intentional, describe
> how these values should be handled. Or, perhaps there a typo and L2 Rbridges
> should allocate from 0xF000 - 0xFFBF (i.e., s/0xFBFF/0xFFBF/)?
> 
> > ** Per the sentence "With TRILL ... is separated", I recommend
> > clarifying the language on what and in what way there is separation
> 
> This is basic to multilevel IS-IS and anyone familiar with that would understand.
> We could add a reference to IS-IS.
> 
> > ** Per the follow-up sentence, "... also confines the effective scope of
> possible malicious events", I recommend discussing in more detail how the
> scope of malicious events is reduced with this approach.
> 
>    Since TRILL multilevel uses the existing IS-IS multilevel facilities [IS-IS],
> flooding of control traffic for link state information is automatically confined to
> a Level 1 area or to Level 2 except (for limited types of information that can be
> specifically flagged for wider flooding). This addresses the TRILL scalability
> issues as specified in Section 2 of [RFC8243] and also, except of the wider
> flooding case, this confines the scope of the effects of malicious events that
> could be communicated through the link state.
> 
> > ** As it is raised as an issue with a mitigation, I recommend articulating the
> implication of leaking nicknames across levels.
> 
> Since nicknames must be unique across the multi-level domain, and nicknames
> in TRILL are auto-allocated, clearly RBridges inside an area need to know what
> nicknames are in use, which is the effect and purpose of leaking nickname claim
> information across levels. I suggest the following wording:
> 
>     However, due to the nature that unique nickname areas share a common
> nickname space, border RBridges still have to leak nickname information
> between levels. Such leaking means that nickname related events in one area
> can affect other areas. For this purpose, border RBridges need to fabricate the
> nickname announcements as specified in Section 4.3.
> 
> > announce a range of nicknames. By doing this, the attacker can attract
> > TRILL data packets that are originally to reach a bunch of other
> > RBridges.
> >
> > ** Recommend articulating the implications of a rogue device changing the
> path -- it might deny service, expose traffic to inspection, etc.
> 
> This is not that much different from an RBridge announcing low cost to some
> MAC address to attract data packets. It is typical that all routers in some
> routing domain have to be, to a reasonable extent, trusted since there is a
> large variety of information they could maliciously announce to cause problems.
> If a rogue router makes false announcements to attract traffic, typically the
> traffic goes to that router and not to the intended destination. Anyone familiar
> with common routing techniques would be aware of this.
> 
> > For this reason, RBridges SHOULD be configured to include the IS-IS
> > Authentication TLV (10) in the IS-IS PDUs that contains the
> > NickBlockFlags APPsub-TLV, so that IS-IS security ([RFC5304]
> > [RFC5310]) can be used to secure the network.
> >
> > ** Should a preference be expressed for RFC5310 over RFC5304?  To quote
> RFC5310, "[while at the time of this writing there are no openly published
> attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a], [Dobb96b])
> create concern about the ultimate strength of the MD5 cryptographic hash
> function."
> 
> > ** Recommend being more specific with the language "to secure the
> network".  Perhaps "For this reason, RBridges SHOULD authenticate their
> peer by using the IS-IS Authentication TLV (10) in the IS-IS PDUs that contains
> the NickBlockFlags APPsub-TLV."
> 
> Suggest replacing "to secure the network" with "to authenticate those PDUs
> and discard them if they are forged."
> 
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 6 Mar 2018 15:25:17 +0000

Hi Donald,

> Sent: Sunday, March 04, 2018 1:58 PM
> Cc: [email-masked]; [email-masked]; draft-ietf-trill-multilevel-unique-
> [email-masked]
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> >
> Typically "link state" information stays within a Level 1 area or within the
> Level 2 routers. Occasionally there is information that it is desirable to  flood
> zero and is set when the TLV is flooded from Level 2 to Level 1 -- this second
> flag is to stop a TLV from being flooded from Level 2 to Level 1 and then back
> to Level 2 again resulting in TLV looping. See, for example, the IS-IS Router
> standard IS-IS machinery that someone familiar with IS-IS would know --
> there is nothing TRILL specific about it.

Understood.  I was struggled with the wording "... unless there are specific ..." as this didn't imply to me a fixed set of previously understood constraints.  I would have chosen "... beyond the expected provisions ... between levels necessary for protocol function."

[snip]
 
> understand. We could add a reference to IS-IS.

Agreed.  It makes sense to add the reference.

> flooding of control traffic for link state information is automatically confined
> to a Level 1 area or to Level 2 except (for limited types of information that
> can be specifically flagged for wider flooding). This addresses the TRILL
> scalability issues as specified in Section 2 of [RFC8243] and also, except of the
> wider flooding case, this confines the scope of the effects of malicious
> events that could be communicated through the link state.

The suggested wording works for me.

> nicknames in TRILL are auto-allocated, clearly RBridges inside an area need to
> know what nicknames are in use, which is the effect and purpose of leaking
> nickname claim information across levels. I suggest the following wording:
> 
> between levels. Such leaking means that nickname related events in one
> area can affect other areas. For this purpose, border RBridges need to

The suggested wording works for me.

[snip]
> attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a],
> [Dobb96b]) create concern about the ultimate strength of the MD5
> cryptographic hash function."
> 

I'd recommend the more agile RFC5310 too.

> and discard them if they are forged."

The suggested wording works for me.

[snip]

Thanks,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 6 Mar 2018 16:31:45 +0000

Hi Donald and Mingui!

Thanks for the changes in -06.  Any thoughts on item (8)?

Roman

> From: Roman Danyliw
> Sent: Friday, March 02, 2018 9:01 PM
> To: [email-masked]; [email-masked]; draft-ietf-trill-multilevel-unique-
> [email-masked]
> Subject: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
 
[snip]

> (old) Also, this border RBridge needs to advertise the set of local distribution
> trees by providing another set of nicknames
> (new) Also, this border RBridge MUST advertise the set of local distribution
> trees by providing another set of nicknames
> 
> (old) If a border RBridge has been assigned both as a global tree root and a
> local tree root, it has to acquire both a global tree root nickname(s) and local
> tree root nickname(s)
> (new) If a border RBridge has been assigned both as a global tree root and a
> local tree root, it MUST acquire both a global tree root nickname(s) and local
> tree root nickname(s)
> 
> (old) Besides its own nickname(s), a border RBridge needs to announce, in its
> area, the ownership of all external nicknames that are reachable from this
> border RBridge.
> (new) Besides its own nickname(s), a border RBridge MUST announce, in its
> area, the ownership of all external nicknames that are reachable from this
> border RBridge.
> 
> (old) Also, a border RBridge needs to announce, in Level 2, the ownership of
> all nicknames within its area. From listening to these Level 2 announcements,
> border RBridges can figure out the nicknames used by other areas.
> (new) Also, a border RBridge MUST announce, in Level 2, the ownership of all
> nicknames within its area. From listening to these Level 2 announcements,
> border RBridges can figure out the nicknames used by other areas.
> 
> (old) To address this issue, border RBridges should make use of the
> NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive
> range of nicknames that are available or not for self allocation by the Level 1
> RBridges in that area.
> (new) To address this issue, border RBridges SHOULD use the NickBlockFlags
> APPsub-TLV to advertise into the Level 1 area the inclusive range of
> nicknames that are available or not for self allocation by the Level 1 RBridges
> in that area.
> 
> (old) If there are RBridges that do not understand the NickBlockFlags
> APPsub-TLV, border RBridges of the area will also use the traditional
> Nickname Sub-TLV [RFC7176] to announce into the area those nicknames
> covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK
> is 0.
> (new) If there are RBridges that do not understand the NickBlockFlags
> APPsub-TLV, border RBridges of the area MUST also use the traditional
> Nickname Sub-TLV [RFC7176] to announce into the area those nicknames
> covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose OK
> is 0.
> 
> (old) Usage of nickname space must be planed so that nicknames used in any
> one unique nickname area and Level 2 are never used in any other areas
> which includes unique nickname areas as well as aggregated nickname areas.
> (new) Usage of nickname space MUST be planed so that nicknames used in
> any one unique nickname area and Level 2 are never used in any other areas
> which includes unique nickname areas as well as aggregated nickname areas.
> 
> (old) Border RBridges of an aggregated area need to announce nicknames
> heard from Level 2 into their area like just like an unique nickname border
> RBridge.
> (new) Border RBridges of an aggregated area MUST announce nicknames
> heard from Level 2 into their area like just like an unique nickname border
> RBridge.
> 
> Regards,
> Roman

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Wed, 7 Mar 2018 03:15:56 +0000

Hi Roman,

All changes you suggested in item (8) are fair. I've made these changes into the 07 version. Awaiting for uploading. 

Thanks,
Mingui

> From: Roman Danyliw [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2018 12:32 AM
> To: [email-masked]; [email-masked];
> Subject: RE: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
> 
> Hi Donald and Mingui!
> 
> > Subject: Secdir review of
> > draft-ietf-trill-multilevel-unique-nickname-05
> 
> [snip]
> 
> > (8) There appear to be a few instances of key protocol behavior not
> > using
> > RFC2119 language.  I'd suggest:
> >
> > (old) Also, this border RBridge needs to advertise the set of local
> > distribution trees by providing another set of nicknames
> > (new) Also, this border RBridge MUST advertise the set of local
> > distribution trees by providing another set of nicknames
> >
> > (old) If a border RBridge has been assigned both as a global tree root
> > and a local tree root, it has to acquire both a global tree root
> > nickname(s) and local tree root nickname(s)
> > (new) If a border RBridge has been assigned both as a global tree root
> > and a local tree root, it MUST acquire both a global tree root
> > nickname(s) and local tree root nickname(s)
> >
> > (old) Besides its own nickname(s), a border RBridge needs to announce,
> > in its area, the ownership of all external nicknames that are
> > reachable from this border RBridge.
> > (new) Besides its own nickname(s), a border RBridge MUST announce, in
> > its area, the ownership of all external nicknames that are reachable
> > from this border RBridge.
> >
> > (old) Also, a border RBridge needs to announce, in Level 2, the
> > ownership of all nicknames within its area. From listening to these
> > Level 2 announcements, border RBridges can figure out the nicknames used
> by other areas.
> > (new) Also, a border RBridge MUST announce, in Level 2, the ownership
> > of all nicknames within its area. From listening to these Level 2
> > announcements, border RBridges can figure out the nicknames used by other
> areas.
> >
> > NickBlockFlags APPsub-TLV to advertise into the Level 1 area the
> > inclusive range of nicknames that are available or not for self
> > allocation by the Level 1 RBridges in that area.
> > (new) To address this issue, border RBridges SHOULD use the
> > NickBlockFlags APPsub-TLV to advertise into the Level 1 area the
> > inclusive range of nicknames that are available or not for self
> > allocation by the Level 1 RBridges in that area.
> >
> > covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose
> > OK is 0.
> > covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose
> > OK is 0.
> >
> > (old) Usage of nickname space must be planed so that nicknames used in
> > any one unique nickname area and Level 2 are never used in any other
> > areas which includes unique nickname areas as well as aggregated nickname
> areas

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Mar 2018 22:19:14 -0500

Thank you, Roman for the review and authors for the responses and updates!

Kathleen

-- 

Best regards,
Kathleen

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Mar 2018 21:30:48 -0400

Hi Roman,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
uploaded. I believe this resolves all of your comments.

Thanks,
Donald

---

From: Roman Danyliw <[email-masked]>
Date: Sat, 17 Mar 2018 14:51:46 +0000

Hello Donald!

Thanks for making these changes in -07.

This addresses all of my feedback.

Roman

> Sent: Wednesday, March 14, 2018 9:31 PM
> [email-masked]; Zhangmingui (Martin) <[email-masked]>
> A -07 version of draft-ietf-trill-multilevel-unique-nickname has been uploaded.
> I believe this resolves all of your comments.
> 
> Thanks,
> Donald
> >> Subject: RE: Secdir review of
> >> > (old) If a border RBridge has been assigned both as a global tree
> >> > root and a local tree root, it has to acquire both a global tree
> >> > root
> >> > (new) If a border RBridge has been assigned both as a global tree
> >> > root and a local tree root, it MUST acquire both a global tree root
> >> > (old) Besides its own nickname(s), a border RBridge needs to
> >> > announce, in its area, the ownership of all external nicknames that
> >> > are reachable from this border RBridge.
> >> > (new) Besides its own nickname(s), a border RBridge MUST announce,
> >> > (new) Also, a border RBridge MUST announce, in Level 2, the
> >> > Level 2 announcements, border RBridges can figure out the nicknames
> >> > used by other
> >> areas.
> >> >
> >> > (old) If there are RBridges that do not understand the
> >> > NickBlockFlags APPsub-TLV, border RBridges of the area will also
> >> > use the traditional Nickname Sub-TLV [RFC7176] to announce into the
> >> > area those nicknames covered by the nickname blocks of the
> >> > NickBlockFlags APPsub-TLV whose OK is 0.
> >> > (new) If there are RBridges that do not understand the
> >> > NickBlockFlags APPsub-TLV, border RBridges of the area MUST also
> >> > use the traditional Nickname Sub-TLV [RFC7176] to announce into the
> >> > area those nicknames covered by the nickname blocks of the
> >> > NickBlockFlags APPsub-TLV whose OK is 0.
> >> >
> >> > (old) Usage of nickname space must be planed so that nicknames used
> >> > in any one unique nickname area and Level 2 are never used in any
> >> > other areas which includes unique nickname areas as well as
> >> > aggregated nickname
> >> areas