Dear authors, I've read the document and have one minor comment and 3 editorials/nits, see below. As a general comment from a non-native speaker I'd suggest a review by a native speaker (noting that one of the authors is a native speaker). I went through that with some of the informational rfcs I've edited and I think it helps to improve readability of a standards track rfc.
I appreciate, that the tie-break section is part of the draft. I admit that I hardly can judge whether that is the right way of doing things. Here I rely on the judgement of the authors and contributors. Related to contents, I think the editor & authors did a good job and the draft is ready for publication. Regards, Ruediger Comments: Section 2.4 Local segments MAY be allocated from the Segment Routing Local Block (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as long as it does not use a reserved label. The SRLB consists of the range of local labels reserved by the node for certain local segments. Would that read better, if the SRLB is defined before label allocation is specified, i.e., switch sentences: The SRLB consists of the range of local labels reserved by the node for certain local segments. Local segments MAY be allocated from the Segment Routing Local Block (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as long as it does not use a reserved label. ################# 2.6. Outgoing Label Collision 2nd section the ingress node may not have exactly have the same data Delete the second "have". ################## 3.1. Example 1 Last para, last sentence The ECMP-awareness ensures that the traffic be load-shared between any ECMP path, in this case the two north and south links between R2 and R3. R2 has two links to R2 and R3, one of which is the north link, while the other is the south link. Suggest to rewrite to: ....ECMP path, in this case the two links between R2 and R3. Or ....ECMP path, in this case the north and south links between R2 and R3. ################### 3.2. Example 2 Suppose the right most router R0 wants..... R0 is the leftmost router #################### Von: spring [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Donnerstag, 7. Juni 2018 18:52 An: SPRING WG List <[email protected]> Cc: [email protected] Betreff: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hi all, A quick update on the status of this WGLC: - All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I've sent them a reminder this Monday. - Two people (Zafar, Adrian) have responded supporting publication. - No opposition. - Two persons have sent comments (Adrian, myself). Thanks Adrian. - Authors have not replied to any comment so far. - The WGLC period was scheduled to end tomorrow. I wish we had more support, reviews, and authors' involvement to reply to reviews. The WGLC is extended by a week. Please review the document and send your comments to the list, no later than *June 15* Thank you, --Bruno From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: [email protected]<mailto:[email protected]> Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again.. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd.. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
