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

From: <[email-masked]>
Date: Thu, 7 Jun 2018 16:52:02 +0000

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.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 08 Jun 2018 08:00:50 +0800

Hi all,

I have read this doc and support the publication.

Xiaohu

------------------------------------------------------------------
From:bruno.decraene <[email-masked]>
Send Time:2018年6月8日(星期五) 00:52
To:SPRING WG List <[email-masked]>
Cc:[email-masked] <[email-masked]>
Subject:Re: [spring] 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.

I wish we had more support, reviews, and authors’ involvement to reply to reviews.

Thank you,
--Bruno

    

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

---

From: Chris Bowers <[email-masked]>
Date: Fri, 8 Jun 2018 13:14:00 -0500

SPRING WG,

I generally support publication of
draft-ietf-spring-segment-routing-mpls. However, I think
that the text in sections 2.5 and 2.6 (on incoming label collisions)
needs some work before publication. This text was added to
the draft a few months ago, and has not gotten much review
from the WG as a whole. The review and proposed text below
focuses on these sections.

As I understand the current text of the draft, the general
approach to resolving incoming label collisions seems
well-reasoned and complete.  However, it is possible that
my interpretation of these tie-breaking rules is
not what the authors intended.

I'd like to propose the examples below to be included
in the draft to help clarify the tie-breaking rules
for incoming label collisions described in section 2.5.
I have highlighted several cases in these examples,
where I think the rules in section 2.5 need
to be clarified in order to unambiguously determine
the winning FEC in an example.

It may also be the case that the authors or other
WG participants will disagree with the interpretation of the
rules used to choose a winning FEC in some of these
examples.  In that case, we should discuss
what is the correct interpretation, and clarify the
text in the draft to make the correct interpretation
clear.

Incoming label collision examples
=========

Node A
OSPF default admin distance for implementation=50
ISIS default admin distance for implementation=60

=========
Example incoming label conflict for label=1005 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.5/32 with index=5
OSPF SRGB on node A = [1000,1999]
Incoming label=1005

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.105/32 with index=5
ISIS SRGB on node A = [1000,1999]
Incoming label=1005

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1006 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6
OSPF SRGB on node A = [1000,1999]
Incoming label=1006

FEC2)
ISIS adjacency sid advertisement from node A with label=1006
Incoming label=1006
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
the FEC types is SR Policy, we use the default admin distances of 50
and 60 to break the tie.  So FEC1 wins.

=========
Example incoming label conflict for label=1007 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.7/32 with index=7
OSPF SRGB on node A = [1000,1999]
Incoming label=1007

FEC2)
ISIS adjacency sid advertisement from node A with label=1007
Incoming label=1007
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.

=========
Example incoming label conflict for label=1008 on node A

FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.8/32 with index=8
OSPF SRGB on node A = [1000,1999]
Incoming label=1008

FEC2)
SR Policy advertisement from controller to node A
Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
Binding-SID label = 1008

FEC1 and FEC2 both use dynamic SID assignment.
Since one of the FEC types is SR Policy, default admin
distance is not used to break the tie.
/* The text in Section 2.5.1 needs to be clarified to specify
whether SR Policy always loses or always wins in this case. */

=========
Example incoming label conflict for label=1009 on node A

FEC1)
OSPF adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC2)
ISIS adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.

FEC1 and FEC2 both use explicit SID assignment.  This kind of
incoming label collision should never occur, since an
implement of explicit SID assignment MUST guarantee
collision freeness on the same router.

========
Example incoming label conflict for label=1010 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.110/32 with index=10
ISIS SRGB on node A = [1000,1999]
Incoming label=1010

FEC2)
ISIS adjacency sid advertisement by node A with label=1010
Incoming label=1010
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130.
Therefore, FEC1 wins.

=========
Example incoming label conflict for label=1011 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.111/32 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC2)
ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 with
index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Since IPv4 is
preferred over IPv6, FEC1 wins.

