Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-ldp-mrt-06: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 14 November 2017 08:44 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE312008A for <mpls@ietfa.amsl.com>; Tue, 14 Nov 2017 00:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 VzBLQjk1Soun for <mpls@ietfa.amsl.com>; Tue, 14 Nov 2017 00:44:03 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFF7126DCA for <mpls@ietf.org>; Tue, 14 Nov 2017 00:44:02 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=mrroyZZDWDYO9M3+kA8S0bUuBaZHKuPC7/Q3LI2GiluAVE5ic4XYc2VVA59ombwqKmZ/hkiTg9s8dbJD4wjYC39gZfI0KaCkDxxMG5l8XvRvLO9k3xXtxG1jzOcD+mdCn/yhPF+taa4aH9NUx0YoXSqs5mUtFRJpTS45P1MPWpA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 32748 invoked from network); 14 Nov 2017 09:44:01 +0100
Received: from dhcp-80f9.meeting.ietf.org (31.133.128.249) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Nov 2017 09:44:00 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CAHzoHbtNJ7HoQBvLqX3qt6YZXh+g=7_PfygxO504KpZ86uxddQ@mail.gmail.com>
Date: Tue, 14 Nov 2017 16:43:55 +0800
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-ldp-mrt@ietf.org" <draft-ietf-mpls-ldp-mrt@ietf.org>, The IESG <iesg@ietf.org>, Chris Bowers <cbowers@juniper.net>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1487156D-983D-4C06-96C5-80D24C426893@kuehlewind.net>
References: <150512983243.9691.9751851324237626342.idtracker@ietfa.amsl.com> <CY4PR05MB2823FF5CC38A3FD5C3DC6F3CA9500@CY4PR05MB2823.namprd05.prod.outlook.com> <5DD4B849-9894-4130-B458-4789C055BB35@kuehlewind.net> <CAHzoHbtNJ7HoQBvLqX3qt6YZXh+g=7_PfygxO504KpZ86uxddQ@mail.gmail.com>
To: Chris Bowers <chrisbowers.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171114084401.32739.90440@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/9PO9xBxGL128sKLy42qocr-mSVM>
Subject: Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-ldp-mrt-06: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 08:44:06 -0000

That was just a comment. Just do the right thing…

> Am 13.11.2017 um 17:59 schrieb Chris Bowers <chrisbowers.ietf@gmail.com>:
> 
> Mirja,
> 
> With respect to the second comment, since the behavior is defined in RFC5661, in this case I think it is better to not be more explicit in this document because it might confuse matters and be interpreted as specifying behavior that is in some way different from RFC5661.  
> 
> If it is OK with you, I will close out these two items without making changes to the current text.
> 
> Thanks,
> Chris
> 
> On Thu, Nov 9, 2017 at 3:28 PM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> Hi Chris,
> 
> see below.
> 
> > Am 07.11.2017 um 01:14 schrieb Chris Bowers <cbowers@juniper.net>:
> >
> > Mirja,
> >
> > Thanks for the feedback.  Responses are inline with [CB].
> >
> > Thanks,
> > Chris
> >
> > -----Original Message-----
> > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mirja Kühlewind
> > Sent: Monday, September 11, 2017 6:37 AM
> > To: The IESG <iesg@ietf.org>
> > Cc: mpls@ietf.org; draft-ietf-mpls-ldp-mrt@ietf.org; mpls-chairs@ietf.org
> > Subject: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-ldp-mrt-06: (with COMMENT)
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-mpls-ldp-mrt-06: No Objection
> >
> > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 1) I was just wondering if it was considered to just use one flag of the reserved field of the multi-topology extension in RFC7307 to advertise MRT support, given that MT must always advertised as well...?
> >
> > [CB]  I don't really understand the suggestion.  The document is requesting three values from the MPLS Multi-Topology Identifiers Registry (defined in RFC 7307). I think that we need all three, MRT-Red, MRT-Blue, and Rainbow MRT, for the protocol to work.  The registry has 64k possible values (with 4k being most useful), of which only 6 are currently used.
> 
> I was thinking just about the MRT Capability Advertisement (use a flag instead of a new TLV Type, namely TBD-MRT-LDP-1). However this is not important...
> 
> >
> > Or are you referring to the request for a value from the Label Distribution Protocol (LDP) Parameters registry "TLV Type Name Space"?
> >
> > 2) Why would a node withdraw the MRT capability/ when would it send a MRT advertisement with S=0?
> >
> > [CB]  As an example, a configuration change on the node to no longer participate in label distribution for MRT would generally result in a withdrawal of the MRT capability, which is done by setting S=0.  The document currently has a  reference to RFC 5661 "LDP Capabilities" for more information on this.  Do you think more text is needed in the document to clarify this?
> 
> Not necessarily. But it always helps to be rather explicit than implicit. It might be good to note that this is send based on things like config changes and not based on state changes that are happening during usual operation. However, maybe this is more obvious to people who are more expert than I am.
> 
> Mirja
> 
> >
> > 3) If you update the document, please also see the gen-art review: there are many small nits which will probably also be caught by the RFC editor but if you can fix them now, that's even better!
> >
> > [CB]  Thanks.  I did that in a separate response.
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>