Hi Peter, On 8/19/15, 5:25 PM, "Peter Psenak" <[email protected]> wrote:
>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. [Pushpasis] I am trying give both options to a operator (i.e. Single SRGB with per-topology SID-index as well as single SID-index with per-topology SRGB). Depending on which one the operators prefer, one of them becomes redundant :) Also the MTID is not attached to the prefix-SID but the prefix with which the SID-index is attached. That is an existing information outside SR. Again in my opinion, MTID with SRGB will be preferable than MTID with prefix-SID, in case one needs to be preferred the other. > > >> 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. [Pushpasis] Sorry if I sound like that. But I am deducing the proposal out of a requirement which I think is relevant to most operators. If operators think they are fine with one SID-index per topology for the same prefix, I will take back my proposal. But yet again I think that operators will prefer to have the same index for the same prefix across multiple topologies and just have one SRGB per topology. I urge all the operators to provide their preference. Thanks -Pushpasis > >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
