Subject: [spring] Fwd: New Version Notification for draft-lw-spring-sid-allocation-01.txt

From: [email-masked]
Date: Tue, 10 Mar 2015 14:02:32 +0800

Hi all,

New version of SID Allocation has been published and description has been 
revised according to comments from the mailing list.
Comments are welcome and discussions in Dallas are expected. 

Best Regards.
Ting
----- 转发人 廖婷038768/user/zte_ltd 时间 2015-03-10 08:48 -----

[email-masked] 写于 2015-03-09 14:39:17:

> 
> A new version of I-D, draft-lw-spring-sid-allocation-01.txt
> has been successfully submitted by Fangwei Hu and posted to the
> IETF repository.
> 
> Name:      draft-lw-spring-sid-allocation
> Revision:   01
> Title:      SPRING SID Allocation
> Document date:   2015-03-08
> Group:      Individual Submission
> Pages:      12
> URL:            http://www.ietf.org/internet-drafts/draft-lw-spring-
> sid-allocation-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-lw-spring-
> sid-allocation/
> Htmlized: http://tools.ietf.org/html/draft-lw-spring-sid-allocation-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-lw-spring-
> sid-allocation-01
> 
> Abstract:
>    Segment Routing (SR) allows for a flexible definition of end-to-end
>    paths within IGP topologies by encoding paths as sequences of
>    topological sub-paths, called "segments".  These segments are
>    advertised by the link-state routing protocols (IS-IS and OSPF).  And
>    a segment is identified by a Segment Routing ID (SID).  This document
>    proposes a method to reduce the SID configuration in a SR domain.
>    Only the selected SR nodes which named Segment Routing Management
>    Nodes (SRMNs) are configured by NMS, while other SRs in the domain
>    need zero-SR-configuration.
> 
>  
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2015 12:46:32 +0100

Ting,

there is a concept of SR Mapping Server, which can be used to advertise 
SIDs for prefixes from the central place.

draft-ietf-ospf-segment-routing-extensions defines the OSPF Extended 
Prefix Range TLV in section 4 which is used to advertise the SID 
mappings by SRMS. Similarly ISIS SR drafts defines a similar mechanism 
in ISIS. There are already implementations that support SRMS.

What you defined in your draft looks very similar to SRMS and we 
definitely do not need two different ways to achieve the same goal.

regards,
Peter

On 3/10/15 07:02 , [email-masked] wrote:
>
> Hi all,
>
> New version of SID Allocation has been published and description has
> been revised according to comments from the mailing list.
>  > Htmlized:
> http://tools.ietf.org/html/draft-lw-spring-sid-allocation-01
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Mar 2015 12:06:43 +0000

I agree. We already have interop tests done on the SRMS so what is the real added value of another proposal ?

s.

On Mar 10, 2015, at 12:46 PM, Peter Psenak <[email-masked]> wrote:

> Ting,
> 
> there is a concept of SR Mapping Server, which can be used to advertise SIDs for prefixes from the central place.
> 
> draft-ietf-ospf-segment-routing-extensions defines the OSPF Extended Prefix Range TLV in section 4 which is used to advertise the SID mappings by SRMS. Similarly ISIS SR drafts defines a similar mechanism in ISIS. There are already implementations that support SRMS.
> 
> What you defined in your draft looks very similar to SRMS and we definitely do not need two different ways to achieve the same goal.
> 
> regards,
> Peter
>

---

From: <[email-masked]>
Date: Tue, 10 Mar 2015 13:49:49 +0000

The mapping server is attended to bind prefixes and SID of  non SPRING nodes, not to configure a SPRING node see https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop-02#section-4.2

Configuring SPRING nodes can be done manually or via a centralized entity,
The centralized entity can be an SDN controller or an extended   mapping server, configs can be pushed using OpenFlow or NETCONFIG /YANG see https://tools.ietf.org/id/draft-litkowski-spring-sr-yang-00.txt

