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 protected]> 写于 2015-03-10 21:49:49: > 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 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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
