Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

From: <[email-masked]>
Date: Mon, 3 Dec 2018 18:21:07 +0000

Hi all,

Many thanks for all reviews during this last call.

Given some changes and the duration needed to address all comments, we'll do another (3rd) short one-week working group last call limited to the changes done since -13 or possibly to comments not yet addressed from the second last call.
Obviously, you should not refrain from reviewing the whole document and raise any errors in the whole document.

This email starts a (third) Working Group Last Call on draft-ietf-spring-segment-routing-mpls-17 [1] in order to give the working group an additional opportunity to review the changes/document.

There is no need to restate your previous support: there has already been many review and support, and we'll send this document to the IESG.

Thanks,
Regards,
--Bruno, Rob

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-17

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: [email-masked]
Subject: RE: 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-masked] [mailto:[email-masked]]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: [email-masked]
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.

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 3 Dec 2018 22:28:46 -0000

Hi all,

Thanks to the authors for the multiple revisions since -17. I reviewed the
Diff.

All of my review comments along the way seem to have been addressed and I
support moving to publication (soon).

One thing, in Section 2.5.

   An implementation MUST NOT allow the MCCs belonging to the same

   router to assign the same incoming label to more than one SR FEC.  An

   implementation that allows such behaviour is considered a faulty

   implementation and is not covered in this document.

That is a fine statement, but what this document *does* need to cover is how
an implementation protects itself against such a faulty implementation.
Possibly this is covered in Section 2.6, in which case a forward pointer
would be good.

Best,

Adrian

From: spring <[email-masked]> On Behalf Of
[email-masked]
Sent: 03 December 2018 18:21
To: SPRING WG List <[email-masked]>
Cc: [email-masked]; Martin Vigoureux
([email-masked]) <[email-masked]>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

Hi all,

Given some changes and the duration needed to address all comments, we'll do
another (3rd) short one-week working group last call limited to the changes
done since -13 or possibly to comments not yet addressed from the second
last call.

Obviously, you should not refrain from reviewing the whole document and
raise any errors in the whole document.

This email starts a (third) Working Group Last Call on
draft-ietf-spring-segment-routing-mpls-17 [1] in order to give the working
group an additional opportunity to review the changes/document.

There is no need to restate your previous support: there has already been
many review and support, and we'll send this document to the IESG.

Thanks,

Regards,

--Bruno, Rob

 

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] 
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: [email-masked]
<mailto:[email-masked]> 
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hi all,

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

- No opposition.

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-masked] <mailto:[email-masked]>
[mailto:[email-masked]] 
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: [email-masked]
<mailto:[email-masked]> 
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

____________________________________________________________________________
_____________________________________________
 
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.
____________________________________________________________________________
_____________________________________________
 
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.

---

From: Ahmed Bashandy <[email-masked]>
Date: Thu, 6 Dec 2018 02:44:52 -0800

Thanks a lot for the review

The paragraph that you quoted says bugs (A.K.A "faulty implementation") 
are out of the scope of the this document. So there is no part of this 
document that says how to protect against bugs otherwise the document is 
contradicting itself

Thanks again for the thorough review

Ahmed

On 12/3/18 2:28 PM, Adrian Farrel wrote:
>
> Hi all,
>
> Thanks to the authors for the multiple revisions since -17. I reviewed 
> the Diff.
>
> All of my review comments along the way seem to have been addressed 
> and I support moving to publication (soon).
>
> One thing, in Section 2.5…
>
> That is a fine statement, but what this document **does** need to 
> cover is how an implementation protects itself against such a faulty 
> implementation. Possibly this is covered in Section 2.6, in which case 
> a forward pointer would be good.
>
> Best,
>
> Adrian
>
> *From:*spring <[email-masked]> *On Behalf Of 
> [email-masked]
> *Sent:* 03 December 2018 18:21
> *To:* SPRING WG List <[email-masked]>
> *Cc:* [email-masked]; Martin 
> Vigoureux ([email-masked]) <[email-masked]>
> *Subject:* [spring] WG Last Call for 
> draft-ietf-spring-segment-routing-mpls-17
>
> Hi all,
>
> Given some changes and the duration needed to address all comments, 
> we’ll do another (3^rd ) short one-week working group last call 
> limited to the changes done since -13 or possibly to comments not yet 
> addressed from the second last call.
>
> Obviously, you should not refrain from reviewing the whole document 
> and raise any errors in the whole document.
>
> draft-ietf-spring-segment-routing-mpls-17 [1] in order to give the 
> working group an additional opportunity to review the changes/document.
>
> There is no need to restate your previous support: there has already 
> been many review and support, and we’ll send this document to the IESG.
>
> Thanks,
>
> Regards,
>
> --Bruno, Rob
>
> [1]https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-17
>
> *From:[email-masked] <mailto:[email-masked]> 
> *Sent:* Thursday, June 07, 2018 6:52 PM
> *To:* SPRING WG List
> *Cc:* [email-masked] 
> *Subject:* RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13
>
> Hi all,
>
> replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent 
> them a reminder this Monday.
>
> 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-masked] <mailto:[email-masked]> 
> *Sent:* Thursday, May 24, 2018 7:14 PM
> *To:* SPRING WG List
> *Cc:* [email-masked] 
> *Subject:* WG Last Call for draft-ietf-spring-segment-routing-mpls-13
>
> Hello Working Group,
> 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.
> [2] 
> https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Dec 2018 11:34:34 -0000

