Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

From: Mingui Zhang <[email-masked]>
Date: Mon, 3 Aug 2015 03:45:13 +0000

Hi Alia,

Please see comments inline with [mingui].

From: trill [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, July 31, 2015 6:30 AM
To: [email-masked]; [email-masked]; Don Eastlake
Subject: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

First, let me thank Hongjun, Tissa, Radia, Mingui, and Yizhou, the authors of this fine draft, for their hard work in producing a document that is easy to read and very detailed.

As is customary, I've done my AD review of this draft before requesting IETF Last Call.  I do have a few questions and clarifications which I will describe.

I intend to review the other two associated trill drafts tomorrow and progress all 3 to an IETF Last Call with a target of getting on the Aug 20 IESG telechat.  If that telechat gets too full, they might need to move to two weeks later.

As we finally push through on this process, having very responsive authors helps immensely in getting drafts through the process.

Here are the details of my review:

Minor concerns:

1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The basic
idea of DF is to elect one RBridge per VLAN from an RBv to egress
multi-destination TRILL Data traffic and replicate locally-received
multi-destination native frames to the CEs served by the RBv."  but
then on p. 16 in Step 4 part 1), it says: "RBv ports associated with
the same pseudo-nickname as that of the incoming port, no matter
whether RBi is the DF for the frame's VLAN on the outgoing ports
except that the frame MUST NOT be replicated back to the incoming
port".  This seems to be contradictory.

[mingui] Let me explain the logic. If the RBridge in a RBv group receives a BUM packet from a locally connected CE.  Other CEs will receive the packet replicated by the DF only. Other RBridges will refrain from replicating.
Having said that, it is also important that the DF never replicates the BUM packet back to the incoming port (Say CE1 sends the BUM packet to the DF RB1 via port 1, then RB1 does not send the replicated BUM packet back to CE1 via port 1.)

Moreover, if one say CE1,
CE2, and CE3 all in the same RBv, when CE1 sends a packet to RB2 and
RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward the
packet to CE1 and CE2 while RB1 would also do so as the DF?

[mingui] As explained above, RB2 will refrain from replicating since it is not the DF.

Could you
please clarify what is causing the inconsistency and problem?  Maybe
the text in 6.1 on p. 18 helps describe that there are actually two
cases to the text on p. 16?

[mingui] Yes, I agree.

2) On p.23 in Sec 9.1: There is no way of identifying what the type of
the LAALP ID is.  Assuming it is a number and meaning doesn't matter,
it would be really good to clarify that.

[mingui] Agree.

3) In Sec 9.2: How can an LAALP ID be withdrawn from PN-RBv
APPsub-TLV?  Could you please describe that sequence?

[mingui] I think, if RBx needs to just withdraw one LAALP ID, it will refresh the previous announced LSP by omitting that LAALP ID from the LAALP ID list in the PN-RBv APPsub-TLV.

Thanks,
Mingui

Thanks,
Alia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 5 Aug 2015 23:07:50 -0400

See below

On Sun, Aug 2, 2015 at 11:45 PM, Mingui Zhang <[email-masked]> wrote:
> ...
> [mingui] Let me explain the logic. If the RBridge in a RBv group receives a
> BUM packet from a locally connected CE.  Other CEs will receive the packet
> replicated by the DF only. Other RBridges will refrain from replicating.
>    Having said that, it is also important that the DF never replicates the BUM
> packet back to the incoming port (Say CE1 sends the BUM packet to the DF RB1
> via port 1, then RB1 does not send the replicated BUM packet back to CE1 via
> port 1.)
>

Probably the wording can be clarified.

> it would be really good to clarify that.

The general requirement is that the LAALP ID identify the
active-active edge group of end stations and the LAALP for a
particular group must be unique across the TRILL campus. As far as I
know, currently the only type of value used for the LAALP ID is an
8-byte MC-LAG/DRNI ID. Perhaps the document should (1) indicate the
general requirement, (2) state that if the length is 8 it MUST be an
MC-LAG/DRNI ID, and (3) say that the type of LAALP ID value for any
other length will be specified in a future document.

> [mingui] I think, if RBx needs to just withdraw one LAALP ID, it will
> refresh the previous announced LSP by omitting that LAALP ID from the LAALP
> ID list in the PN-RBv APPsub-TLV.

The APPsub-TLV (which is inside a TRILL GENINFO IS-IS TLV) is link
state although it is not part of the base routing information LSP. It
is distributed in E-L1FS FS-LSPs (support for which is required by
draft-ietf-trill-rfc7180bis which is also in publication requested
state). So the contents of the APPsub-TLV can be changed or it can be
withdrawn by changing the FS-LSP fragment in which it occurs.

> Alia

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 11 Aug 2015 16:38:44 -0400

Hi,

I believe the mark ups in the attached resolve the AD comments on
draft-ietf-trill-pseudonode-nickname and also update some author info.
Could the authors please incorporate changes along these lines and
post a new draft or, alternatively, point out my errors and propose
different changes.

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

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 13 Aug 2015 01:55:32 +0000

