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

Robert,

Thanks for your comments, please see inline

Cheers,

Jeff

From: <rraszuk@gmail.com> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Thursday, November 30, 2017 at 06:13
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: idr wg <idr@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-eag-distribution-05.txt

Jeff,

Both RFC3630 & RFC5305 define 4 octet administrative groups. I just checked and non of them is updated formally by RFC7308. 

[jeff] it doesn’t, it extends

My comment applies equally to RFC7308 and to your draft. It is really not my fault that RFC7308 went through as is. 

[jeff] there should be 6-7 implementations of 7308 in the shipping products.

Defining only extension for longer then 4 octets admin groups for interfaces in an MPLS-TE domain is presenting myopic view on how those extensions are to be used in practice within SESSION_ATTRIBUTE object. 

[jeff] you are mixing state distribution with LSP setup… color(bitmask) is a property of a link and on itself has nothing to do with RSVP-TE. The name of 7308 reflects realities of the time it was written, however.. it is not limited to.

If you say that your extension are to be used only by controller I rest my case. But as written today they can not just work in practice with base RSVP-TE specification. 

[jeff] AG/EAG provide additional meta-data about the link in a graph and could be used by any consumer of that data, being PCE/SDNc/any_cool_acronym_of_the_day 

Best,

R.

PS. The comments about lack of bw reservation and qos was not related to yr draft. It was to provide bigger picture of the problem at hand. But you are welcome to disregard it :). 

[jeff] I really appreciate your comments and don’t mean to disregard them, resolution of color semantics could be done in any way to express business logic

On Thu, Nov 30, 2017 at 11:20 AM, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

Robert,

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.

Thanks,

Jeff

From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Thursday, November 30, 2017 at 01:46
To: idr wg <idr@ietf.org>
Cc: "mpls@ietf.org" <mpls@ietf.org>
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 */

Hi,

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. 

Observations:

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.

Cheers,

Robert.

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