Stefano is correct - and I find it hard to understand the positions of the objectors.
A label - to borrow a phrase used by others - is an instruction to the forwarding plane to send a packet along a given path. Clearly, when IGPs calculate paths they do so in the context of a topology. So if we are going to use a SID as a means of encoding the IGP calculated topology specific path to the forwarding plane clearly SIDs MUST be topology specific. This is why the prefix-SID sub-TLV in IS-IS is allowed in the MT prefix reachability TLVs defined in RFC 5120. When a mapping server is used in place of advertising SIDs in prefix reachability TLVs, clearly MTID also needs to be supported. A few more remarks inline. > -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Stefano Previdi > (sprevidi) > Sent: Thursday, May 21, 2015 9:44 AM > To: Hannes Gredler > Cc: [email protected]; [email protected] list > Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing- > extensions > > Hi Hannes, > > On May 21, 2015, at 4:34 PM, Hannes Gredler <[email protected]> wrote: > > hi stefano, > > > > On Thu, May 21, 2015 at 01:55:07PM +0000, Stefano Previdi (sprevidi) > wrote: > > | [... ] > > | SP> Can you clarify in a new thread what is your problem in making the > Binding TLV _not_ MT aware in ISIS ? > > > > very simple explanation: > > > > Binding TLV only carries non-IP (e.g. MPLS labels, SRGB Indexes) > information > > at no point it carries information which directly affects IP forwarding > > state. > [Les:] This seems to me to be an abuse of terminology. The differentiation between "IP forwarding" and "MPLS forwarding" refers to how the forwarding logic implemented. What is being defined in the forms of the prefix-SID values advertised by the IGPs is how the topology specific instruction for a given prefix are passed to the forwarding plane. > > it propagates information about paths that are useable in a topology. > > > > in contrast all exisiting MT TLVs carry information which have direct > relevance > > to the generation of IP forwarding state (e.g. > > -MT-ISREACH affects metrics for IP routes, > > -MT-IPREACH affects advertisment and metrics for IP routes). > > > > what is not clear to me: > > why do we need to augment non-IP advertisments with extensions that > > are only relevant for IP path construction. - the intersection between > > the two seems zero to me. > > > ok, let's try to clarify the point then. > > ISIS is used to propagate information pertaining to prefixes and topology. > This information has been contextualized with the introduction of MT-ISIS. > This resulted into adding a MT-ID to each piece of topology advertised by > ISIS, including prefixes and adjacencies. > > SR introduced the Binding TLV which is also a piece of topology since it > represents a useable path in the topology. > > Therefore, it makes sense to me to add a MT-ID to the Binding TLV. > > Note also that the Binding TLV is used by the Mapping Server. There too, the > information propagated by the Mapping Server MAY be related to a > topology. An example is the deployment of IPv6 using MT-ISIS where all IPv6 > information (prefixes, adjacencies) are advertised within topology ID 2. It > wouldn't make sense to advertise IPv6/SID mappings without any topology > identifier. > > Therefore, to me, it is straightforward to enhance the Binding TLV with MT > capability. > > > > | SP> Also, would you also suggest to make it _not_ MT aware in OSPF ? In > such case we have to change the OSPF spec. > > > > same reasoning here: in case its not clear what/how to use MT in the > binding TLV for, we should remove it. [Les:] It is very clear in the case when mapping server is used to advertise prefix-SIDs. The only mistake that was made was that the earlier versions of the IS-IS draft overlooked the need for MTID in the binding TLV. Les > > > well, it looks to me the ospf wg clearly understood and acknowledged the > need of the MT-ID and I believe we did the right thing there. > > Now, I'd be interested to know other people opinion on this (from both isis > and spring wg's). > > s. > > > > > > /hannes > > > > | On May 21, 2015, at 3:26 PM, Hannes Gredler <[email protected]> > wrote: > > | > > | > hi stefano, > > | > > > | > On Thu, May 21, 2015 at 10:14:20AM +0000, Stefano Previdi (sprevidi) > wrote: > > | > [ ... ] > > | > | > | SP> why not creating a new thread explaining the issue and > including isis and spring wg ? > > | > | > > > | > | > HG> thats a good suggestion - please do it ! - we need to be > > | > | > HG> clear on the protocol requirements *before* adding > > | > | > HG> protocol extensions. > > | > | > > | > | SP> well, we agreed already at multiple occasions (last one was > > | > | SP> during the meeting in Dallas where you and me agreed to add MT > support to the Binding TLV) so we're inline with the process, right ? > > | > > > | > again this is meant as a friendly reminder to document (e.g. in > > | > some of the SPRING documents where you have the pen) how you > want to intend to use the MT extensions for the binding TLV. > > | > > > | > its not yet clear to me and i'd like to get an answer on this > > | > before progressing the protocol extensions in the ISIS and OSPF > working groups. > > | > > > | > /hannes > > | > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
