On 3/12/15 08:02 , [email protected] wrote:
Hi Rabah, If the nexthop learnt from the mapping message is the nexthop to the prefix of non SR node, as shown in the figure: The SRMS allocates a SID label 105 to a non SR node LR5, SR1 learns the message, and the nexthop of SR1 to LR5 is to R4, SR4 and LR5 is a normal IGP adjancency without label. When SR1 sending out a packet with a top label 105, the nexthop is to R4,
given that SR is not running on a link between SR1 and SR4, SR1 would send packet as unlabeled to R4.
Peter
R4 receives the mpls packet, but it doesn’t have a label forwarding entry, it will drop the packet. Best Regards. Ting "spring" <[email protected]> 写于 2015-03-11 18:08:02: > >Hi, Please see inline[Rabah] > > De : [email protected] [mailto:[email protected]] > Envoyé : mercredi 11 mars 2015 10:33 > À : GUEDREZ Rabah IMT/OLN; Peter Psenak (ppsenak); Stefano Previdi (sprevidi) > Cc : [email protected]; spring > Objet : Re: [spring] New Version Notification for draft-lw-spring- > sid-allocation-01.txt > > > 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 theproposal. > > 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. > >[Rabah] No this not true upon the reception of the mapping SID-A > prefix Z by any SR-Node , the node IGP-SPF will match the SID A > prefix with its routing table and calculate > the shortest path(exit interface) to that prefix and install an > entry in the NHFE( Next Hop Label Forwarding Entry). > > > 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 > _________________________________________________________________________________________________________________________ > > 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
