Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions

["Stefano Previdi (sprevidi)" <[e-mail]>]

<adding isis and spring mailing lists>

All, the thread below is about adding Multi Topology support in ISIS Segment Routing Extensions draft and, more precisely, in the Binding TLV. While we initially all agreed that we should add MT capability to the Binding TLV, it looks like we have some divergent opinions now. Please read the thread below and feel free to comment.


On May 20, 2015, at 6:20 PM, Hannes Gredler <[e-mail]> wrote:
> hi stefano,
> 
> On Mon, May 18, 2015 at 01:58:22PM +0000, Stefano Previdi (sprevidi) wrote:
> | On May 18, 2015, at 3:10 PM, Hannes Gredler <[e-mail]> wrote:
> | 
> | > hi les,
> | > 
> | > i am arguing that everything that we have standardized so far for MT (222, 235, 237)
> | > has clear semantics on how to calculate an *IP* path.
> | > 
> | > here comes the catch:
> | > the sole information we are advertising in the binding TLV is related to
> | > *non-IP* paths.
> | > 
> | > the questions i'd like to get some answers now are:
> | > 
> | > 1) why do we need an MT extension for something which is carrying "non-IP"
> | >   related information.
> | 
> | 
> | well, the mapping server carries mappings of prefixes to SIDs. This may or may not be associated to a topology, we can argue on this.
> 
> does this mean that you intend to have a multi-topology mapping server ?


one may want to have that, yes.


> does that imply that you have a multi-topology deployment of LDP ?


as far as I remember LDP, there are no advertisement in ISIS...


> | However, for the other info carried by the binding TLV, don't you have a FEC ? And the FEC isn't in the form of a IP reachability ?
> 
> a FEC describes an endpoint of an MPLS LSP.


which may be useable by a given topology and not by another... nothing weird to me.

Moreover, if IPv6 is deployed using MT-ISIS (topology identifier 2) it is obvious that all advertisements of IPv6 prefixes, mappings, etc are to be done within that topology (and not as part of all topologies).


> Advertisment of a FEC does not create IP forwarding state thats the fundamental difference;
> 
> | > 2) is there a description ("use-case") how the "non-IP" related information in the
> | >   binding TLV information does influence the path decision of an IP path.
> | > 
> | > since this is not an IS-IS related thing, but really SPRING relevant, i'd like
> | > also to see some open discussion on the SPRING list. 
> | 
> | 
> | why not creating a new thread explaining the issue and including isis and spring wg ?
> 
> thats a good suggestion  - please do it ! -
> 
> we need to be clear on the protocol requirements *before* adding
> protocol extensions.