In my opinion we should work on the process of configuring SPRING nodes, the architecture(SR-client and SR-controller) and defining the minimum configs for a node to function properly.

Nether the proposed draft nor the section on the mapping server addressed those requirements.

There are two types of configurations that need to be pushed to SPRING nodes  : Required and Optional 
Required configs : are all the information that has global signification like node-SID, anycast-SID,++ ..., or when decided to use the same SRGB on all the SPRING nodes, those config must be done manually or pushed from centralized entity.
Optional configs : all the decision that can be made locally by the "SR-client"  like assigning Adj-SIDs to the node interfaces.

-----Message d'origine-----
De : spring [mailto:[email-masked]] De la part de Stefano Previdi (sprevidi)
Envoyé : mardi 10 mars 2015 13:07
À : Peter Psenak (ppsenak)
Cc : [email-masked]; <[email-masked]>
Objet : Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

s.

_________________________________________________________________________________________________________________________

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: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2015 14:58:06 +0100

> The mapping server is attended to bind prefixes and SID of  non SPRING nodes, not to configure a SPRING node see https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop-02#sec…

SRMS can be used to advertise SIDs for SPRING nodes as well.

Peter

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Mar 2015 14:14:46 +0000

> SRMS can be used to advertise SIDs for SPRING nodes as well.

correct.
s.

---

From: <[email-masked]>
Date: Tue, 10 Mar 2015 14:22:25 +0000

> SRMS can be used to advertise SIDs for SPRING nodes as well.

Can you clarify some points for me, does your  mapping server push configuration to the SPRING node or Advertise the node-SID, ADj-SID, SID-RANGE and so on. using the IGP on the behalf of the SPRING node.
Rabah.

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Envoyé : mardi 10 mars 2015 15:15
À : Peter Psenak (ppsenak)
Cc : GUEDREZ Rabah IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

On Mar 10, 2015, at 2:58 PM, Peter Psenak <[email-masked]>
 wrote:

>> The mapping server is attended to bind prefixes and SID of  non 
>> SPRING nodes, not to configure a SPRING node see 
>> https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp
>> -interop-02#section-4.2
> 

correct.
s.

>> There are two types of configurations that need to be pushed to 
>> SPRING nodes  : Required and Optional Required configs : are all the information that has global signification like node-SID, anycast-SID,++ ..., or when decided to use the same SRGB on all the SPRING nodes, those config must be done manually or pushed from centralized entity.
>> De : spring [mailto:[email-masked]] De la part de Stefano 
>> Previdi (sprevidi) Envoyé : mardi 10 mars 2015 13:07 À : Peter Psenak 
>> (ppsenak) Cc : [email-masked]; <[email-masked]> Objet : Re: 
>> [spring] New Version Notification for 
>> draft-lw-spring-sid-allocation-01.txt
>> 
>>>> New version of SID Allocation has been published and description 
>>>> has been revised according to comments from the mailing list.
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> 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.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2015 15:36:28 +0100

> Can you clarify some points for me, does your  mapping server push configuration to the SPRING node or Advertise the node-SID, ADj-SID, SID-RANGE and so on. using the IGP on the behalf of the SPRIN…

SRMS advertises mappings between prefixes and SIDs. Prefixes can be 
located in SPRING domain or outside.

Peter

---

From: <[email-masked]>
Date: Tue, 10 Mar 2015 15:07:32 +0000

> SRMS advertises mappings between prefixes and SIDs. Prefixes can be located in SPRING domain or outside.
If did understand ^-^ then the SRMS implement an instance of IGP (OSPF or ISIS) for every SPRING node it advertise all the SR information, is that correct ?

-----Message d'origine-----
De : Peter Psenak [mailto:[email-masked]] 
Envoyé : mardi 10 mars 2015 15:36
À : GUEDREZ Rabah IMT/OLN; Stefano Previdi (sprevidi)
Cc : [email-masked]; [email-masked]
Objet : Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

