[trill] draft-ietf-trill-multilevel-single-nickname-13.txt - Shepherd analysis of draft

[Susan Hares <[e-mail]>]

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}.

/