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 12:05 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 A3FBD1204DA; Thu, 17 Aug 2017 05:05:07 -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=gH/b7xA9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XMePsKeU
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 iEYzeZAja9YV; Thu, 17 Aug 2017 05:05:05 -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 CD5B21323A8; Thu, 17 Aug 2017 05:05:04 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4700020CB6; Thu, 17 Aug 2017 08:05:04 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 17 Aug 2017 08:05:04 -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=GgkPDjvdQEgUqkBxltfvI8qt012lw Ccty38TbuCq0Qs=; b=gH/b7xA9WKu17J6AzWQ8yJC1/g1AU42XoABzxkSHxFPUH tfibNnox70raUHMYYdnabXOOEGgRoQVJT1r3ctAw+DPrbtm1WoGf9pm9CkysGN9K 6q2vjG9XktVsWi6TjSZnaKyqUTM9RxCDBla+t0mSVuwqDwQJsHGkcRjJ2z9F9xtm mh+BKg3mUMg7yZKDG+7BBLagBV1hR1uzY+c33zePBKP56ErUlRx83t+BoFlGgSGp OFQQWTwkYtf5qFIoOaC42VKb5Gfb27AmDgcJH51VEYjf7jIR5Nw9uBI9GYFxoy2i k5/Cfx0awx0uF6bEb8bcfD/nzmqqMWuw/qPzRGJBQ==
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=GgkPDj vdQEgUqkBxltfvI8qt012lwCcty38TbuCq0Qs=; b=XMePsKeUujzCJUMJuaIY72 CrYtT0W6J/mmR5k06YM4CgRYjym1hoinVhyuHqgFOejACFAarFUeJGXmpGyU93Ot VPBVWL0yCvQkCwOqQzPcFYkdo6gG0zVh4dlkGqjZzApPh5lWoFHtqnqjsVbuY7Aj 44PQADQOSpDsTzGkOkzdIYWULYSPhKvc7dVoMmxrmqQUDGqoWiCtPAwhHprBRwIW I7ARQpa2ctvudJjK0Pg8C6DhgmkaHN9fmX4jrDi1Q+9u9dxP4p1k6f8P5B7LYBSN ybCYdOQ146kanmfoCKahqqi25py1SCFWno3l1dHyKzf0DiCtP1A1KLU6dylIltZA ==
X-ME-Sender: <xms:cIaVWdOSYruxxW4y8vfLgJzGDZ0X1u68bAJ1uCQITsweyxB07BX2FA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1F6589E308; Thu, 17 Aug 2017 08:05:04 -0400 (EDT)
Message-Id: <1502971504.22339.1076341056.244618C2@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
Date: Thu, 17 Aug 2017 13:05:04 +0100
References: <150160092345.9575.15101330200808959616.idtracker@ietfa.amsl.com> <0dafc151-777c-ce0c-dd40-192e88bdc915@juniper.net>
In-Reply-To: <0dafc151-777c-ce0c-dd40-192e88bdc915@juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/64m6R0zIP9O4Oms0UJ5IxmXH4ko>
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 12:05:08 -0000

Hi Eric,
Sorry for the slow response.

On Tue, Aug 1, 2017, at 09:59 PM, Eric C Rosen wrote:
> 
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I would like to discuss one issue before recommending approval of this document:
> >
> > In Section 2.1:
> >
> >     The value field of the Multiple Labels Capability (shown in Figure 1)
> >     consists of one or more triples, where each triple consists of four
> >     octets.  The first two octets of a triple specify an AFI value, the
> >     third octet specifies a SAFI value, and the fourth specifies a Count.
> >     If one of the triples is <AFI,SAFI,Count>, the Count is the maximum
> >     number of labels that the BGP speaker sending the Capability can
> >     process in a received UPDATE of the specified AFI/SAFI.
> >
> > I think lack of recommendations on the minimal supported Count value will
> > result in lack of interoperability. What are the common Count values used by
> > implementations?
> 
> An implementation is not required to support more than one label in the 
> NLRI.  In that case, of course the Multiple Labels Capability is not  
> supposed to be used.  So if the Capability is used, the minimum value is 
> 2.   It looks like the document does not state that explicitly, but it 
> certainly should.  I will fix that.
> 
> Thus the literal answer to your question is that the Multiple Labels 
> Capability MUST NOT contain a count less than 2.
> 
> Typically when SAFI-4 or SAFI-128 routes are used, only one label is 
> included.  If an operator has a scenario in which multiple labels are 
> needed, it is necessary for the operator to ensure that all his vendors 
> can support however many labels he needs.  That's not really something 
> that the standard can address. 

The standard can specify minimum requirement (and this has been done in
the past). For example you can say that all implementations must support
4 (or whatever).

> If the operator needs 3 labels in the 
> NLRI, it won't help much if some of his boxes can only support 2.

Exactly my point. Without the minimum you still need to have out-of-band
selection of implementations that support your minimum requirements.

> ---------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > In Section 2.3:
> >
> >        0                   1                   2                     3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+
> >       |    Length     |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                 Label                 |Rsrv |S~
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       ~                 Label                 |Rsrv |S|
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                          Prefix                               ~
> >       ~                                                               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                      Figure 3: NLRI With Multiple Labels
> >
> >     - Length:
> >
> >        The Length field consists of a single octet.  It specifies the
> >        length in bits of the remainder of the NLRI field.
> >
> > I would like to double check that my math is correct. With SAFI=128 and AFI=2,
> > assuming the prefix length of 192 bits, this will leave space for:
> >
> >   (255-192)/24 = 2.625. So this configuration only allows for 2 labels to be included, right?
> >
> Your arithmetic is accurate ;-)
> 
> If you are implying that this is not necessarily the best mechanism for 
> associating an arbitrarily long label stack with a prefix, I wouldn't 
> disagree.

Yes, I was just surprised that this has such a small limit. I wanted to
make sure that this is by design.

Best Regards,
Alexey