> Can you clarify some points for me, does your  mapping server push configuration to the SPRING node or Advertise the node-SID, ADj-SID, SID-RANGE and so on. using the IGP on the behalf of the SPRIN…

SRMS advertises mappings between prefixes and SIDs. Prefixes can be located in SPRING domain or outside.

Peter

> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoyé : 
> mardi 10 mars 2015 15:15 À : Peter Psenak (ppsenak) Cc : GUEDREZ Rabah 
> IMT/OLN; [email-masked]; [email-masked] Objet : Re: [spring] 
> New Version Notification for draft-lw-spring-sid-allocation-01.txt
>
>
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>> 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.
>>>
> ______________________________________________________________________
> ___________________________________________________
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 10 Mar 2015 16:29:00 +0100

> If did understand ^-^ then the SRMS implement an instance of IGP (OSPF or ISIS) for every SPRING node it advertise all the SR information, is that correct ?

SRMS uses IGP to advertise mappings between prefixes and SIDs - that's 
all it does.

Peter

---

From: [email-masked]
Date: Wed, 11 Mar 2015 17:33:06 +0800

Hi rabah，peter，stefano,

Thanks for your reviews and comments. The SID allocation proposal is used 
to 
solve the automatic SID configuration based on the operator's requirment 
of zero configuration for the nodes. 
It includes the following differences with SRMS：

1.  It has a mechanism to ensure the uniqueness of SID allocation. 
When two or more SRMNs(SR management nodes described in this draft) 
allocate different SIDs to the same prefix, 
we provide a method for the SR nodes to choose one of the SID in the 
proposal.

2.  The SRMN only allocates SID to SR node in this draft. 
I wonder there may be some problem if SRMS can allocates SID to non-SR 
node and SR node. 

For example, the SRMS is in charge of mapping a SID( SID A) to a non SR 
node（node A）originally, 
and then SRMS floods the mapping message to SR domain, when a SR node(node 
B) receives  the message, 
node B learns an entry of SID A with a nexthop, where  the nexthop is the 
shortest path to SRMS but not to node A. 
Of course the SRMS can be used to allocate a SID（SID C）to a SR node(node 
C), 
when SR node B learns  this message , it still learns the nexthop is the 
shortest path to SRMS， 
and in this case，the nexthop should be to node C.

In this proposal, the nexthop is to SR node C.

3.  In the allocation TLV described in this draft, it can carry other SR 
related configuration such as algorithm, MT number, 
and in a TLV, it can carry one or more ip addresses, no matter the 
addresses are consecutive or inconsecutive. 

Best Regards.
Ting

"spring" <[email-masked]> 写于 2015-03-10 21:49:49:

> SPRING nodes, not to configure a SPRING node see https://tools.ietf.
> 
org/html/draft-filsfils-spring-segment-routing-ldp-interop-02#section-4.2
> The centralized entity can be an SDN controller or an extended 
> mapping server, configs can be pushed using OpenFlow or NETCONFIG /YANG 
see 
> https://tools.ietf.org/id/draft-litkowski-spring-sr-yang-00.txt
> 
> In my opinion we should work on the process of configuring SPRING 
> nodes, the architecture(SR-client and SR-controller) and defining 
> the minimum configs for a node to function properly.
> 
> SPRING nodes  : Required and Optional 
> Required configs : are all the information that has global 
> signification like node-SID, anycast-SID,++ ..., or when decided to 
> use the same SRGB on all the SPRING nodes, those config must be done
> manually or pushed from centralized entity.
> Optional configs : all the decision that can be made locally by the 
> "SR-client"  like assigning Adj-SIDs to the node interfaces.
> 
> 
> Previdi (sprevidi)
> I agree. We already have interop tests done on the SRMS so what is 
> the real added value of another proposal ?
> 
> s.
> 
> 
> > there is a concept of SR Mapping Server, which can be used to 
> advertise SIDs for prefixes from the central place.
> > 
> > draft-ietf-ospf-segment-routing-extensions defines the OSPF 
> Extended Prefix Range TLV in section 4 which is used to advertise 
> the SID mappings by SRMS. Similarly ISIS SR drafts defines a similar
> mechanism in ISIS. There are already implementations that support SRMS.
> > 
> 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,
> privileged information that may be protected by law;
> 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: Peter Psenak <[email-masked]>
Date: Wed, 11 Mar 2015 11:06:31 +0100

