Re: [mpls] [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.

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 <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
>