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

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 10:45:54 +0100

/* 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.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 30 Nov 2017 02:20:11 -0800

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 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, November 30, 2017 at 01:46
To: idr wg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Nov 2017 15:13:28 +0100

Jeff,

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

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

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.

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.

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 :).

On Thu, Nov 30, 2017 at 11:20 AM, Jeff Tantsura <[email-masked]>
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…
>
> *From: *Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Thursday, November 30, 2017 at 01:46
> *To: *idr wg <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[Idr] draft-ietf-idr-eag-distribution-05.txt
>
>
>
> 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
>
>
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 30 Nov 2017 06:54:40 -0800

Robert,

Thanks for your comments, please see inline

Cheers,

Jeff

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, November 30, 2017 at 06:13
To: Jeff Tantsura <[email-masked]>
Cc: idr wg <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]> wrote:

Robert,

Hope this clarifies.

Thanks,

Jeff

Hi,

Observations:

Cheers,

Robert.