Ting,

On 3/11/15 10:33 , [email-masked] wrote:
>
> Hi rabah，peter，stefano,
>
> Thanks for your reviews and comments. The SID allocation proposal is
> used to

above has nothing to do with SRMS or SRMN as such, conflict resolution 
is handled at the receiving routers and is completely orthogonal to the 
way you distribute it.

> I wonder there may be some problem if SRMS can allocates SID to non-SR

there is no problem in allocating SID for non-SR node. There are 
multiple implementations of SRMS that do that and it proved to work fine.

> and then SRMS floods the mapping message to SR domain, when a SR
> node(node B) receives  the message,
> node B learns an entry of SID A with a nexthop, where  the nexthop is
> the shortest path to SRMS but not to node A.

what is the problem? In SR domain no matter what is the next hop, SID is 
a global index and the value of index is bound to a prefix on all nodes. 
In a non-SR domain, SID is not used at all.

> Of course the SRMS can be used to allocate a SID（SID C）to a SR
> node(node C),

advertising a capability of a remote node from the SRMN can become 
dangerous, especially if the node is not configured consistently with 
what is advertised from the SRMN.

regards,
Peter

>  > mapping server, configs can be pushed using OpenFlow or NETCONFIG
> /YANG see

---

From: <[email-masked]>
Date: Wed, 11 Mar 2015 10:08:02 +0000

>Hi, Please see inline[Rabah]

De : [email-masked] [mailto:[email-masked]]
Envoyé : mercredi 11 mars 2015 10:33
À : GUEDREZ Rabah IMT/OLN; Peter Psenak (ppsenak); Stefano Previdi (sprevidi)
Cc : [email-masked]; spring
Objet : Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi rabah，peter，stefano,

Thanks for your reviews and comments. The SID allocation proposal is used to
solve the automatic SID configuration based on the operator's requirment of zero configuration for the nodes.
It includes the following differences with SRMS：

1.  It has a mechanism to ensure the uniqueness of SID allocation.
When two or more SRMNs(SR management nodes described in this draft) allocate different SIDs to the same prefix,
we provide a method for the SR nodes to choose one of the SID in the proposal.

2.  The SRMN only allocates SID to SR node in this draft.
I wonder there may be some problem if SRMS can allocates SID to non-SR node and SR node.

For example, the SRMS is in charge of mapping a SID( SID A) to a non SR node（node A）originally,
and then SRMS floods the mapping message to SR domain, when a SR node(node B) receives  the message,
node B learns an entry of SID A with a nexthop, where  the nexthop is the shortest path to SRMS but not to node A.
Of course the SRMS can be used to allocate a SID（SID C）to a SR node(node C),
when SR node B learns  this message , it still learns the nexthop is the shortest path to SRMS，
and in this case，the nexthop should be to node C.
>[Rabah]  No this not true upon the reception of  the mapping SID-A prefix Z by any SR-Node , the node IGP-SPF will match the SID A prefix with its routing table and calculate
  the shortest path(exit interface) to that prefix and install an entry in the NHFE( Next Hop Label   Forwarding Entry).

3.  In the allocation TLV described in this draft, it can carry other SR related configuration such as algorithm, MT number,
and in a TLV, it can carry one or more ip addresses, no matter the addresses are consecutive or inconsecutive.

Best Regards.
Ting

