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 protected]]
Sent: Thursday, December 06, 2018 12:35 PM
To: 'Ahmed Bashandy'; DECRAENE Bruno TGI/OLN; 'SPRING WG List'
Cc: [email protected]; 'Martin Vigoureux'
Subject: RE: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17
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 protected]>
Sent: 06 December 2018 10:45
To: [email protected]; [email protected]; 'SPRING WG List'
<[email protected]>
Cc: [email protected]; 'Martin Vigoureux'
<[email protected]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17
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...
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 protected]><mailto:[email protected]> On
Behalf Of [email protected]<mailto:[email protected]>
Sent: 03 December 2018 18:21
To: SPRING WG List <[email protected]><mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>;
Martin Vigoureux
([email protected]<mailto:[email protected]>)
<[email protected]><mailto:[email protected]>
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17
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 protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc:
[email protected]<mailto:[email protected]>
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 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.
_________________________________________________________________________________________________________________________
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