Hi Donald,

Appreciate the review. The suggested changes are fine. Authors will incorporate them and send out the updated draft for your review. If it will be OK. The new version will be uploaded by tomorrow.

Thanks,
Mingui

> -----Original Message-----
> From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: Wednesday, August 12, 2015 4:39 AM
> To: [email-masked]
> Cc: Tissa Senevirathne; [email-masked]
> Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04
> 
> Hi,
> 
> Could the authors please incorporate changes along these lines and post a new
> draft or, alternatively, point out my errors and propose different changes.
> 
> Thanks,
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> 
> 
> >> To: [email-masked];
> >> [email-masked]; Don Eastlake
> >> 1) On p. 15 & 16: I'm a bit confused because on p. 15, it says "The
> >> basic idea of DF is to elect one RBridge per VLAN from an RBv to
> >> egress multi-destination TRILL Data traffic and replicate
> >> locally-received multi-destination native frames to the CEs served by
> >> the RBv."  but then on p. 16 in Step 4 part 1), it says: "RBv ports
> >> associated with the same pseudo-nickname as that of the incoming
> >> port, no matter whether RBi is the DF for the frame's VLAN on the
> >> outgoing ports except that the frame MUST NOT be replicated back to
> >> the incoming port".  This seems to be contradictory.
> >>
> >> [mingui] Let me explain the logic. If the RBridge in a RBv group
> >> receives a BUM packet from a locally connected CE.  Other CEs will
> >> receive the packet replicated by the DF only. Other RBridges will refrain from
> replicating.
> >>    Having said that, it is also important that the DF never
> >> replicates the BUM packet back to the incoming port (Say CE1 sends
> >> the BUM packet to the DF RB1 via port 1, then RB1 does not send the
> >> replicated BUM packet back to CE1 via port 1.)
> >>
> >> RB1 is the DF for the particularly VLAN, then wouldn't RB2 forward
> >> the packet to CE1 and CE2 while RB1 would also do so as the DF?
> >>
> >> 2) On p.23 in Sec 9.1: There is no way of identifying what the type
> >> of the LAALP ID is.  Assuming it is a number and meaning doesn't
> >> matter, it would be really good to clarify that.
> >>
> >> [mingui] Agree.
> >
> >> refresh the previous announced LSP by omitting that LAALP ID from the
> >> LAALP ID list in the PN-RBv APPsub-TLV.
> >
> >  155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Mon, 17 Aug 2015 11:58:16 -0400

Hi Mingui,

I need the updated version ASAP.  If I don't see it today, I will have to
put off reviewing the draft on the IESG telechat for another 2 weeks.

Donald's suggested text does clear up my concern about the inconsistency
around the non-DF behavior.

Thanks,
Alia

On Wed, Aug 12, 2015 at 9:55 PM, Mingui Zhang <[email-masked]>
wrote:

> Hi Donald,
>
> Appreciate the review. The suggested changes are fine. Authors will
> incorporate them and send out the updated draft for your review. If it will
> be OK. The new version will be uploaded by tomorrow.
>
> Thanks,
> Mingui
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 18 Aug 2015 03:08:08 +0000

Hi Alia,

Sorry for the delay.
I agree that Donald has cleared out the inconsistency. The updated version has been uploaded.

Thanks,
Mingui

From: Alia Atlas [mailto:[email-masked]]
Sent: Monday, August 17, 2015 11:58 PM
To: Mingui Zhang
Cc: Donald Eastlake; [email-masked]; Tissa Senevirathne; [email-masked]
Subject: Re: [trill] AD review of draft-ietf-trill-pseudonode-nickname-04

Hi Mingui,

I need the updated version ASAP.  If I don't see it today, I will have to put off reviewing the draft on the IESG telechat for another 2 weeks.

Donald's suggested text does clear up my concern about the inconsistency around the non-DF behavior.

Thanks,
Alia

On Wed, Aug 12, 2015 at 9:55 PM, Mingui Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Donald,

Thanks,
Mingui

> From: trill [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Donald Eastlake
> To: [email-masked]<mailto:[email-masked]>
> Cc: Tissa Senevirathne; [email-masked]<mailto:[email-masked]>
>  Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]<mailto:[email-masked]>
>
>
> On Wed, Aug 5, 2015 at 11:07 PM, Donald Eastlake <[email-masked]<mailto:[email-masked]>>
> wrote:
> > See below
> >
> > On Sun, Aug 2, 2015 at 11:45 PM, Mingui Zhang <[email-masked]<mailto:[email-masked]>>
> wrote:
> >> Hi Alia,
> >>
> >> From: trill [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> >> To: [email-masked]<mailto:[email-masked]>;
> >> [email-masked]<mailto:[email-masked]>; Don Eastlake
> >  155 Beaver Street, Milford, MA 01757 USA  [email-masked]<mailto:[email-masked]>
_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill