Hi Pushpasis, On 8/19/15 13:13 , Pushpasis Sarkar wrote: > Some corrections/additions in my response earlier… > > On 8/19/15, 3:47 PM, "spring on behalf of Pushpasis Sarkar" > <[email protected] <mailto:[email protected]> on behalf of > [email protected] <mailto:[email protected]>> wrote: > > Hi Peter, > > On 8/19/15, 3:27 PM, "Peter Psenak" <[email protected] > <mailto:[email protected]>> wrote: > > Hi Pushpasis, > > On 8/19/15 10:43 , Pushpasis Sarkar wrote: > > Hi Peter, > On 8/19/15, 1:22 PM, "Peter Psenak" <[email protected] > <mailto:[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. > > > please bear in mind that there are implementation out there in > the field > with the existing encoding. > > [Pushpasis] That’s why I said that MTID in SR-Capability should be > optional. The SRGB for the default topology can be encoded without a > MTID > (no impact to current implementation). The SRGB for other topologies can > be encoded with a MTID field. *Might as well be a separate > MT-SRCapabality subTLV.* > > If you move the MTID/algorithm fileds from > Prefix SID to SRGB, what is the MTID/algorithm fields in prefix > SID used > for? > > > [Pushpasis] The MTID in prefix TLV is for having the index > associated with > the prefix.
What you need is a different label for same prefix per MTID/algorithm - that we agree on. To achieve that you either need single SID and per MTID/algorithm SRGB or single SRGB with per MTID/algorithm SIDs. If you look at OSPF encoding, both MTID and algorithm are inside the Prefix-SID sub-TLV. ISIS has MTID in the Prefix TLV and algorithm in Prefix SID sub-TLV. Nevertheless, from the architecture perspective both IGPs assumed the same. The SR architecture from the very beginning assumed per MTID/algorithm SID, not per MTID/algorithm SRGB and IGP encoding has been designed with that in mind. If you add MTID and algorithm in SRGB as well, you end up with the MTID and algorithm fields at two different TLVs for the same topology - inside SRGB and inside the Prefix SID sub-TLV, which is clearly redundant. > If one uses the same index with differenet MTIDs(different > topologies) the label allocated for the same prefix for the two > different > topologies shall be *different* *same*. If the forwarding path for > the prefix for > one topology needs to be different than the other, having the same label > for the same prefix for the two different topology is not an option. > Hence > we need a different SRGB for each topology. That’s why we need a MTID in > the SR-Capability. you need different labels for same prefix in different topologies, that does not mean you need a different SRGB. Please do not present your solution as a requirement. thanks, Peter > > Having the MTID/algorithm fileds in both Perfix SID and SRGB would > be redundant and confusing. > > > 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? > > > advertisement wise yes, config wise no. > > [Pushpasis] I did not understand how advertisement can be different from > configuration. In my understanding advertisements are derived from > configurations. > > Thanks > -Pushpasis > > > thanks, > Peter > > Thanks > -Pushpasis > > > thanks, > Peter > > > On 8/19/15 09:36 , [email protected] > <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