Hi,

Thanks for your response.

A protocol specification must describe what to do when something unexpected
happens.

Consider, for example, that we will say how to process a message that is
badly encoded or can't be parsed (usually by saying "drop the message, and
possibly log the event").

Are you saying that if an implementation breaks the rule in this text then
that fact is not visible outside of that implementation? That is, the
implementation would break or confuse itself, but would not actually harm
any other implementations in the network? Furthermore, are you saying that
the only way this error could be detected outside the broken implementation
is through misrouting or blackholing of traffic?

If you are saying those two things, then I agree with you that nothing more
needs to be said (although the use of 2119 language doesn't seem to be
appropriate because you are describing the internal details of an
implementation.

If, however, the error is externally detectable (for example, because the
label is advertised associated with more than one SR FEC) then you do need
to describe how the receiver of such advertisements will behave. You have to
do that even if the behaviour is "accept the advertisements at face value".

Cheers,

Adrian

From: Ahmed Bashandy <[email-masked]> 
Sent: 06 December 2018 10:45
To: [email-masked]; [email-masked]; 'SPRING WG List'
<[email-masked]>
Cc: [email-masked]; 'Martin Vigoureux'
<[email-masked]>
Subject: Re: [spring] WG Last Call for
draft-ietf-spring-segment-routing-mpls-17

The paragraph that you quoted says bugs (A.K.A "faulty implementation") are
out of the scope of the this document. So there is no part of this document
that says how to protect against bugs otherwise the document is
contradicting itself

Ahmed

Hi all,

Best,

Adrian

From: spring  <mailto:[email-masked]> <[email-masked]> On
Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: 03 December 2018 18:21
To: SPRING WG List  <mailto:[email-masked]> <[email-masked]>
Cc: [email-masked]
<mailto:[email-masked]> ; Martin Vigoureux
([email-masked] <mailto:[email-masked]> )
<mailto:[email-masked]> <[email-masked]>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

Hi all,

Thanks,

Regards,

--Bruno, Rob

 

Hi all,

- No opposition.

Thank you,

--Bruno

Hello Working Group,

 

Thank you,
Bruno, Rob

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 16:55:18 +0000

Hi Adrian, Ahmed,

Speaking as an individual contributor and co-author:
- I think that this is fine to make a difference between an inconsistency from a (one) faulty sender, and an inconsistency from two correct senders but with inconsistent configurations. Those are different cases which may be handled differently.
- "A protocol specification must describe what to do when something unexpected happens."

With this in mind, I'd propose the following change:

OLD:
   An implementation MUST NOT allow the MCCs belonging to the same
   router to assign the same incoming label to more than one SR FEC. An
   implementation that allows such behavior is considered a faulty
   implementation and is not covered in this document.

NEW:
   An implementation MUST NOT allow the MCCs belonging to the same
   router to assign the same incoming label to more than one SR FEC. An
   implementation that allows such behavior is considered as faulty. Procedures
   defined in this document equally applies to this case, both for incoming label
   collision (§2.5) and effect on outgoing label programming (§2.6)

Possibly the second sentence could be omitted. (I would lightly favor this, but tried to minimize the changes)

On a side note, the document does cover this case:

   2. Within an MCC, apply tie-breaking rules to select one FEC only and
      assign the label to it. The losing FECs are handled as if no
      labels are attached to them. The losing FECs with a non-zero
      algorithm are not installed in FIB.

Cheers,
--Bruno

From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, December 06, 2018 12:35 PM
To: 'Ahmed Bashandy'; DECRAENE Bruno TGI/OLN; 'SPRING WG List'
Cc: [email-masked]; 'Martin Vigoureux'
Subject: RE: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

Hi,

A protocol specification must describe what to do when something unexpected happens.
Consider, for example, that we will say how to process a message that is badly encoded or can't be parsed (usually by saying "drop the message, and possibly log the event").

Are you saying that if an implementation breaks the rule in this text then that fact is not visible outside of that implementation? That is, the implementation would break or confuse itself, but would not actually harm any other implementations in the network? Furthermore, are you saying that the only way this error could be detected outside the broken implementation is through misrouting or blackholing of traffic?

If you are saying those two things, then I agree with you that nothing more needs to be said (although the use of 2119 language doesn't seem to be appropriate because you are describing the internal details of an implementation.

If, however, the error is externally detectable (for example, because the label is advertised associated with more than one SR FEC) then you do need to describe how the receiver of such advertisements will behave. You have to do that even if the behaviour is "accept the advertisements at face value".

Cheers,
Adrian

From: Ahmed Bashandy <[email-masked]>
Sent: 06 December 2018 10:45
To: [email-masked]; [email-masked]; 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; 'Martin Vigoureux' <[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

The paragraph that you quoted says bugs (A.K.A "faulty implementation") are out of the scope of the this document. So there is no part of this document that says how to protect against bugs otherwise the document is contradicting itself
Thanks again for the thorough review

Ahmed

Thanks to the authors for the multiple revisions since -17. I reviewed the Diff.

All of my review comments along the way seem to have been addressed and I support moving to publication (soon).

One thing, in Section 2.5...

That is a fine statement, but what this document *does* need to cover is how an implementation protects itself against such a faulty implementation. Possibly this is covered in Section 2.6, in which case a forward pointer would be good.

Best,
Adrian

From: spring <[email-masked]><mailto:[email-masked]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 December 2018 18:21
To: SPRING WG List <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux ([email-masked]<mailto:[email-masked]>) <[email-masked]><mailto:[email-masked]>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

Hi all,

Thanks,
Regards,
--Bruno, Rob

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hi all,

Thank you,
--Bruno

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: [email-masked]<mailto:[email-masked]>
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hello Working Group,

Thank you,

Bruno, Rob

Thank you.

Thank you.

Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Dec 2018 20:09:43 -0000

Hi Bruno,

> - I think that this is fine to make a difference between an inconsistency
from
>   a (one) faulty sender, and an inconsistency from two correct senders but
with
>   inconsistent configurations. Those are different cases which may be
handled
>   differently.
> - “A protocol specification must describe what to do when something
>   unexpected happens.” 

Good, that's all I'm asking for.

> With this in mind, I’d propose the following change:
>
> OLD:

Thanks, yes, that captures the cases and addresses them by referring to
sections that describe the correct behaviour.

I also think that that sentence doesn't add anything (since any variation
from a MUST or MUST NOT) defines a faulty implementation. But if retaining
that text keeps people happy, then that is fine.

>      algorithm are not installed in FIB.

Yes. 

Hopefully we can make the change you propose and move on.

Best,
Adrian
--
Fairy tales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, December 06, 2018 12:35 PM
To: 'Ahmed Bashandy'; DECRAENE Bruno TGI/OLN; 'SPRING WG List'
Cc: mailto:[email-masked]; 'Martin
Vigoureux'
Subject: RE: [spring] WG Last Call for
draft-ietf-spring-segment-routing-mpls-17

Hi,

A protocol specification must describe what to do when something unexpected
happens.
Consider, for example, that we will say how to process a message that is
badly encoded or can’t be parsed (usually by saying “drop the message, and
possibly log the event”).

If you are saying those two things, then I agree with you that nothing more
needs to be said (although the use of 2119 language doesn’t seem to be
appropriate because you are describing the internal details of an
implementation.

If, however, the error is externally detectable (for example, because the
label is advertised associated with more than one SR FEC) then you do need
to describe how the receiver of such advertisements will behave. You have to
do that even if the behaviour is “accept the advertisements at face value”.

Cheers,
Adrian

From: Ahmed Bashandy <mailto:[email-masked]> 
Sent: 06 December 2018 10:45
To: mailto:[email-masked]; mailto:[email-masked]; 'SPRING WG
List' <mailto:[email-masked]>
Cc: mailto:[email-masked]; 'Martin
Vigoureux' <mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for
draft-ietf-spring-segment-routing-mpls-17

Ahmed

 

 
Best,
Adrian 
 
From: spring mailto:[email-masked] On Behalf Of
mailto:[email-masked]
Sent: 03 December 2018 18:21
To: SPRING WG List mailto:[email-masked]
Cc: mailto:[email-masked]; Martin Vigoureux
(mailto:[email-masked]) mailto:[email-masked]
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17
 
Hi all,

Given some changes and the duration needed to address all comments, we’ll do

There is no need to restate your previous support: there has already been
many review and support, and we’ll send this document to the IESG.
 
Thanks,
Regards,
--Bruno, Rob

From: mailto:[email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: mailto:[email-masked]
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13
 
Hi all,

replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent them a
 
I wish we had more support, reviews, and authors’ involvement to reply to
reviews.

Thank you,
--Bruno
 
From: mailto:[email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: mailto:[email-masked]
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13
 
Hello Working Group,

 

Thank you,
Bruno, Rob

---

From: Ahmed Bashandy <[email-masked]>
Date: Sun, 9 Dec 2018 05:31:12 -0800

There is no document in the world that can cover what to do in case of 
bugs, simply because a document is finite while bugs are infinite

However to avoid unnecessary discussions, I posted version 18 with the 
text that Bruno suggested

Ahmed

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 9 Dec 2018 17:39:08 -0800

I reviewed the doc and had a bunch of editorial suggestions.

Anoop

==

Section 2
control layer protocol -> control plane protocol
Segment routing header instantiated -> Segment routing header is instantiated
We call "MPLS Control Plane Client (MCC)" any control plane ->
We use the term "MPLS Control Plane Client (MCC)" to refer to any control plane
which restrict its ability -> which restricts its ability
In order ... -> This paragraph should be a subsection titled Node-SID
TI-LFA -- expand acronym and provide reference (the reference is
provided later, but should be provided here)
node-SID -> Node-SID

Section 2.1
...,etc -> , etc.
Instantiating Segment -> Instantiating segment

Section 2.2
Probably be better if moved to being the first subsection in Section 2.

Section 2.3
MPLS Label ranges -> MPLS label ranges
The list of ranges comprising -> Any pair of ranges from the list of
ranges comprising
A Local segment -> A local segment
except rule -> except the rule
...future study -> ...future study.

Section 2.4
In the title -- label -> Label

Section 2.5
Segment-Routing MPLS -> Segment Routing MPLS
For the purpose of incoming
label collision resolution, a routing instance is identified by a
single incoming label downloader to FIB.
...identified by a single entity that installs incoming labels in the LFIB?
(downloader is a new term.)

make numerical value -> make the numerical value
map to the same -> maps to the same
a first-come-first-serve -> first-come-first-serve
still collision -> still a collision
reload -> reboot (only instance of reload, many instances of reboot)

Section 2.5.1
Each FEC is assigned an administrative distance. The FEC
administrative distance is encoded as an 8-bit value. The lower the
value, the better the administrative distance.
Move to be first paragraph in 2.5.1

smallest numerical FEC value -> smallest numerical FEC value.
collision freeness on the same router -> collision freeness on the same router.
administrative distance of any other FEC type -> administrative
distance of any other FEC type.
type code point for each SR FEC defined at the beginning of this Section ->
code points for each SR FEC types defined at the beginning of this section
an SR policy [RFC8402]. -> an SR policy [RFC8402]
Missing periods at the end of many bullets/sub-bullets, and at last
sentence of section.
encoded in a 16 bits field -> encoded using 16 bits
routing_instance_id, Topology, SR Algorithm,) -> Routing Instance ID,
Topology, SR Algorithm)
Color_id -> Color ID
allow to map the original index -> allow mapping of the original index

Section 2.5.2.2
with the prefix 192.0.2.1/32 ->  with the prefix 192.0.2.1/32.
index 1 corresponds to the local label 16001 -> index 1 corresponds to
the local label 16001.  (Also remove following bullet.)
adj-SID, Adj-SID -- make consistent

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 10 Dec 2018 09:45:57 -0000

Thank you for that.
Adrian

-----Original Message-----
From: Ahmed Bashandy <[email-masked]> 
Sent: 09 December 2018 13:31
To: [email-masked]; [email-masked]
Cc: [email-masked]; 'Martin Vigoureux' <[email-masked]>; 'SPRING WG List' <[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17

Ahmed