Subject: Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 21 May 2015 13:55:07 +0000

Hannes,

it's getting difficult to follow your reasoning because you switch from protocol details concerns (which have been addressed) to ietf procedures...

Can you clarify in a new thread what is your problem in making the Binding TLV _not_ MT aware in ISIS ?

Also, would you also suggest to make it _not_ MT aware in OSPF ? In such case we have to change the OSPF spec.

s.

On May 21, 2015, at 3:26 PM, Hannes Gredler <[email-masked]> 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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 21 May 2015 10:14:20 +0000

<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 <[email-masked]> 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 <[email-masked]> 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:[email-masked]]
> | > | > Sent: Thursday, May 14, 2015 12:51 PM
> | > | > To: Les Ginsberg (ginsberg)
> | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil); Ahmed Bashandy
> | > | > (bashandy); Stephane Litkowski; [email-masked] 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:[email-masked]]
> | > | > | > Sent: Thursday, May 07, 2015 5:07 AM
> | > | > | > To: Les Ginsberg (ginsberg)
> | > | > | > Cc: Stefano Previdi (sprevidi); Clarence Filsfils (cfilsfil); Ahmed
> | > | > | > Bashandy (bashandy); Stephane Litkowski; [email-masked]
> | > | > | > 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:[email-masked]]
> | > | > | > | > Sent: Wednesday, May 06, 2015 9:52 AM
> | > | > | > | > To: Stefano Previdi (sprevidi)
> | > | > | > | > Cc: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy);
> | > | > | > | > Stephane Litkowski; [email-masked] 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
> | > | > | > | > | <[email-masked]>
> | > | > | > 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).
> | > | > | > | > |
> |

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 21 May 2015 15:26:47 +0200

hi stefano,

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 21 May 2015 16:34:26 +0200

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. 

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.

| 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.

/hannes

| On May 21, 2015, at 3:26 PM, Hannes Gredler <[email-masked]> 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
|

---

From: <[email-masked]>
Date: Thu, 21 May 2015 15:14:57 +0000

I am out dsl 

-----Message d'origine-----
De : spring [mailto:[email-masked]] De la part de Hannes Gredler
Envoyé : jeudi 21 mai 2015 16:34
À : Stefano Previdi (sprevidi)
Cc : [email-masked]; [email-masked] list
Objet : Re: [spring] latest update of draft-ietf-isis-segment-routing-extensions

hi stefano,

very simple explanation:

 
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.

/hannes

| On May 21, 2015, at 3:26 PM, Hannes Gredler <[email-masked]> 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 protocol 
| > | > HG> 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
| 

_______________________________________________
spring mailing list
[email-masked]
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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 21 May 2015 16:43:48 +0000

Hi Hannes,

>   at no point it carries information which directly affects IP forwarding state. 

it propagates information about paths that are useable in a topology.

> 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.

> 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.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 21 May 2015 17:56:03 +0000

Hi Stefano,

Mostly agree but not clear on how we this. Hopefully and as I understood (may be wrong) this is one of the questions Hannes could be asking.

Any ways -
>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.

If we do that it *may*  become default topology (RFC 5308) and which  may not be what is intended.

But my unanswered question in this context is there is no topology information when we try to stitch the LDP path in mapping server context.
Perhaps that part need to be addressed too/before?? Or it could be orthogonal..

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Thursday, May 21, 2015 9:44 AM
To: Hannes Gredler
Cc: [email-masked]; [email-masked] list
Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions

Hi Hannes,

> 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.

s.

> | > | > HG> clear on the protocol requirements *before* adding 
> | > 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-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 21 May 2015 18:14:32 +0000

Hi Stefano,

As much I understand the LDP mapping server functionality the
Label-Binding TLV shall be used to map a SR Node-SID-Index with a FEC
originated by SR-incapable node.

Now in regular SPRING domain a SR-capable node does not generate one
Node-SID-Index for a given node address (loopback) per topology. The index
is still one for the address across all topologies. Do you suggest that
there should be a Node-SID-Index configured for every topology? If not,
then I don¹t see a need of mapping different node-sid-index for the same
prefix under different topology.

Thanks
-Pushpasis

On 5/21/15, 10:13 PM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>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.
>
>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.
>
>> | SP> Also, would you also suggest to make it _not_ MT aware in OSPF ?
>>In such case we have to change the OSPF spec.
>> 
>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.
>
>>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 ?
>> | > 
>>some of the SPRING documents
>>before progressing the

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 22 May 2015 19:44:03 +0000

I see this -

As today binding TLVs can be used for advertising both 

a. prefixes (for mapping server functionality on behalf of unsupported SR nodes)  as well as to 
b. advertise paths/ERO/Backup-EROs/Etc...

1. We *may* need MT ID if we are trying to achieve #a above (again doing MT for e.g., even for V4 only with LDP is a different question though). 
2. We don't need MT ID for #b above.

This need to be clarified IMO, in the draft.

--
Uma C.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Thursday, May 21, 2015 9:44 AM
To: Hannes Gredler
Cc: [email-masked]; [email-masked] list
Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-extensions

Hi Hannes,

s.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 23 May 2015 05:34:09 +0000

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.

> >   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. 

> 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.
> 
> 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.
> 
> > | SP> Also, would you also suggest to make it _not_ MT aware in OSPF ? In
> such case we have to change the OSPF spec.
> >

[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

> > | > | 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 ?
> > | >
> > | > some of the SPRING documents where you have the pen) how you
> want to intend to use the MT extensions for the binding TLV.
> > | >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 23 May 2015 05:53:31 +0000

Uma -

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma Chunduri
> Sent: Thursday, May 21, 2015 10:56 AM
> To: Stefano Previdi (sprevidi); Hannes Gredler
> Mostly agree but not clear on how we this. Hopefully and as I understood
> (may be wrong) this is one of the questions Hannes could be asking.
> 
> Any ways -
> >An example is the deployment of IPv6 using MT-ISIS where all IPv6
> information (prefixes, adjacencies) are advertised within topology ID 2.

[Les:] This isn't a logical conclusion - what is being done actually makes what you suggest LESS likely.
There are two ways to support IPv6 Reachability advertisements in IS-IS today:

1)RFC 5308 (TLV 236)

This is often called "single topology IPv6" because the MTID for all advertisements of this type is implied to be 0 - which means the paths to IPv6 destinations are calculated on a single topology which is shared with IPv4 (TLV 135).

2)RFC 5120 (TLV 237)

This is often called "multitopology IPv6" because the IPv6 Reachability advertisements are explicitly identified with a separate and potentially incongruent topology (w respect to topology #0)

There are multiple implementations of both forms of IPv6 support deployed today.

Making the Binding TLV have MTID support aligns it with the existing support in IS-IS today. And it means that Binding TLV can now be used to support BOTH RFC 5308 and RFC 5120 based deployments of IPv6.

RFC 5120 technology can be (and has been) used as a means of supporting multiple topologies for a given address family - as well as multiple topologies each of which supports multiple address families. It is wrong to think we are limited to "one IPv4 topology" and "one IPv6 topology" just because that is the most common use case today. If one runs standard SPF on two incongruent topologies clearly topology unique paths for the same destination can result - and prefix-SID advertisements (whether in prefix reachability TLVs or Binding TLV) need to be able to support this.

> 
> But my unanswered question in this context is there is no topology
> information when we try to stitch the LDP path in mapping server context.

[Les:] Please see my other reply in this thread.

   Les