Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

[<[e-mail]>]

Hi Alvaro,

Thanks for your comment, please find some replies inline.

Brgds,


-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]] 
Sent: Wednesday, July 04, 2018 14:36
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Alvaro Retana's No Objection on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-spring-entropy-label-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a similar opinion as others regarding the status of this document:
informational vs proposed standard.  While I don't disagree with the intention
of the WG to put this work on the standards track, I think that, as a standard,
the document still needs some work:  even when using rfc2119 language, the
specification is not as precise as I would hope.  A couple of examples from §7:

(a) "This section describes some considerations that could be taken into
account when placing ELI/ELs.  This list of criteria is not considered as
exhaustive and an implementation MAY take into account additional criteria or
tie-breakers that are not documented here."  Even if specific language is used
later on, the preface says that the considerations don't have to be taken into
account ("could be"), and that there is other criteria (not in this document)
that could be used.  How are multiple implementations to consistently
interoperate?

[SLI] On the ingress side, there is no particular interoperability issue if two implementations does not use the same criteria.
The result will be a different placement of ELI/EL for a similar LSP.
I'm proposing the following addition:
"As the insertion of ELI/ELs is performed by the ingress node, having ingress nodes that does not use the same criteria does not cause an interoperability issue. However, from a network design and operation perspective, it is better to have all ingress routers using the same criteria."



(b) "An implementation SHOULD try to maximize the load-balancing where multiple
ECMP paths are available and minimize the number of EL/ELIs that need to be
inserted."  How does an implementation try?  How would an implementation
maximize load balancing?  I don't remember seeing anything like that in rfc6790.

[SLI] I agree that the sentence is not really clear. RFC6790 does not have to deal with the same issues as we have with SPRING.
In RFC6790, when an egress advertises the ELC and the ingress pushes an ELI/EL, the network configuration can ensure that proper loadbalancing will happen.
SPRING has to deal with paths which are composed of subpaths (segment list), so we (as SP) need to ensure that we can get loadbalancing of each required subpath.
 Here is a proposed modification:
" An implementation SHOULD try to maximize the possibility of load-balancing along the path by inserting an ELI/EL where multiple equal cost paths are available and minimize the number of ELI/ELs that need to be inserted."


On the process side, the IETF LC should be redone simply because it was done
assuming an informational status (regardless of the downref).

[I am not balloting DISCUSS because I'm sure the responsible AD will do the
right thing.]



_________________________________________________________________________________________________________________________

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.