[Idr] draft-li-idr-congestion-status-extended-community

[<[e-mail]>]

Hi authors,

Please find below some minor comments. 

§2  Congestion Status Extended Community

> The "Utilization" field is 1 octet.  Its value is the utilization of the exit link in unit of percent

- Is this the utilization on the link or before the link (i.e. before dropping the traffic in excess) ? IOW, can this be greater than 100%? I think I'd prefer the latter, but in all cases, I like to see a text detailing the handling of numbers > 100%. 
- In order to offer more granularity, sometimes the traffic is rate limited to a capacity smaller than the physical link. e.g. the physical link has 10G of traffic, but only 3G is available to the user. Please explicit whether you are referring to physical or "real"/"offered"/"available" capacity. On my side, I'd prefer the latter.

> The "Bandwidth" field is 1 octet.  Its value is the bandwidth of the exit link in unit of 10 gbps (gigabits per second).

I don't see that this is extremely future proof, as the usable range is 1-255. When this proposition gets used (in years from now), 100G links would presumably be the default. Meaning we would already have consumed *10 from the budget. Only leaving *25 for the future. I'd prefer a wider range with less precision. e.g. bandwidth is 10^^bandwidth in gbps. (or 2^^).

> The link with bandwidth less than 10 gbps is not suitable to use this feature.

Why not? It looks to me that the %Utilization could be useful even if the bandwidth is not advertised. Possibly a "Bandwidth" reserved value (e.g. 0) could be specified to indicate that the bandwidth is not advertised. This would also fit the case where some ASes do not want to advertise their link capacity.


§3.  Application Considerations

> The SDN controller uses the exit link utilization information to steer the Internet access traffic among all the exit links from the perspective of the whole network.

Indeed, presumably this information is used to influence the routing behavior. May be the document should indicate that the reception of such community over IBGP session should not influence routing decision unless tunneling is used to reach the BGP Next-Hop. (to avoid forwarding loops, incremental deployment issues, complications in error handling).

In addition, what are the interactions with the BGP Link Bandwidth Extended communities? https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth  (I know that the draft expired, but still it's a WG document and an official IANA code point)
Ships in the night? 

>   To avoid route oscillation, the exit router SHOULD set a threshold.   When the utilization change reaches the threshold, the exit router  SHOULD generate a BGP update message with congestion status extended  community.

I think that the document should better evaluate the churn introduced. In particular the churn is cumulative as the number of ASes crossed increase. e.g. if we assume that each AS use the community quite carefully by not advertising more than 1 update per hour, if we have 5 ASes on the way, the ingress AS can receive 5 (additional) updates per prefix per hour.


4.  Security Considerations
> This new extended community does not directly introduce any new security issues.

What about trust/cheating considerations? Especially from remote ASes with which you have zero relationship?
e.g. advertising alleged congestion in order to TE/influence routing of others ASes, advertising plenty of fake capacity to attract more traffic/customers, advertising that they are never experiencing any congestion for commercial reasons, fake advertisement on "behalf" of other ASes...

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.