Hi Peter, On 8/19/15, 1:22 PM, "Peter Psenak" <[email protected]> wrote:
>Stephane, > >there are two things involved here - configuration and advertisement. > >If you look at the SR drafts for both IGPs, both MTID and algorithm is >advertised with Prefix SID, not with SRGB. [Pushpasis] Again IMO, SRGBs published per topology and hence ISIS/OSPF SR extensions should be modified to add an optional MTID field as well. > >That does not mean you have to manually configure prefix SID for each >MTID or algorithm - there are ways how this can be achieved in an >automated way while advertising a single topology/algorithm agnostic SRGB. [Pushpasis] I am assuming by 'automated way’ you still mean separate indexes per topology for the same prefix. Right? Thanks -Pushpasis > >thanks, >Peter > > >On 8/19/15 09:36 , [email protected] wrote: >> Hi, >> >> We come back to the same discussion for MT as for per algorithm SRGB. >>Do we need for operational reason the same index value to be configured >>for different algorithm or topologies ? >> IMO, it is useful operationally otherwise adding a topology or >>algorithm would be painful ... Adding a new index value is like >>assigning a new prefix but here we want to use the same prefix. >> >> Stephane >> >> -----Original Message----- >> From: spring [mailto:[email protected]] On Behalf Of Pushpasis >>Sarkar >> Sent: Wednesday, August 19, 2015 09:06 >> To: Peter Psenak; Eric Rosen; SPRING WG >> Subject: Re: [spring] SRGBs, indexes, and topologies within a domain >> >> Hi Peter, >> >> On 8/19/15, 12:01 PM, "Peter Psenak" <[email protected]> wrote: >> >>> SR protocol extensions clearly do - they advertise MTID with the prefix >>> SID, not with SRGB. >>> >> [Pushpasis] Do you mean that a separate index per topology is mandatory? >> That won¹t be a good idea in my opinion. Operators SHOULD have >>flexibility to choose a separate or same index for the same prefix under >>different topology. Not sure how other members (especially the >>operators) think about the same. Request SR authors to re-consider this. >> >> Thanks >> -Pushpasis >> >>> >> >> _______________________________________________ >> 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