=========
Example incoming label conflict for label=1012 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.112/32 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.128/30 with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  FEC1 has prefix length=32,
and FEC2 has prefix length=30, so FEC2 wins.

=========
Example incoming label conflict for label=1013 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.113/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.213/32 with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013

FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point.  Both FECs have FEC type
code-point=120. So we compare address family.  Both are IPv4 address
family, so we compare prefix length.  Prefix lengths are the same,
so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins.

=========
Example incoming label conflict for label=1014 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.114/32 with index=14
Routing Instance ID = 1000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.114/32 with index=14
Routing Instance ID = 2000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014

These two FECs match all the way through the prefix length and prefix.
So Routing Instance ID breaks the tie, with FEC1 winning.

=========
Example incoming label conflict for label=1015 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.115/32 with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 40
ISIS SRGB on node A = [1000,1999]
Incoming label=1015

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins.

/* There appears to be a typo in section 2.5.1, with two different
orderings shown for a prefix-based FEC:
Prefix, Routing Instance, Topology, Algorithm
and
(Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)
This needs to be corrected. */

=========
Example incoming label conflict for label=1016 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 0
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.116/32 with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 22
ISIS SRGB on node A = [1000,1999]
Incoming label=1016

These two FECs match all the way through the prefix length, prefix, and
Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so
FEC1 wins.

=========
Example incoming label conflict for label=1017 on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.117/32 with index=17
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

FEC2)
ISIS mapping server advertisement (SID/Label Binding TLV) from node D:
Range=100, Prefix = 203.0.113.1/32
This mapping server advertisment generates 100 mappings, one of which
maps 203.0.113.17/32 to index=17.
ISIS SRGB on node A = [1000,1999]
Incoming label=1017

The fact that FEC1 comes from a normal prefix sid advertisement and
FEC2 is generated from a mapping server advertisement is not
used as a tie-breaking parameter. Both FECs use dynamic SID assignment,
are from the same MCC, have the same FEC type code-point=120. Their prefix
lengths are the same as well.  FEC2 wins based on lower numerical prefix
value,
since 203.0.113.17 is less than 203.0.113.117.

=========
Example incoming label conflict for label=1018 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1018
corresponding to next-hop interface address=192.0.2.100, outgoing interface
ID=5
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv6 adjacency sid advertisement from node A with label=1018
corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130.  FEC1 wins
because IPv4 address family is preferred over IPv6.

=========
Example incoming label conflict for label=1019 on node A

FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.220, outgoing interface
ID=7
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

FEC2)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.230, outgoing interface
ID=8
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.

Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. Both FECs have to
same address family.  FEC1 wins based on having the lowest next-hop
interface address.

/* It is not clear how to construct an example that
would result in using the outgoing interface ID as a tie-breaker.
It would be useful to understand why this is and clarify
it in the text. */
=========
Example incoming label conflict for label=1020 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
Binding-SID label=1020

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
Binding-SID label=1020

The FECs match through the tie-breaks up to and including
having the same FEC type code-point=140.
FEC2 wins based on IPv4 address family being preferred
over IPv6.

=========
Example incoming label conflict for label=1021 on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
Binding-SID label=1021

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
Binding-SID label=1021

The FECs match through the tie-breaks up to and including
having the same address family. FEC1 wins by having the
lower numerical endpoint address value.

=========

I'd like to propose the examples below to be included
in the draft to help clarify section 2.6
(currently entitled "Outgoing Label Collision").

Examples of the Effect Incoming Label Collision on Outgoing Label
Programming
====================================

Example of effect of incoming label collision for label=1022
on outgoing label programming on node A

FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.122/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.222/32 with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022

FEC1 wins based on lowest numerical prefix value.  This means that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1022, with
outgoing label N,
and use outgoing interace I. N is determined by the index associated with
FEC1 (index=22) and
the SRGB advertised by the next-hop node on the shortest path to reach
203.0.113.122/32.

Node A will generally also install an ingress MPLS forwarding entry
corresponding to FEC1 for
incoming prefix=203.0.113.122/32 pushing outgoing label N, and using
outgoing interace I.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS
forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=203.0.113.222/32).

