Hi,
On 2015-07-21, 5:04 PM, "[email protected]" <[email protected]> wrote: >Hi Tarek, > >I think per-prefix granularity is still possible. >Advertising a SRGB for a particular algorithm does not mean that all the >prefixes advertised will be advertised for that particular algorithm. > >I mean considering you have a network with node A ,B, C, D, each one >advertising a loopback. >You want to run algo 0 between all routers, so each router advertises a >SRGB for algo 0, and loopback address with SID is advertised with Algo 0 >also. >Now you want to run algo 2 but only A and B requires communication >between each other using algo 2. As C and D may be on the path from A to >B, all routers requires supports of algo 2 and a new SRGB is provisioned [TS]: Yes, if a prefix is to be reachable via alg 2, it¹s understandable every other node a will allocate/program label for alg2. >on all routers corresponding to algo 2. But in term of SID advertisement, >you may configure only A and B to advertise Algo2 for Loopback address >(Algo is encoded in PrefixSID), so there would be only 2 new MPLS [TS]: quote from draft: "In Option 2 each node advertises a single node index and a unique label block for each algorithm. " 1) it is not clear (from proposal) if alg support is to be explicitly enabled per prefix, and how? If it is to be explicitly enabled per alg2 for a prefix/loopback, wouldn't the overhead be comparable to configuring an index per algorithm? 2) also, not clear how a node announces support for multiple algs for same SID index value. Is multiple prefix-SID sub-TLVs announced with same SID index and for every algorithm it supports? If so, wondering how would a node withdraw support for a specific alg? Regards, Tarek >forwarding entries instead of 4. > >Does it make sense ? > >Stephane > > >-----Original Message----- >From: spring [mailto:[email protected]] On Behalf Of Tarek Saad >(tsaad) >Sent: Tuesday, July 21, 2015 15:05 >To: [email protected] >Cc: [email protected] >Subject: Re: [spring] New Version Notification for >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > >Hi Chris, > >A possible limitation of advertizing per-alg SRGB is that a node will >always assign/maintain as many SRGB-alg labels (on possibly all nodes) >for a prefix without being able to control this on per-prefix if needed. >Are there are any considerations for this in your proposal? > >Regards, >Tarek > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Wednesday, June 24, 2015 6:03 PM >To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; >Pushpasis Sarkar; Hannes Gredler >Subject: New Version Notification for >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > > >A new version of I-D, >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt >has been successfully submitted by Chris Bowers and posted to the IETF >repository. > >Name: draft-bowers-spring-adv-per-algorithm-label-blocks >Revision: 01 >Title: Advertising Per-Algorithm Label Blocks >Document date: 2015-06-24 >Group: Individual Submission >Pages: 7 >URL: >https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algorithm >- >label-blocks-01.txt >Status: >https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm-lab >e >l-blocks/ >Htmlized: >https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label-bl >o >cks-01 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-bowers-spring-adv-per-algorithm-la >b >el-blocks-01 > >Abstract: > Segment routing uses globally-known labels to accomplish destination- > based forwarding along shortest paths computed using Dijkstra's > algorithm with IGP metrics. This draft discusses how to use segment > routing to accomplish destination-based forwarding along paths > computed using other algorithms and metrics. In particular, the > draft contrasts two different options for associating labels with > different algorithms for computing forwarding next-hops. > > > > > >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 > >__________________________________________________________________________ >_______________________________________________ > >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
