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

> On 3/10/15 14:49 , [email protected] 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
> 
> SRMS can be used to advertise SIDs for SPRING nodes as well.


correct.
s.


> 
> Peter
> 
> 
>> 
>> 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 protected]] De la part de Stefano Previdi 
>> (sprevidi)
>> Envoyé : mardi 10 mars 2015 13:07
>> À : Peter Psenak (ppsenak)
>> Cc : [email protected]; <[email protected]>
>> Objet : Re: [spring] New Version Notification for 
>> draft-lw-spring-sid-allocation-01.txt
>> 
>> 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 protected]> 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
>>> 
>>> On 3/10/15 07:02 , [email protected] wrote:
>>>> 
>>>> 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 protected] 写于 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
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> spring mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>> 
>>> 
>>> _______________________________________________
>>> spring mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/spring
>> 
>> _______________________________________________
>> spring mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/spring
>> 
>> _________________________________________________________________________________________________________________________
>> 
>> 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

Reply via email to