========

Example of effect of incoming label collision for label=1023
on outgoing label programming on node A

FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
Binding-SID label=1023

FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
Binding-SID label=1023

FEC1 wins by having the lower numerical endpoint address value. This means
that node A
installs a transit MPLS forwarding entry to SWAP incoming label=1023, with
outgoing labels
and outgoing interface determined by the SID-List for FEC1.
Node A will generally also install an ingress MPLS forwarding entry
corresponding to FEC1 for
incoming prefix=192.0.2.80/32 pushing outgoing labels and using the
outgoing interface
determined by the SID-List for FEC1.

The rule in section 2.6 means that node A MUST NOT install an ingress MPLS
forwarding entry
corresponding to FEC2 ( which would be for incoming prefix=192.0.2.81/32).

========

General comment:

section 2.6 title:
existing:
Outgoing Label Collision:
proposed:
Effect of Incoming Label Collision on Outgoing Label Programming :
--------------------------------------

Thanks,
Chris

On Thu, May 24, 2018 at 12:14 PM, <[email-masked]> wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Przemyslaw Krol <[email-masked]>
Date: Sat, 9 Jun 2018 00:01:01 -0700

Greetings,

Few minor, cosmetic/editorial suggestions:

2.5. Incoming Label Collision
[...]
*(Endpoint, Color)* representing an SR policy [I.D. filsfils-spring-
segment-routing-policy]

(Color, Endpoint) is the ordering used by the policy draft. If the decision
is to correct it, there is few references in the draft

2.5.1. Tie-breaking Rules
[...]
       o The Color ID is encoded using *16 bits*

should be 32 bits
(https://tools.ietf.org/html/rfc5512#section-4.3.1 &&
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-00#section-2.1
)

2.6. Outgoing Label Collision
[...]
In the general case, the ingress node may not have exactly *have* the same
data of the receiving node

2.7. PUSH, CONTINUE, and NEXT
PUSH, NEXT, and CONTINUE are operations applied by the forwarding plan*e*.
[...]

2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs
[...]
an IGP with SR extensions *[*I-D.ietf-isis-segment-routing-extensions,
I-D.ietf-ospf-segment-routing-extensions]

^^^ missing '[' or alternatively both references should be enclosed in
their own []

thanks,
pk

On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers <[email-masked]>
wrote:

> OSPF prefix sid advertisement from node B for 198.51.100..8/32
> <http://198.51.100.8/32> with index=8
> ISIS prefix sid advertisement from node C for 203.0.113..213/32
> <http://203.0.113.213/32> with index=13
> so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins..
>
> =========
> ISIS prefix sid advertisement from node C for 203..0.113.116/32
> <http://203.0.113.116/32> with index=16
> corresponding to next-hop interface address=192.0.2.100, outgoing
> interface ID=5
> Incoming label=1018
> corresponding to next-hop interface address=192.0.2.220, outgoing
> interface ID=7
> Incoming label=1019
> corresponding to next-hop interface address=192.0.2.230, outgoing
> interface ID=8
> Incoming label=1019
> On Thu, May 24, 2018 at 12:14 PM, <[email-masked]
> <[email-masked]>> wrote:
>
>> Hello Working Group,
>>
>>
>>
>> - Shraddha has agreed to be the document shepherd... Thank you Shraddha.
>>

-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [email-masked]

---

From: Przemyslaw Krol <[email-masked]>
Date: Sat, 9 Jun 2018 12:29:42 -0700

Greetings,

In terms of UHP, draft-ietf-isis-segment-routing-extensions-16
<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16#section-2.1.1>
describes
2 cases:
 - P set, E unset
 - P set, E set

However it looks that draft-ietf-spring-segment-routing-15
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.1.2>
doesn't
make that distinction and doesn't seem to cover the latter case:

   o  A remote node M MUST maintain the following FIB entry for any
      learned Prefix-SID SID-R attached to IP prefix R:

     Incoming Active Segment: SID-R
     Ingress Operation:
        If the next-hop of R is the originator of R
        and instructed to remove the active segment: NEXT
