> 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 protected]] Envoyé : mardi 10 mars 2015 15:15 À : Peter Psenak (ppsenak) Cc : GUEDREZ Rabah IMT/OLN; [email protected]; [email protected] 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 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. >> > _________________________________________________________________________________________________________________________ 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
