Martin:
This is a very overdue shepherd report on the AD sponsored draft: draft-ietf-trill-multilevel-single-nickname-13.txt https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname / I am sending this to the TRILL WG mail list so the IESG can find it. If you have another place you wish to send it, please let me know. Sue ------------- Trill Shepherd review: draft-ietf-trill-multilevel-single-nickname-13.txt Status: AD Sponsor (due to TRILL WG closure) Comments: Ready for publication with editorial nits only Editorial nits: strongly suggested fix: section 6, page 12, the section below is unclear. A fix is proposed. Current: / For a multicast packet: suppose RB1 is not the DBRB, RB1 will not transition the packet; otherwise, RB1 is the DBRB, - if this packet originated from an area out of the connected areas, RB1 replicates this packet and floods it on the proper Level 1 trees of all the areas in which it acts as the DBRB. - if the packet originated from one of the connected areas, RB1 replicates the packet it receives from the Level 1 tree and floods it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface). RB1 might also receive the replication of the packet from the Level 2 tree. This replication MUST be dropped by RB1. It recognizes such packets by their ingress nickname being the nickname of one of the border RBridges of an L1 area to which the receiving border RBridge is attached. / Proposed new: / For a multicast packet: either RB1 is not the DBRB and RB1 will not transition the packet or RB1 is the DBRB. If RBI is the DBRB, RB follows the following rules: - if this packet originated from an area out of the connected areas, RB1 replicates this packet and floods it on the proper Level 1 trees of all the areas in which it acts as the DBRB. - if the packet originated from one of the connected areas, RB1 replicates the packet it receives from the Level 1 tree and floods it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface). RB1 might also receive the replication of the packet from the Level 2 tree. This replication MUST be dropped by RB1. It recognizes such packets by their ingress nickname being the nickname of one of the border RBridges of an L1 area to which the receiving border RBridge is attached. / Optional fixes: #1 Section 3.1 page 6 - changes /so replace/ with /replacing/ - grammar issue current: / - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, so replaces 27 with 2. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. / New / - RB2, when transitioning the packet from Level 1 to Level 2, replacing the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. / #2 section 3.2, page 7 - change of commas to parentheses Current: / happen within a Level 1 area, as it would in TRILL today, is that RB27 will forward the packet as multi-destination, setting its M bit to 1 and choosing an L1 tree, flooding the packet on the distribution tree, subject to possible pruning. / New: happen within a Level 1 area (as it would in TRILL today) is that RB27 will forward the packet as multi-destination, setting its M bit to 1 and choosing an L1 tree, flooding the packet on the distribution tree, subject to possible pruning. / #3 - section 3.2, page 7 - changes /so replace/ with /replacing/ - grammar issue replaces , say 2, (say 2) - clarity issue current: / - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, so replaces 27 with 2. RB2 also needs to replace the egress RBridge nickname with an L2 tree root RBridge nickname, say 2. In order to accommodate return traffic, RB2 records that S is attached to nickname 27 and SHOULD use ESADI protocol [RFC7357] to synchronize this attachment information with other border RBridges (say RB20) in the area. / New / - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. RB2 also needs to replace the egress RBridge nickname with an L2 tree root RBridge nickname (say 2), In order to accommodate return traffic, RB2 records that S is attached to nickname 27 and SHOULD use ESADI protocol [RFC7357] to synchronize this attachment information with other border RBridges (say RB20) in the area. / #4 - section 3.2. page 7 changes , say 3 to (say 3) and replaces parentheses with [] current: / - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with a root RBridge nickname, say 3, of the distribution tree of L1 area {3,30}. (Here, the ingress nickname MAY be replaced with a different area nickname selected from {2,20}, the set of border RBridges to the ingress area, as specified in Section 4.) Now suppose that RB27 has learned the location of D (attached to nickname 3), but RB3 does not know where D is. In that case, RB3 must turn the packet into a multi- destination packet and floods it on the distribution tree of L1 area {3,30}. / new:/ - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with a root RBridge nickname (say 3) of the distribution tree of L1 area {3,30}. [Here, the ingress nickname MAY be replaced with a different area nickname selected from {2,20}, the set of border RBridges to the ingress area, as specified in Section 4.] Now suppose that RB27 has learned the location of D (attached to nickname 3), but RB3 does not know where D is. In that case, RB3 must turn the packet into a multi- destination packet and floods it on the distribution tree of L1 area {3,30}. /
_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
