Re: [mpls] [Idr] draft-ietf-idr-eag-distribution-05.txt

Jeff Tantsura <> Thu, 30 November 2017 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D453C1293FF; Thu, 30 Nov 2017 02:20:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id im_2J3mSju1H; Thu, 30 Nov 2017 02:20:05 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EDC01293FD; Thu, 30 Nov 2017 02:20:05 -0800 (PST)
Received: by with SMTP id n138so1024081wmg.2; Thu, 30 Nov 2017 02:20:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=V70tCLZ8s38WgkXWV0udvIOuMv0xho0DGQYu5icIjvY=; b=NEjrxZ43zOMy9EsMSIK5gQH+sRxkFciyuUfmF5kI9LYK9Rml1Wr7doMhcs1dkX6Ncd mVkI4F3Lqh7R59HxSTWGCiDr0YIJlq7h6MBFxCpwHysb5Z/2IvywUfztx/QfgUp33p0f XzL2/pF1p69VzhVNMP9Ilz6FyVzXcdsGjUZa+t3Rw7n7HFNczTBs5o1gnVBeHDAd7TO9 h0qytxXUDpTxqent2sUrJhDsromf3hI+1xYIuzXF6iKz+RfX3oe3OYqaOSfw5qxYhxoP +6qgfLp+UDmpvmq/yb6xZcK6a0sd3GrcP++wnJmRnR04UIUZq7aa7FmNxWL15fMvET+Z nLYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=V70tCLZ8s38WgkXWV0udvIOuMv0xho0DGQYu5icIjvY=; b=Dcq3iOHkyO685O9ejpYs7hAc6z3QuVBM4CJbYygijEhg7LwfdFdF+U2ena3X1IJ+tJ M4T9Vvy/HBJo4Q/zK5NgSBmQpVs8azFK5+An6MZKXO6KFe85bWnaOZBbmiLPv+E6iU1o 2mXoktVVQwdGg7iBvLhgGn6NGtCmOBbXg3dgyDwdczNehIxz7M25FKAtoDrF6pdYObly Ztn5xje0pfz6guNWsLYxur2d4E1woYtrjMBX0dm5A/N70mApS/HN6723/dGf9DZ3EgGT zrh6Tj9b+rMOUlCf5TssRZ+hYA1b/+ZaVCOFbKgkqc+HrPkc4QEfTTdrZzfwcBSHplIV 7HXg==
X-Gm-Message-State: AJaThX7B54r3IhdJ2OO03ch+f4nOIOp6TfCjajurm6eoaQyymd1smXZz emx1EgnvvcU0L9O52vPNVYo=
X-Google-Smtp-Source: AGs4zMbCaEz8aiTcIROWlhRxRGMY7wx+9vU9mc1Ol8+5EpZpv2DlGM/Ly0Dsg+MN60vkvI3IAuhBYg==
X-Received: by with SMTP id w204mr123768wme.126.1512037203868; Thu, 30 Nov 2017 02:20:03 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id l25sm4159837wmi.35.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 02:20:03 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.28.0.171108
Date: Thu, 30 Nov 2017 02:20:11 -0800
From: Jeff Tantsura <>
To: Robert Raszuk <>, idr wg <>
CC: "" <>
Message-ID: <>
Thread-Topic: [Idr] draft-ietf-idr-eag-distribution-05.txt
References: <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3594853212_1744931488"
Archived-At: <>
Subject: Re: [mpls] [Idr] draft-ietf-idr-eag-distribution-05.txt
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: Thu, 30 Nov 2017 10:20:08 -0000



The draft provides BGP-LS facility for RFC7308 that extends RFCs 3630 and 5305 (AG->EAG), aka link coloring, nothing to do with BW reservations or packet prioritization.

RFC7308 was necessary to provide interoperable solution, if I recall correctly, around 2013, in order to signal EAGs - Junos was using TLV138 while XR Sub-TLV 252. Your comment about modifications needed is about 5 years late…

There was a need for more than 32, that came in a form of feature requests ☺

You might not believe it – but there are still networks running RSVP-TE at a rather large scale.


I agree – a wider look is necessary, but BGP-LS might not be the first place to start.


Hope this clarifies.




From: Idr <> on behalf of Robert Raszuk <>
Date: Thursday, November 30, 2017 at 01:46
To: idr wg <>
Cc: "" <>
Subject: [Idr] draft-ietf-idr-eag-distribution-05.txt


/* While the draft is in IDR I am adding MPLS WG here as the discussion is really about MPLS-TE and not BGP */




I looked at draft-ietf-idr-eag-distribution-05.txt and would like to share few comments on it. 


The draft defines extension to BGP-LS in order for the node to signal extended admin groups of a links in the TE domain relaxing the current limit of 32 bits. 




1. Is the draft only applicable to MPLS-TE or also to SR networks ? If the latter the title needs to be changed. 


2. While it is usually considered good to have more then less of anything let's look at the bigger picture and the consequences of this proposal in respect to its current applicability of MPLS-TE: 


Signalling of 32 affinity bits of the link is just a tiny piece of the full picture. In MPLS-TE networks those bits are signaled in SESSION_ATTRIBUTE of RSVP-PATH msg as defined in RFC3209 section 4.7


Signalling more then 32 bits will just not fit the current space hence fundamental set of RSVP-TE (aka MPLS-TE) operation are broken. 


Likewise most of the CSPF implementations would also need to modified to accomodate for BGP signalled extened affinity bits. 


IMO if there is real need to have more then 32 admin groups per link in a TE domain the right process would be to extend IGP as well as RSVP-TE RFCs for it. 


Moreover as we know RSVP-TE or SR-TE while can steer packets via constrained paths do not guarantee any interface level reservations or packet prioritization. Those are control plane driven features. 


As such one could also notice that with the extened set of link affinity classes there is real need to also extend QoS of each network element to offer more then 32 diffserv classes. Otherwise in the event of congestion it is likely that packets assumed to be classified into one admin group will likely compete for bandwith in the same queue with packets classified into different group.


So while I do not have concerns to define such TLV in BGP-LS I do have bigger picture observations which I believe need to be addressed and need to become formal references in this document before we proceed on it in IDR any further.





_______________________________________________ Idr mailing list