*        Else: CONTINUE*
     Egress interface: the interface towards the next-hop along the
                       path computed using the algorithm advertised with
                       the SID toward prefix R.

Would it make sense to also describe the 2nd option (E+P) given ISIS draft
brings this up as a use case?

thanks,
pk

On Sat, Jun 9, 2018 at 12:01 AM Przemyslaw Krol <[email-masked]> wrote:

> (Color, Endpoint) is the ordering used by the policy draft. If the
> decision is to correct it, there is few references in the draft
>
>> installs a transit MPLS forwarding entry to SWAP incoming label=1022,
>> with outgoing label N,
>> The rule in section 2.6 means that node A MUST NOT install an ingress
>> MPLS forwarding entry
>> FEC1 wins by having the lower numerical endpoint address value. This
>> means that node A
>> installs a transit MPLS forwarding entry to SWAP incoming label=1023,
>> with outgoing labels
>> The rule in section 2.6 means that node A MUST NOT install an ingress
>> MPLS forwarding entry

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 11 Jun 2018 14:55:27 -0700

Thanks a lot for the through review

I posted version 14 few minutes ago to address your comments

See my reply as #Ahmed

On 5/25/18 2:22 AM, Adrian Farrel wrote:
>
> Hi,
>
> I think it is well past time that we completed this foundation work
>
> and got an RFC published. So I support passing this draft to the AD
>
> again.
>
> However, we do need to clean it up first. Hopefully this won't be a
>
> lot of effort for the editors as nearly all I found were editorial
>
> nits.
>
> As a side comment, it isn't a success that section 2.5 is so large.
>
> Full one quarter of the document is dedicated to the edge case of
>
> collision avoidance. That said, I don't have a better solution.
>
> Thanks for the work.
>
> Adrian
>
> ====
>
> idnits isn't as clean as it could be. In particular:
>
> - 2.5.2.1 uses IP address 1.1.1.1 and should pick one from RFC 6890.
>
> - Missing normative reference for RFC 8174
>
> - [I-D.ietf-idr-segment-routing-te-policy] is not used
>
> - [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and
>
> [I-D.ietf-ospf-segment-routing-extensions] have spurious spaces in
>
> the filenames
>
#Ahmed: Fixed

> ---
>
> You'll need to move the "Requirements Language" to be Section 1.1.
>
#Ahmed: Moved it to section 1.1
>
> ---
>
> Section 2
>
> s/link State IGPs/link state IGPs/
>
> s/Segment ID (SIDs)/Segment IDs (SIDs)/
>
#Ahmed: Fixed
>
> ---
>
> You use SRGB in 2.2 before you expand it in 2.3
>
#Ahmed: I expanded it at the beginning of Section 2.2
>
> ---
>
> 2.2
>
> oThe label value MUST be unique within the router on which the MCC
>
> is running. i.e. the label MUST only be used to represent the SID.
>
> I don't think you mean this. You have written that the label value has
>
> be unique which means that only one label value can be assigned to a
>
> SID.
>
> I think what you mean is that
>
> oThe label value MUST NOT be used for any other purpose on the
>
> router on which the MCC is running. I.e. the label MUST NOT be
>
> used to represent more than one SID or for any other forwarding
>
> purpose on the router.
>
#Ahmed: I used a slightly different wording than what you suggested. 
Here it is
The label value MUST be unique within the router on which the MCC is 
running. i.e. the label MUST only be used to represent the SID and MUST 
NOT be used to represent more than one SID or for any other forwarding 
purpose on the router.
>
> ---
>
> 2.2
>
> Unusual to have a normative reference to an IANA URL as you have for
>
> [reserved-MPLS]. Besides, the URL you give is 404.
>
> You would do better to reference RFC 7274.
>
#Ahmed: Agreed and done
>
> You might also fix the language and terminology, thus...
>
> OLD
>
> oThe label value MUST NOT be identical to or within the range of
>
> any reserved label value or range [reserved-MPLS], respectively.
>
> NEW
>
> oThe label value MUST NOT come from the range of special purpose
>
> labels [RFC7274].
>
#Ahmed: Agreed and done
>
> ---
>
> 2.3 ditto
>
> OLD
>
> oEvery range in the list of ranges specifying the SRGB MUST NOT
>
> cover or overlap with a reserved label value or range [reserved-
>
> MPLS], respectively.
>
> NEW
>
> oEvery range in the list of ranges specifying the SRGB MUST NOT
>
> cover or overlap with the range of special purpose labels
>
> [RFC7274].
>
#Ahmed: Agreed and Done
>
> ---
>
> 2.3
>
> oIf the SRGB of a node does not conform to the structure specified
>
> in this section or to the previous two rules, then this SRGB is
>
> completely ignored and the node is treated as if it does not have
>
> an SRGB.
>
> Can we fix this passive voice? Presume the intention is that the
>
> advertisement of this SRGB is ignored by any routing protocol speakers
>
> that receive it.
>
> Two points of clarification I think we should add:
>
> 1. The *whole* SRGB is ignored, not simply the range of labels in a set
>
> of ranges that is at fault
>
> 2. The term "ignore" in this case means that no SR action is taken, but
>
> the SRGB advertisement continues to be propagated within the routing
>
> protocol.
>
#Ahmed: the section defines the SRGB as a single entity consisting of a 
list of label ranges. Hence the SRGB is not divisible. The document 
clearly specifies what "ignore" means by saying "and the node is treated 
as if it does not have an SRGB.". How a routing protocol advertises the 
SRGB (e.g. by flooding, leaking between levels/areas) is beyond the 
scope of this document. I modified the statement slightly to indicate 
what does it mean "ignored"
>
> ---
>
> 2.3 (bottom of page 5)
>
> s/reserved label/special purpose label/
>
#Ahmed: renamed "reserved label" to special purpose label through out 
the document as you s
>
> ---
>
> 2.3
>
> s/contiguous range of label/contiguous range of labels/
>
#Ahmed: Done
>
> ---
>
> 2.5
>
> s/(e.g.,over/(e.g., over/
>
> s/map to the same incoming/maps to the same incoming/
>
> s/FECk} maps to the same/FECk} map to the same/
>
> s/non-zero algo/non-zero algorithm/
>
#Ahmed: Corrected or removed the statement containing the typo
>
> ---
>
> 2.5.1
>
> The plural of FEC is FECs not FEC's
>
#Ahmed: corrected the 3 occurrences
>
> ---
>
> 2.5.1
>
> 2. if more than one competing FEC remains after step 1, sort them and
>
> select the smallest numerical FEC value
>
> Is sorting required? Can we just have...
>
> 2. if more than one competing FEC remains after step 1, select the
>
> smallest numerical FEC value
>
#Ahmed: Agreed and modified accordingly
>
> ---
>
> 2.5.1
>
> An implementation may choose to implement additional
>
> s/may/MAY/
>
#Ahmed: Agreed and modified accordingly
> ---
> 2.5.2
> s/THEN/then/
#Ahmed: Agreed and modified accordingly
> ---
> 2.7
> s/plan./plane./
#Ahmed: Agreed and modified accordingly
>
> ---
>
> Terminology for adjacency SIDs needs to be harmonised.
>
> draft-ietf-spring-segment-routing has "IGP-Adjacency Segment" and
>
> "Adj-SID"
>
> This document has:
>
> adjacency SID (2.5.1)
>
> Adj-SID (2.7.3)
>
> adj-SID (2.7.3)
>
> IGP-adjacency-SID (2.8)
>
> IGP-Adj-SID (2.11.1)
>
> IGP adj-SID (2.11.2)
>
  #Ahmed: I changed all of them to adj-SID
>
> ---
>
> Some of the section names are overly long and can be cut down without
>
> risking much. This helps with layout and readability. Just a suggestion,
>
> but...
>
> OLD
>
> 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix
>
> 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global 
> SIDs
>
> 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs
>
> 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on Local SIDs
>
> 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for 
> Local SIDs
>
> NEW
>
> 2.1. Multiple Forwarding Behaviors for the Same Prefix
>
> 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs
>
> 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs
>
> 2.10.2. Forwarding for NEXT Operation for Global SIDs
>
> 2.11.1. Forwarding for PUSH Operation on Local SIDs
>
> 2.11.2. Forwarding for CONTINUE Operation for Local SIDs
>
#Ahmed: Thanks for the advice. Modified as suggested
>
> ---
>
> For some reason the definite article is missing before a lot of
>
> instances of "FIB". For example, in 2.8...
>
> The label corresponding to the global SID "Si" represented by the
>
> global index "I" downloaded to FIB is used to match packets whose
>
> ---
>
> 2.10
>
> OLD
>
> This section specifies forwarding behavior, including the outgoing
>
> label(s) calculations corresponding to a global SID when applying
>
> PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.
>
> This document covers the calculation of outgoing label for the top
>
> label only. The case where outgoing label is not the top label and is
>
> part of a stack of labels that instantiates a routing policy or a
>
> traffic engineering tunnel is covered in other documents such as
>
> [I.D.filsfils-spring-segment-routing-policy].
>
> NEW
>
> This section specifies forwarding behavior, including the calculation
>
> of outgoing labels, that corresponds to a global SID when applying
>
> PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.
>
> This document covers the calculation of the outgoing label for the
>
> top label only. The case where the outgoing label is not the top
>
> label and is part of a stack of labels that instantiates a routing
>
> policy or a traffic engineering tunnel is covered in other documents
>
> such as [I.D.filsfils-spring-segment-routing-policy].
>
#Ahmed: Modified as suggested
>
> ---
>
> 2.10.1
>
> s/{RFC3031]/[RFC3031]/
>
> ---
>
> 2.10.2 has
>
> oApply the instruction associated with the incoming label prior to
>
> popping
>
> This is a little ambiguous. Might be read that the instruction should be
>
> applied prior to popping. The text that follows des clarify, but perhaps
>
> rewrite as...
>
> oApply the instruction associated with the incoming label that has
>
> been popped
>
#Ahmed: Agreed and modified accordingly
>
> ---
>
> In order that ECMP descriptions work in the examples, Section 3 just
>
> needs a quick comment like.
>
> All links in this example have the same IGP metric.
>
#Ahmed: Added a phrase to the end of the second sentence in the section
>
> ---
>
> While it is largely OK to defer the discussion of manageability in
>
> Section 5 to draft-ietf-spring-segment-routing, it would make sense
>
> to make explicit reference to RFC 8287 because that is the key document
>
> that means no further OAM discussion is needed in this document.
>
> Probably just copy in the following paragraph
>
> SR OAM use cases for the MPLS data plane are defined in
>
> [I-D.ietf-spring-oam-usecase].SR OAM procedures for the MPLS data
>
> plane are defined in [RFC8287].
>
#Ahmed. Copied
>
> ---
>
> 8.
>
> Possibly Himanshu would prefer to be named as "Himanshu Shah".
>
#Ahmed: Thanks for catching that :)
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* 24 May 2018 18:14
> *To:* SPRING WG List
> *Cc:* [email-masked]
> *Subject:* [spring] 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.
> [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,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Jun 2018 10:53:00 +0100

Good work, Ahmed.
 
Very many thanks for the changes and for the clear response to my review.
 
Best,
Adrian
 
From: Ahmed Bashandy [mailto:[email-masked]] 
Sent: 11 June 2018 22:55
To: [email-masked]; [email-masked]; 'SPRING WG List'
Cc: [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13

 

 
Thanks for the work.
 
Adrian
 
====

 

---

---
 
Section 2

---

 
---
 
2.2
   o  The label value MUST be unique within the router on which the MCC
      is running. i.e. the label MUST only be used to represent the SID.

 
   o  The label value MUST NOT be used for any other purpose on the 
      router on which the MCC is running. I.e. the label MUST NOT be 
      used to represent more than one SID or for any other forwarding
      purpose on the router.
#Ahmed: I used a slightly different wording than what you suggested. Here it is
The label value MUST be unique within the router on which the MCC is running.
i.e. the label MUST only be used to represent the SID and MUST NOT be used to
represent more than one SID or for any other forwarding purpose on the router.

---
 
2.2

 
 
OLD
   o  The label value MUST NOT be identical to or within the range of
      any reserved label value or range [reserved-MPLS], respectively.
NEW
   o  The label value MUST NOT come from the range of special purpose
      labels [RFC7274].
#Ahmed: Agreed and done

---
 
2.3 ditto
 
OLD
   o  Every range in the list of ranges specifying the SRGB MUST NOT
      cover or overlap with a reserved label value or range [reserved-
      MPLS], respectively.
NEW
   o  Every range in the list of ranges specifying the SRGB MUST NOT
      cover or overlap with the range of special purpose labels 
      [RFC7274].
#Ahmed: Agreed and Done

---
 
2.3
 
   o  If the SRGB of a node does not conform to the structure specified
      in this section or to the previous two rules, then this SRGB is
      completely ignored and the node is treated as if it does not have
      an SRGB.

 

#Ahmed: the section defines the SRGB as a single entity consisting of a list of
label ranges. Hence the SRGB is not divisible. The document clearly specifies
what "ignore" means by saying "and the node is treated as if it does not have an
SRGB.". How a routing protocol advertises the SRGB (e.g. by flooding, leaking
between levels/areas) is beyond the scope of this document. I modified the
statement slightly to indicate what does it mean "ignored"

---
 
2.3 (bottom of page 5)
 
s/reserved label/special purpose label/
#Ahmed: renamed "reserved label" to special purpose label through out the
document as you s 
 
---
 
2.3

---
 
2.5

---
 
2.5.1

---
 
2.5.1

 

---
 
2.5.1

---
 
2.5.2
s/THEN/then/
 
---
 
2.7
s/plan./plane./
 
---

 
This document has:
adjacency SID (2.5.1)
Adj-SID (2.7.3)
adj-SID (2.7.3)
IGP-adjacency-SID (2.8)
IGP-Adj-SID (2.11.1)
IGP adj-SID (2.11.2)

---

OLD
2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global SIDs
2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local SIDs

---

 
---
 
2.10
OLD

 
---
 
2.10.1
s/{RFC3031]/[RFC3031]/
 
---
 
2.10.2 has
 
   o  Apply the instruction associated with the incoming label prior to
      popping

   o  Apply the instruction associated with the incoming label that has
      been popped
#Ahmed: Agreed and modified accordingly

---

 
---

 
   SR OAM use cases for the MPLS data plane are defined in
   [I-D.ietf-spring-oam-usecase].  SR OAM procedures for the MPLS data
   plane are defined in [RFC8287].
#Ahmed. Copied

---
 
8.

 
From: spring [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 24 May 2018 18:14
To: SPRING WG List
Cc: [email-masked]
Subject: [spring] 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.

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.

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 15:40:13 +0000

Hi all,

- WGLC has ended.
- All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I sending another reminder today.
- Six non authors (Zafar, Adrian, Xiaohu, Chris, Pk, Ruediger) have responded supporting publication.
- No opposition.
- Six persons have sent comments (Adrian, Chris, pk, Ruediger, Sasha, myself). Thank you.
- Authors have addressed Adrian's comments. Please engage resolution with the five remaining reviewers.

I'll wait on:
- contributors to replies to IPR
- authors to reply to reviewers

Then next step would be:
- Shepherd report (Shraddha)
- AD decision (Martin)
- Submission to IESG

Thank you,
--Bruno

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,

Thank you,
--Bruno

Hello Working Group,

Thank you,

Bruno, Rob

Thank you.

Thank you.