Return-Path: 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 CD285131070; Sun, 8 Jul 2018 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ov13AjFJ-U_L; Sun, 8 Jul 2018 09:21:16 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7F41277D2; Sun, 8 Jul 2018 09:21:16 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k81-v6so31708988oib.4; Sun, 08 Jul 2018 09:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dsmAn/aA6SlGx4q2VE0uFMb8LCFz5HTyx4S3c9QpEEc=; b=u2XP2SlONQl0hEwKgxO18OBv2zdPs0JMo3IhQ6Oqc8ImBqhoAg0m3pWP72gVgSr+X/ 88EUg5XqtJPtfdRhv8S5zhXpKTdoO2ONy+1v4KKCAdp+LtjHvmj7LVJk+WIoD8jutXoa 5kkU7Ict5MWmOfE6OcuOnHodM2rav07Gw/n9/+45TYMylwdkWfzwowhbppC1vtdwfB0H uw34IbdxJEAqaEQ5S1N6IHv3fj8GrB/AlMFCVEQWh5v5f9c53aF2uJY/tM2pqCy5ZLwG 6coYA7pM0HS/2X2TD6EgjxPodHw0hfAzAq61xz1z5DGZy+0UIeuYN2ClPu5gzq2TkWhL h1Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dsmAn/aA6SlGx4q2VE0uFMb8LCFz5HTyx4S3c9QpEEc=; b=Txoth6xXaR+Y+QH2ktfUAlkWi0w2a3B8iIBUvIc+7+u3lCS7dUwxzK3qhFXSc1D72E iFiXSIvNonPhAWY/Mh4vFjAvgaSUK+Ahske8/W3bf+fW7eBYwZwowG5EkaPjxFPbFcJ4 Jmn5nNSfBz5cWfCQqMChFocaa61xJVf0Ua6zS0Mjb40ql/WdnpwNEiej0ZovIwCAZtkT NPxxIbn3yvmZlMH7UVLRiKFLuK5Ob05qDA7OXIwCkcyqPs9s7szZWKyOMWg6f8if/wU3 1LX1ACFsrdRFMssFHI7pkGzs1jGNQ1YubcUWkeOW0hpupXt7qjzAM6m9CJ9OGzROhWWq j+Nw== X-Gm-Message-State: APt69E3kVhIQh0neoKXFuXqKQ1JnwRCw9nsr69spMgUxZ9lwG4LB742z sno2/t50BPFc2qXACr7uUI5V35k0JIdHu0c+hUpBHA== X-Google-Smtp-Source: AAOMgpdEZGLlYb73kSFAAiL8vdWOIjOuSQQMnJqV0WvQ0o3iwqNEz+Rw200Jr1nkvAUFESuvFVjN55SVlg8SemJRYjc= X-Received: by 2002:aca:d48c:: with SMTP id l134-v6mr21276863oig.15.1531066875220; Sun, 08 Jul 2018 09:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 09:20:54 -0700 (PDT) In-Reply-To: <0ae330e4-8aa6-7a02-4528-7014417ab3b6@pi.nu> References: <0ae330e4-8aa6-7a02-4528-7014417ab3b6@pi.nu> From: "Andrew G. Malis" Date: Sun, 8 Jul 2018 12:20:54 -0400 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-esale-mpls-ldp-rmr-extensions@ietf.org" Content-Type: multipart/alternative; boundary="00000000000039963405707f4961" Archived-At: Subject: Re: [mpls] working group adoption poll on draft-esale-mpls-ldp-rmr-extensions X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 16:21:19 -0000 --00000000000039963405707f4961 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Loa, I=E2=80=99m repeating the comments in my MPLS-RT review of this draft, sinc= e they were never responded to. This draft documents the extensions required to LDP in order to signal resilient MPLS ring LSPs, based on the architecture for RMRs described in draft-ietf-mpls-rmr-02. In general, I found the described extensions to LDP, and their operation, clearly written to the extent that they can easily be the basis for WG input and review. The authors have taken the draft to the point where wider WG review that would result from adoption is necessary. Thus, my opinion is that the draft is ready for WG adoption. I have one nit that can be resolved either before or after adoption. In section 4.2.2, the section begins: A node X wishing to participate in LDP RMR signaling SHOULD negotiate the RMR capability with all its neighbors. I would think that should be a MUST rather than a SHOULD. Cheers, Andy On Sun, Jul 8, 2018 at 9:40 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-esale-mpls-ldp-rmr-extensions-02 > as a MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There is one IPR disclosure against this document. > > The authors have stated on the MPLS wg mailing list that they are > unaware of any other IPRs thanwhat has been disclosed to the IETF. > > The working group adoption poll ends July 27, 2018. > > /Loa > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --00000000000039963405707f4961 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Loa,

I=E2=80=99m repeating the comments= in my MPLS-RT review of this draft, since they were never responded to.

This= =C2=A0draft=C2=A0documents the=C2=A0extensions=C2=A0required to=C2=A0LDP=C2=A0in order to signal resilient=C2=A0MPLS=C2=A0ring LSPs, based on the architecture for RMRs desc= ribed in=C2=A0draft-ietf-mpls-rmr-02.

In general, I found the described=C2=A0extensions=C2=A0to=C2=A0LDP, a= nd their operation, clearly written to the extent that they can easily be t= he basis for WG input and review. The authors have taken the=C2=A0draft=C2=A0to the point where wider WG review that w= ould result from adoption is necessary.

Thus, my opinion is that the=C2=A0draft=C2= =A0is ready for WG adoption.

I have one nit= that can be resolved either before or after adoption. In section 4.2.2, th= e section begins:

   A node X wishing to participate in L=
DP RMR signaling SHOULD negotiate
   the RMR capability with all its neighbor=
s.

I would think that should be a MU= ST rather than a SHOULD.

Cheers,
Andy


On Sun, Jul 8, = 2018 at 9:40 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-esale-mpls-ldp-rmr-extensions-02
as a MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There is one IPR disclosure against this document.

The authors have stated on the MPLS wg mailing list that they are
unaware of any other IPRs thanwhat has been disclosed to the IETF.

The working group adoption poll ends July 27, 2018.<= font color=3D"#888888">

/Loa
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pho= ne: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--00000000000039963405707f4961--