Hi Peter, Please see inline [Ting].
Best Regards. Ting "spring" <[email protected]> 写于 2015-03-11 18:06:31: > Ting, > > On 3/11/15 10:33 , [email protected] wrote: > > > > 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. > > 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. [Ting] Yes, the receiving router handles the conflict, and the conflict resolution is based on the extension as described in the SID allocation. > > > > 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. > > 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. [Ting] Yes, the SRMS is in charge of allocating sid for non-sr node originally. > > > > 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. > > 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. [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. > > 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. > > 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. [Ting] Do you mean that it is dangerous for the SRMN to allocate the SID? The SRMN allocates SR related configuration includes SID etc. > regards, > Peter > > > > > 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 > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
