Hi Peter, Please see inline [Ting]:
Best Regards. Ting "spring" <[email protected]> 写于 2015-03-12 16:07:22: > Ting, > > please see inline: > > On 3/12/15 08:10 , [email protected] wrote: > > > > 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. > > 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. > > > > > > > > > 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. > > 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. > > > > > 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? > > no, it's dangerous for SRMN to advertise the capabilities of the remote > nodes. [Ting] In the SID allocation solution, the SRMN is not in charge of allocate the capabilities. > > regards, > Peter > > 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 definesa 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 > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