well, we agreed already at multiple occasions (last one was 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 ? 

Obviously, I'm perfectly ok to re-spin the discussion.


Thanks.
s.





> 
> /hannes
> 
> 
> | > On Fri, May 15, 2015 at 03:05:19PM +0000, Les Ginsberg (ginsberg) wrote:
> | > | Hannes -
> | > | 
> | > | All we are doing here is providing Binding TLV w the same capabilities as we have for Prefix Reachability TLVs.
> | > | Are you arguing that we should NOT be able to advertise SIDs in TLVs 235 and 237?
> | > |
> | > | If not then I simply don't see why your question is relevant.
> | > | 
> | > |    Les
> | > | 
> | > | 
> | > | > -----Original Message-----
> | > | > From: Hannes Gredler [mailto:[e-mail]]
> | > | > Sent: Thursday, May 14, 2015 12:51 PM
> | > | > To: Les Ginsberg (ginsberg)
> | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil); Ahmed Bashandy
> | > | > (bashandy); Stephane Litkowski; [e-mail] IMT/OLN;
> | > | > Jeff Tantsura; Wim (Wim) Henderickx; Pushpasis Sarkar
> | > | > Subject: Re: latest update of draft-ietf-isis-segment-routing-extensions
> | > | > 
> | > | > les,
> | > | > 
> | > | > i do not think that i am confusing the two;
> | > | > 
> | > | > perhaps we can go with a practical example.
> | > | > 
> | > | > can you construct an example where you do NEED the MTID flavor of the
> | > | > binding SID.
> | > | > 
> | > | > /hannes
> | > | > 
> | > | > On Thu, May 07, 2015 at 03:48:38PM +0000, Les Ginsberg (ginsberg) wrote:
> | > | > | Hannes -
> | > | > |
> | > | > | You are confusing algorithm and topology - they are NOT the same.
> | > | > |
> | > | > | Topologies (RFC 5120) are formed based on the set of nodes and links
> | > | > which advertise support for a given MTID. On that topology we run (by
> | > | > default) the same SPF algorithm (algorithm 0). Obviously other algorithms
> | > | > could also be run.
> | > | > |
> | > | > | As I stated earlier, we have SR MT support via the IP/IPv6 Reachability TLVs
> | > | > - but we overlooked this in the Binding TLV - we have now corrected that
> | > | > oversight.
> | > | > |
> | > | > | Frankly, I think all of the questions you are raising are because of a
> | > | > misunderstanding on your part.
> | > | > |
> | > | > |    Les
> | > | > |
> | > | > | > -----Original Message-----
> | > | > | > From: Hannes Gredler [mailto:[e-mail]]
> | > | > | > Sent: Thursday, May 07, 2015 5:07 AM
> | > | > | > To: Les Ginsberg (ginsberg)
> | > | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil); Ahmed
> | > | > | > Bashandy (bashandy); Stephane Litkowski; [e-mail]
> | > | > | > IMT/OLN; Jeff Tantsura; Wim (Wim) Henderickx; Pushpasis Sarkar
> | > | > | > Subject: Re: latest update of
> | > | > | > draft-ietf-isis-segment-routing-extensions
> | > | > | >
> | > | > | > hi les,
> | > | > | >
> | > | > | > understood: where is the use-case for MT enabled Binding TLVs and
> | > | > | > what is the Path calculation algorithm that is being used for
> | > | > | > attaching the information found in MT Binding TLVs.
> | > | > | >
> | > | > | > So far the major function that has been implemented using Binding
> | > | > | > TLVs has been the mapping server. - we have a doucment for that.
> | > | > | >
> | > | > | > where is a similar decription for the MT Binding TLV (e.g. "i want
> | > | > | > to do MT- LDP Mapping server")
> | > | > | >
> | > | > | > /hannes
> | > | > | >
> | > | > | > On Wed, May 06, 2015 at 05:07:51PM +0000, Les Ginsberg (ginsberg)
> | > | > wrote:
> | > | > | > | Hannes -
> | > | > | > |
> | > | > | > | If we support multiple topologies that means we can have different
> | > | > | > | paths
> | > | > | > in the forwarding plane for the same prefix in each topology. If we
> | > | > | > are using an MPLS dataplane that means we need different labels for
> | > | > | > the same prefix in each topology. (How packets are classified into a
> | > | > | > given topology is out of scope of this discussion). I therefore need
> | > | > | > the ability to install topology specific labels in the forwarding
> | > | > | > plane - which means I need to be able to advertise topology specific
> | > | > | > SIDs. As I mentioned in my earlier reply, we have the ability to do
> | > | > | > that in MT Reachability advertisements - but currently we did not
> | > | > | > include the same capability in the Binding TLV. The latest version of the
> | > | > draft corrects that omission.
> | > | > | > |
> | > | > | > |   Les
> | > | > | > |
> | > | > | > |
> | > | > | > | > -----Original Message-----
> | > | > | > | > From: Hannes Gredler [mailto:[e-mail]]
> | > | > | > | > Sent: Wednesday, May 06, 2015 9:52 AM
> | > | > | > | > To: Stefano Previdi (sprevidi)
> | > | > | > | > Cc: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy);
> | > | > | > | > Stephane Litkowski; [e-mail] IMT/OLN; Jeff
> | > | > | > | > Tantsura; Wim (Wim) Henderickx; Les Ginsberg (ginsberg);
> | > | > | > | > Pushpasis Sarkar
> | > | > | > | > Subject: Re: latest update of
> | > | > | > | > draft-ietf-isis-segment-routing-extensions
> | > | > | > | >
> | > | > | > | > On Wed, May 06, 2015 at 01:32:23PM +0000, Stefano Previdi
> | > | > | > | > (sprevidi)
> | > | > | > wrote:
> | > | > | > | > | On May 5, 2015, at 7:52 AM, Hannes Gredler
> | > | > | > | > | <[e-mail]>
> | > | > | > wrote:
> | > | > | > | > | > hi stefano, et al,
> | > | > | > | > | >
> | > | > | > | > | > i cannot get my head around the need/use-case for MTID for
> | > | > | > | > | > binding
> | > | > | > | > TLVs.
> | > | > | > | > | >
> | > | > | > | > | > my naive view is that MT information is generally used to
> | > | > | > | > | > SPF computation for supporting non-congurent SPT trees.
> | > | > | > | > | >
> | > | > | > | > | > since SPT does not use any of the binding TLV information today:
> | > | > | > | > | > for what use-case would one need the MT marker ?
> | > | > | > | > | >
> | > | > | > | > | > i seem to recall that this was brought up by E/// engineers,
> | > | > | > | > | > so maybe jeff et al can highlight a usecase where MT for
> | > | > | > | > | > binding TLV might be useful.
> | > | > | > | > |
> | > | > | > | > |
> | > | > | > | > | well, I presume a MT implementation would also like to use paths
> | > | > (i.e.:
> | > | > | > | > binding TLVs) associated to a given topology... just guessing here.
> | > | > | > | >
> | > | > | > | > that was my initial guess as well - the catch with that is that
> | > | > | > | > contents of the binding TLV are not yet explored in any of the
> | > | > | > | > routw-calculation pieces (SPF) we have ...
> | > | > | > | >
> | > | > | > | > so whats the point on making them MT aware ?
> | > | > | > | >
> | > | > | > | > | >
> | > | > | > | > | > On Mon, Apr 27, 2015 at 03:10:47PM +0000, Stefano Previdi
> | > | > | > | > | > (sprevidi)
> | > | > | > | > wrote:
> | > | > | > | > | > | . Introduced a new top level TLV: MT-Binding TLV.
> | > | > | > | > | > | Originally we thought we could just add a MTID subTLV to
> | > | > | > | > | > | the existing
> | > | > | > | > Binding TLV however, this may cause interop problems with
> | > | > | > | > implementations not supporting the MTID and therefore ignoring
> | > | > | > | > it (which would have the effect of merging topologies).
> | > | > | > | > |
> |