"spring" <[email-masked]<mailto:[email-masked]>> 写于 2015-03-10 21:49:49:

> mapping server, configs can be pushed using OpenFlow or NETCONFIG /YANG see
> Cc : [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>>
> On Mar 10, 2015, at 12:46 PM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Ting,
> >
> > On 3/10/15 07:02 , [email-masked]<mailto:[email-masked]> wrote:
> >>
> >> Hi all,
> >>
> >> [email-masked]<mailto:[email-masked]> 写于 2015-03-09 14:39:17:
> >>
> >> >
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 12 Mar 2015 15:02:45 +0800

Hi Rabah,

If the nexthop learnt from the mapping message is the nexthop to the 
prefix of non SR node, 
as shown in the figure: 

The SRMS allocates a SID label 105 to a non SR node LR5,
SR1 learns the message, and the nexthop of SR1 to LR5 is to R4, 
SR4 and LR5 is a normal IGP adjancency without label.
When SR1 sending out a packet with a top label 105, the nexthop is to R4,
R4 receives the mpls packet, but it doesn’t have a label forwarding 
entry, it will drop the packet. 

Best Regards.
Ting

used to 
> solve the automatic SID configuration based on the operator's 
> requirment of zero configuration for the nodes. 
> we provide a method for the SR nodes to choose one of the SID in 
theproposal.
> For example, the SRMS is in charge of mapping a SID( SID A) to a non SR 
node（
> node A）originally, 
> node B learns an entry of SID A with a nexthop, where  the nexthop 
> is the shortest path to SRMS but not to node A. 
> >[Rabah]  No this not true upon the reception of  the mapping SID-A 
> prefix Z by any SR-Node , the node IGP-SPF will match the SID A 
> prefix with its routing table and calculate 
>   the shortest path(exit interface) to that prefix and install an 
> entry in the NHFE( Next Hop Label   Forwarding Entry).
> 
> 
> 3.  In the allocation TLV described in this draft, it can carry 
> other SR related configuration such as algorithm, MT number, 
/YANG see 
> > >> New version of SID Allocation has been published and description 
has

---

From: [email-masked]
Date: Thu, 12 Mar 2015 15:10:16 +0800

Hi Peter,

Please see inline [Ting].

Best Regards.
Ting

> > solve the automatic SID configuration based on the operator's 
requirment
> is handled at the receiving routers and is completely orthogonal to the 

[Ting] Yes, the receiving router handles the conflict, and the conflict 
resolution 
is based on the extension as described in the SID allocation.
> multiple implementations of SRMS that do that and it proved to work 
fine.

[Ting] Yes, the SRMS is in charge of allocating sid for non-sr node 
originally.

> In a non-SR domain, SID is not used at all.

[Ting] When a SID is allocated to a non SR node, it is used to indicate 
the packet 
sending from SR domain to non SR domain, it must be sent to SRMS, 
otherwise how the SID convert to LDP label. 
The detail has been described in the mailing list replied to Rabah.

> what is advertised from the SRMN.

[Ting] Do you mean that it is dangerous for the SRMN to allocate the SID?
The SRMN allocates SR related configuration includes SID etc.
 
> >  > SPRING nodes, not to configure a SPRING node see 
https://tools.ietf.
has

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Mar 2015 07:34:23 +0000

Hi Ting

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 12, 2015 3:03 PM
To: [email-masked]
Cc: [email-masked]; spring; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: [spring] 答复: Re: New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi Rabah,

If the nexthop learnt from the mapping message is the nexthop to the prefix of non SR node,
as shown in the figure:
The SRMS allocates a SID label 105 to a non SR node LR5,
SR1 learns the message, and the nexthop of SR1 to LR5 is to R4,
SR4 and LR5 is a normal IGP adjancency without label.
When SR1 sending out a packet with a top label 105, the nexthop is to R4,
R4 receives the mpls packet, but it doesn’t have a label forwarding entry, it will drop the packet.

[Xiaohu] In fact, R4 could also tunnel the received MPLS packet to LR5 via an IP-based tunnel. For more details, please see the approach as described in (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-03).

Best regards,
Xiaohu

Best Regards.
Ting

"spring" <[email-masked]<mailto:[email-masked]>> 写于 2015-03-11 18:08:02:

> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> Cc : [email-masked]<mailto:[email-masked]>; spring
> we provide a method for the SR nodes to choose one of the SID in theproposal.
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Mar 2015 08:00:47 +0000

Hi Ting,

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 12, 2015 3:10 PM
To: Peter Psenak
Cc: [email-masked]; [email-masked]; spring; Stefano Previdi (sprevidi)
Subject: Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi Peter,

Best Regards.
Ting

"spring" <[email-masked]<mailto:[email-masked]>> 写于 2015-03-11 18:06:31:

> Ting,
>
> On 3/11/15 10:33 , [email-masked]<mailto:[email-masked]> wrote:
> >
> > Hi rabah，peter，stefano,
> >

[Ting] Yes, the receiving router handles the conflict, and the conflict resolution
is based on the extension as described in the SID allocation.
> multiple implementations of SRMS that do that and it proved to work fine.

[Ting] Yes, the SRMS is in charge of allocating sid for non-sr node originally.
> In a non-SR domain, SID is not used at all.

[Ting] When a SID is allocated to a non SR node, it is used to indicate the packet
sending from SR domain to non SR domain, it must be sent to SRMS,
otherwise how the SID convert to LDP label.
The detail has been described in the mailing list replied to Rabah.

[Xiaohu] The SID mappings originated by the mapping servers are just label mappings/bindings. In other words,  these mappings should not impact the shortest path selection on other routers at all.

Best regards,
Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Mar 2015 09:07:22 +0100

Ting,

please see inline:

> [Ting] Yes, the SRMS is in charge of allocating sid for non-sr node

no, that is not correct. It can allocate SIDs for SR and non-SR nodes.

> otherwise how the SID convert to LDP label.

above statement is incorrect. SRMS does not require traffic flowing from 
SR domain to non-SR domain to transit via SRMS.

If the router(s) in the border of the SR and non-SR domain are smart 
enough, they can stich the LSP based on info from SRMS and LDP.

> other SR

no, it's dangerous for SRMN to advertise the capabilities of the remote 
nodes.

regards,
Peter

---

From: [email-masked]
Date: Thu, 12 Mar 2015 16:13:30 +0800

Hi Xiaohu,

I think it would be solved by learning the nexthop of the SID is the 
shortest route to SRMS.

Best Regards.
Ting

Xuxiaohu <[email-masked]> 
2015-03-12 15:34

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, spring <[email-masked]>, 
"Stefano Previdi (sprevidi)" <[email-masked]>, "Peter Psenak 
(ppsenak)" <[email-masked]>
主题
RE: [spring] 答复: Re:  New Version Notification for 
draft-lw-spring-sid-allocation-01.txt

Hi Ting
 
From: spring [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Thursday, March 12, 2015 3:03 PM
To: [email-masked]
Cc: [email-masked]; spring; Stefano Previdi (sprevidi); Peter Psenak 
(ppsenak)
Subject: [spring] 答复: Re: New Version Notification for 
draft-lw-spring-sid-allocation-01.txt

Hi Rabah, 

[Xiaohu] In fact, R4 could also tunnel the received MPLS packet to LR5 via 
an IP-based tunnel. For more details, please see the approach as described 
in (
https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-03
).
 
Best regards,
Xiaohu

Best Regards.
Ting 

used to 
theproposal.
node（
/YANG see 
has 
> > >> > URL:            
http://www.ietf.org/internet-drafts/draft-lw-spring-

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Mar 2015 08:33:13 +0000

Hi Ting,

IGP-SR is just another label distribution method. Therefore, just like LDP, it should not influence the best path selection result.

Best regards,
Xiaohu

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 12, 2015 4:14 PM
To: Xuxiaohu
Cc: [email-masked]; [email-masked]; spring; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: Re: [spring] New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi Xiaohu,

I think it would be solved by learning the nexthop of the SID is the shortest route to SRMS.

Best Regards.
Ting

Xuxiaohu <[email-masked]<mailto:[email-masked]>>

2015-03-12 15:34

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, "Stefano Previdi (sprevidi)" <[email-masked]<mailto:[email-masked]>>, "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>

主题

RE: [spring] 答复: Re:  New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi Ting

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 12, 2015 3:03 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; spring; Stefano Previdi (sprevidi); Peter Psenak (ppsenak)
Subject: [spring] 答复: Re: New Version Notification for draft-lw-spring-sid-allocation-01.txt

Hi Rabah,

Best regards,
Xiaohu

Best Regards.
Ting

"spring" <[email-masked]<mailto:[email-masked]>> 写于 2015-03-11 18:08:02:

> > SPRING nodes, not to configure a SPRING node see https://tools.ietf<https://tools.ietf/>.

---

From: [email-masked]
Date: Thu, 12 Mar 2015 16:33:50 +0800

Hi Peter,

Please see inline [Ting]:

Best Regards.
Ting

> >  > > we provide a method for the SR nodes to choose one of the SID in 
the
> no, that is not correct. It can allocate SIDs for SR and non-SR nodes.

[Ting] I agree, it can be used to allocate the SIDs for SR nodes, 
I meant it is used to allocate SIDs for non SR nodes in the first version 
of draft-filsfils-spring-segment-routing-ldp-interop.

> no, it's dangerous for SRMN to advertise the capabilities of the remote 

[Ting] In the SID allocation solution, the SRMN is not in charge of 
allocate the capabilities.

https://tools.ietf.
> >  > >  >
> >  > >  > Configuring SPRING nodes can be done manually or via a 
centralized
> >  > > entity,
> >  > >  > Nether the proposed draft nor the section on the mapping 
server
> >  > >  > addressed those requirements.
> >  > >  >
> >  > >  > Objet : Re: [spring] New Version Notification for 
draft-lw-spring-
> >  > >  > the SID mappings by SRMS. Similarly ISIS SR drafts definesa 
similar
> >  > >  > >> >    Segment Routing (SR) allows for a flexible definition 
of
> >  > > end-to-end
> >  > >  > >> >    advertised by the link-state routing protocols (IS-IS 
and
> >  > > OSPF).  And
> >  > >  > >> >    a segment is identified by a Segment Routing ID (SID). 
 This
> >  > > document
> >  > >  > >> >    Nodes (SRMNs) are configured by NMS, while other SRs 
in the
> >  > > domain
> >  > >  > Orange decline toute responsabilite si ce message a ete 
altere,
> >  > >  > deforme ou falsifie. Merci.
> >  > >  >

---

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Mar 2015 10:42:29 +0100

> allocate the capabilities.

"In the allocation TLV described in this draft, it can carry
other SR related configuration such as algorithm, MT number, ..."

---

From: [email-masked]
Date: Thu, 12 Mar 2015 17:54:41 +0800

> other SR related configuration such as algorithm, MT number, ..."

Algorithm and MT(multi-topology) ID both are configuration values, 
advertising within the SID allocation TLV, 
and the new draft-ietf-isis-segment-routing-extensions-03 added the 
extension of the algorithm in the binding tlv:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length    |0|0|           |     Weight    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Range = 4          |       /32     |      192      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       .0      |        .2     |       .1      |Prefix-SID Type|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | sub-TLV Length|     Flags     |   Algorithm   |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                             1 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Best Regards.
Ting

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Mar 2015 08:22:39 +0100

> extension of the algorithm in the binding tlv:

right, but they are advertised by the router itself, not by some central 
entity.

Peter