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

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

Hi Hannes,

On May 21, 2015, at 4:34 PM, Hannes Gredler <[e-mail]> 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. 


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.


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 <[e-mail]> 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 ! - 
> | > | > HG> we need to be clear on the protocol requirements *before* adding
> | > | > HG> protocol extensions.
> | > | 
> | > | SP> well, we agreed already at multiple occasions (last one was during the meeting in Dallas
> | > | SP> 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
> |