RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 10 April 2014 16:02 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1181A02E0; Thu, 10 Apr 2014 09:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level:
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PskJGs18CGEJ; Thu, 10 Apr 2014 09:02:49 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9757C1A02D1; Thu, 10 Apr 2014 09:02:49 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AG2YHu000964; Thu, 10 Apr 2014 17:02:34 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AG2XOx000958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 17:02:33 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Fedyk, Don'" <don.fedyk@hp.com>, "'Ben Niven-Jenkins'" <ben@niven-jenkins.co.uk>, <rtg-ads@tools.ietf.org>
References: <A1D43D7D-3E37-498C-8B5D-617A318DD6E7@niven-jenkins.co.uk> <D17B8554-22A1-46B7-A8EC-67A35CF14584@niven-jenkins.co.uk> <A46D9C092EA46F489F135060986AD9FFD0A81A@G6W2492.americas.hpqcorp.net>
In-Reply-To: <A46D9C092EA46F489F135060986AD9FFD0A81A@G6W2492.americas.hpqcorp.net>
Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
Date: Thu, 10 Apr 2014 17:02:33 +0100
Message-ID: <031e01cf54d6$496516d0$dc2f4470$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH+AHmJeatBe0KR/K3XXWNXppdEMAGodTO8AiQoiKaaj0RkUA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.000
X-TM-AS-Result: No--6.690-10.0-31-10
X-imss-scan-details: No--6.690-10.0-31-10
X-TMASE-MatchedRID: 6otD/cJAac0tqx4vLVZ3FppWgCLYjjT9NACnndLvXweCsBeCv8CM/RZ0 n9DHfDteqthi32DRSIKtmu58TYSSJekOZa3OWbiWTQh9A4m9EtHh04vhNT6Pi6MVwpOQMj2MowO jF+MaCNgHyVe0cM3K0c2O30xxOFFQGjqKL+SYU9X5WZT2GFh+nbYxxljjfMnjd71AOvz4tNyaD4 6neqGHJAY+dsqE8cvNJ+6k856T1ST9k2nJXxNdGn6DQ2TEDqZs1kqyrcMalqUXzqHaBURjrBjbR /XCsHXWDiTX4NL90becUEZb1VcLPl2zdiRYF6EuHcQQBuf4ZFueimGtNywjtpsoi2XrUn/JyeMt MD9QOgDGlDvsLUDW2o6HM5rqDwqtsRCKU4TxQuAiV7UYA8luTzSZX4BvfCMKsWxOSccJX9wG4fU CBdx/dA==
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/hqNkBi6VG1Uy2Lz0HAQmNYyq4eg
Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 16:02:51 -0000

Hi Don,

[snip]

> > a) Some clear text/statement of when the new optimised MAC flush
> mechanism should be used instead of the existing RFC4627 mechanism (e.g.
> when is a full RFC4627 MAC flush "bad").
> [Don] OK I'll ask Adrian if he would like this highlighted.

I think that would be valuable to include (and am embarrassed to have not picked
up on it myself). Essentially, you are introducing an option: new flush
mechanism or old flush mechanism. You should help implementers decide which to
use. Might be as simple as "always" or might be some other issues.

[snip]

> > 1) The first paragraph of section 3 states:
> >
> >   When the MTU-s switches over to the backup PW, the requirement is to
> >   flush the MAC addresses learned in the corresponding Virtual Switch
> >   Instance (VSI) in peer PE devices participating in the full mesh, to
> >   avoid black holing of frames to those addresses.  This is
> >   accomplished by sending an LDP Address Withdraw Message from the PE
> >   that is no longer connected to the MTU-s with the primary PW, with
> >   the list of MAC addresses to be removed to all other PEs over the
> >   corresponding LDP sessions [RFC4762].
> >
> > Comparing this against Figure 1, my understanding is that the "PE that is no
> longer connected to the MTU-s with the primary PW" is PE1-rs. However section
> 3.1.1 states:
> >
> >   [RFC4762] specifies that on failure of the primary PW, it is the
> >   PE3-rs (Figure 1) that initiates MAC flush towards the core.
> >
> > Which contradicts the first paragraph of section 3?
> [Don] I see your point here, is what is being described.
> 1) PE-rs dual homing Aware
> - Control of dual homing by the PE-RS <- This is 3.1.1
> - Control of dual homing by the MTUs <-This is 3.
> 2) PE-Rs dual homing unaware.
> 
> [Don] It is up to you Ads & WG chairs to say if this should be highlighted,  I
think it
> covers the cases and I can try make it clearer as above if that helps.

My general rule of thumb is that if a reasonably smart reader has questions
arising from the text, clarifying the text is worthwhile. Maybe that some
pointers as highlighted would cover the case.

[snip]

Thanks,
Adrian