Thanks a lot for the comments
I uploaded version 15 of the draft on Oct/23
See my response to your comments "#Ahmed"
On 6/13/18 2:32 AM, [email protected] wrote:
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.
#Ahmed:
I have changed the wording of this paragraph based on comments from
others. I hope the new wording is good
#################
2.6. Outgoing Label Collision
2^nd section
the ingress node may not have exactly have the
same data
Delete the second “have”.
#Ahmed:
Done
##################
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.
#Ahmed:
Version 15 of the draft uses this wording (thanks). Just be aware that
all examples have been moved to appendix
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
#Ahmed:
We got rid of example 2 based on received comments
####################
*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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
