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 2CEA112953F; Mon, 13 Nov 2017 02:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, 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 76bb65lIbnNG; Mon, 13 Nov 2017 02:00:01 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 B6AA01294E7; Mon, 13 Nov 2017 02:00:01 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id d2so8414579ywb.11; Mon, 13 Nov 2017 02:00:01 -0800 (PST) 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=fW43iXhn+WWFUHq/qzhjS2HJRtCGTKldoAkEUC8vu0s=; b=pyVO5lMZuR+eXWIVCz8yt+iXVWhABd52jnqUcWKSOin4BmSJI6FyP+o1B9hsFZKrMo A6WvPplG1OGby6WD9CEMRp7s6OA7vv5DTn1scFC3k87wjl/cN+4ECJX4rUm519gTZ2og qjA6CxmRR1HEaSSB/gD23m+aFWMoq7yzOAyBktx+byc6fFR2j4vHInxTCwcZdihw8Rdn YYDmMIlpn8wnfStGLnJzHEJVOsxCJJ7JMW5luuBwSLKbm6v8MrOmgpJTtbujbcXtBQ3O Rls0YiBsiRbh9XBKldMCjPlVLgIacPAaMXs6tA+GcTkwP9LTTkKySQ4NvJZ6ERJYB5ip VRWg== 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=fW43iXhn+WWFUHq/qzhjS2HJRtCGTKldoAkEUC8vu0s=; b=CcwwrN26SxyjjV5GfkLgd+xudMaBewmWzV1M5D6NzDdnXu7aLzzsU5GNw71ZB9Jn+I MYCZAwvD64S+nUQGWDAobgDuXPYs2nUGJQiYutjtQpOreBhfxtr9G2vUu+Y9PassTDGf wIsUO/7ywqty+OYfWXtO5HbpHvE/ZwWK1tspEuyNZm+D/jV4P1Bab5q/L3NwKAsL+0SR 7HmymdAxydCi8wtgdpPYZ65DBQhLIUPWIjxFkj+zwPJJr0XW4Ns4+Pq90ZjCWN0k0wmI R6NmyKeydT3NnGSjQ2xhThEn3+laDJORle0EhKXMY6+qYODoRaquC6AZi21HB2Rdvgq+ YbSw== X-Gm-Message-State: AJaThX4YfB+dlFtlbo8uK6bXUslhFy7F5wCBrh+5HJVFZG6O+LXIVtGl 7N4Vwu11WK9Jzh3Wa5BkYF2My4kTI+z88xIEgac= X-Google-Smtp-Source: AGs4zMY0aEVnGmPss7eA1mHsalGZnFzdA++wH4bLfU72qu/wBSGUAZs06uQZAmCWC+qFv0YE0nOIBouLSVMbk+PjBpU= X-Received: by 10.13.212.5 with SMTP id w5mr5413851ywd.13.1510567201035; Mon, 13 Nov 2017 02:00:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.174.95 with HTTP; Mon, 13 Nov 2017 01:59:40 -0800 (PST) In-Reply-To: <5DD4B849-9894-4130-B458-4789C055BB35@kuehlewind.net> References: <150512983243.9691.9751851324237626342.idtracker@ietfa.amsl.com> <5DD4B849-9894-4130-B458-4789C055BB35@kuehlewind.net> From: Chris Bowers Date: Mon, 13 Nov 2017 17:59:40 +0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: Chris Bowers , "mpls@ietf.org" , "draft-ietf-mpls-ldp-mrt@ietf.org" , The IESG , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a114fb5026d6393055dda5588" Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-ldp-mrt-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:00:24 -0000 --001a114fb5026d6393055dda5588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) wrote: > Hi Chris, > > see below. > > > Am 07.11.2017 um 01:14 schrieb Chris Bowers : > > > > 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=C3=BChle= wind > > Sent: Monday, September 11, 2017 6:37 AM > > To: The IESG > > Cc: mpls@ietf.org; draft-ietf-mpls-ldp-mrt@ietf.org; > mpls-chairs@ietf.org > > Subject: [mpls] Mirja K=C3=BChlewind's No Objection on > draft-ietf-mpls-ldp-mrt-06: (with COMMENT) > > > > Mirja K=C3=BChlewind 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 th= e > reserved field of the multi-topology extension in RFC7307 to advertise MR= T > 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=3D0? > > > > [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=3D0. The > document currently has a reference to RFC 5661 "LDP Capabilities" for mo= re > 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: ther= e > 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 > --001a114fb5026d6393055dda5588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mirja,

With respect to the second comment, sin= ce 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 R= FC5661.=C2=A0

If it is OK with you, I will cl= ose out these two items without making changes to the current text.

Thanks,
Chris

On Thu, Nov 9, 2017 at 3:28 PM, Mi= rja 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.=C2=A0 Responses are inline with [CB].
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Mirja K=C3=BChlewind
> 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=C3=BChlewind's No Objection on draft-ietf-= mpls-ldp-mrt-06: (with COMMENT)
>
> Mirja K=C3=BChlewind 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 int= roductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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 t= he reserved field of the multi-topology extension in RFC7307 to advertise M= RT support, given that MT must always advertised as well...?
>
> [CB]=C2=A0 I don't really understand the suggestion.=C2=A0 The doc= ument is requesting three values from the MPLS Multi-Topology Identifiers R= egistry (defined in RFC 7307). I think that we need all three, MRT-Red, MRT= -Blue, and Rainbow MRT, for the protocol to work.=C2=A0 The registry has 64= k possible values (with 4k being most useful), of which only 6 are currentl= y used.

I was thinking just about the MRT Capability Advertisement (use a fl= ag instead of a new TLV Type, namely TBD-MRT-LDP-1). However this is not im= portant...

>
> Or are you referring to the request for a value from the Label Distrib= ution 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=3D0?
>
> [CB]=C2=A0 As an example, a configuration change on the node to no lon= ger participate in label distribution for MRT would generally result in a w= ithdrawal of the MRT capability, which is done by setting S=3D0.=C2=A0 The = document currently has a=C2=A0 reference to RFC 5661 "LDP Capabilities= " for more information on this.=C2=A0 Do you think more text is needed= in the document to clarify this?

Not necessarily. But it always helps to be rather explicit than impl= icit. It might be good to note that this is send based on things like confi= g changes and not based on state changes that are happening during usual op= eration. 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: the= re 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]=C2=A0 Thanks.=C2=A0 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

--001a114fb5026d6393055dda5588--