Re: [mpls] Alexey Melnikov's Discuss on draft-ietf-mpls-rfc3107bis-02: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 17 August 2017 13:55 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 A300513242C; Thu, 17 Aug 2017 06:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Gecyz5C6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nLnq0tC5
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 SqPY2OBVWOwA; Thu, 17 Aug 2017 06:55:40 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB2F132063; Thu, 17 Aug 2017 06:55:39 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6A2E520C8D; Thu, 17 Aug 2017 09:55:39 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 09:55:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mrSxUGSu9H0IKuDx3XIfrfZbrbBzb PuLUNU8UAdGjM4=; b=Gecyz5C6ZmJF6Hmr4sv78kPgJozfLosSfc7z9wJpw/5wr pCUuLoUlnIfSOBIOKcEHyUhF3riEkTYQhImDlOlpAGm+d+LlzVnSEgQMuj3aTmiA 1/xNIu2mhQQdLkjEAPzvXZP8+fbC2wLwvesQnDsuk4sh1vxDUVkEsDdxGkbqQfUr 8jWSR45+fUVbRTvmbijKndEcv566fofaBS14Ed9T6bvnBp8IookHTeb3umRE8cUq Q0iiqPKzefo8DiL2vXRE+DSOCIo5A7Hy9JXV3lOOxViI5ZYrG3z9t8uxvmj822Zd roEqR6uMoANV5qvPPlwaBHfRZrtAYSt7O75eQ5dgg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mrSxUG Su9H0IKuDx3XIfrfZbrbBzbPuLUNU8UAdGjM4=; b=nLnq0tC5LCUEmLeNnvL0w/ JypDAOf/OAJXvKJ9DHCymJEQAXdt7tFXnojzfafv/pPF58CO7/FeFheOSRllwvSb nKceEGckYHFLtTo01/ZcjbO9I0to/mFmZ50viJfgS2QIpuKtLSMS8eqI8zvjwHWW 9amwhp2Qe++CXRmFdOMq67qBoJkI//zhbA/JCvP8WxLKt1Ydjv3WApHCegkLeZ0b WFoG27l+C/AKxs5G4SNLJoQ2gzNgJqZ5c8bQac78VlrQCiGoBwZbhOcVLr0zgPKi 1D7OArqDqKR12v6amYbTIz8wUHT6dek6SDXY2O9eLzsHERNafSsxCzQrrWQzSiVQ ==
X-ME-Sender: <xms:W6CVWYcqsnOmVzL-yLU_i6FwDvjT1oy2Wz19uzer4HQviqMi7OD7Tw>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3B9AF9E308; Thu, 17 Aug 2017 09:55:39 -0400 (EDT)
Message-Id: <1502978139.44713.1076448424.7F87482D@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Eric C Rosen <erosen@juniper.net>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-rfc3107bis@ietf.org, Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, mpls@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044
References: <150160092345.9575.15101330200808959616.idtracker@ietfa.amsl.com> <0dafc151-777c-ce0c-dd40-192e88bdc915@juniper.net> <1502971504.22339.1076341056.244618C2@webmail.messagingengine.com> <660636ae-4821-7ae4-32f5-c54b309e2704@juniper.net>
In-Reply-To: <660636ae-4821-7ae4-32f5-c54b309e2704@juniper.net>
Date: Thu, 17 Aug 2017 14:55:39 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/N1p4DROZMNRVNCWuywi-SRhQVk4>
Subject: Re: [mpls] Alexey Melnikov's Discuss on draft-ietf-mpls-rfc3107bis-02: (with DISCUSS and 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: Thu, 17 Aug 2017 13:55:41 -0000

Hi Eric,

On Thu, Aug 17, 2017, at 02:51 PM, Eric C Rosen wrote:
> H Alexey,
> 
> In BGP, anything that is announced by a Capability is always optional.  
> Per the draft, if one doesn't send the Multiple Labels Capability, one 
> sends exactly one label in the NLRI.   So in that sense, the mandatory 
> minimum value is 1.  I thought this part was clear from the first bullet 
> point in Section 2.

Yes, this part was clear.

> When the Multiple Labels Capability is sent at session establishment 
> time, I thought the new text:
> 
> "A triple of the form <AFI=x,SAFI=y,Count=0> or <AFI=x,SAFI=y,Count=1>
>   MUST NOT be sent.  If such a triple is received, it MUST be ignored."
> 
> implied that the mandatory minimum value is 2, as that text precludes 
> the use of the only smaller values.

I got that. I thought 2 was a rather low limit, but you made a good
explanation in this email, so I am Ok with that. So I will clear my
DISCUSS.

> If you think this isn't clear enough, I can some text like "Any 
> implementation that sends a Multiple Labels Capability MUST be able to 
> support at least two labels in the NLRI.  However, there may be 
> deployment scenarios in which a larger number of labels is needed."
> 
> Would that be okay?

Probably not needed, but I am Ok if the above is added.

> I wouldn't want to make the mandatory minimum any larger, because (a) 
> some deployment scenarios might only require two labels, and (b) we 
> don't want to have a larger mandatory minimum because the number of 
> labels is not merely a control plane issue, but also affects the data 
> plane.  E.g., if some platform can only push two labels at a time, 
> there's no value to requiring it to support three labels in the control 
> plane.
> 
> Eric
> 
> 
> 
> 
> 
> 
>