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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Uma -

> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Uma Chunduri
> Sent: Thursday, May 21, 2015 10:56 AM
> To: Stefano Previdi (sprevidi); Hannes Gredler
> Cc: [e-mail]; [e-mail] list
> Subject: Re: [Isis-wg] latest update of draft-ietf-isis-segment-routing-
> extensions
> 
> 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.

[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.
> Perhaps that part need to be addressed too/before?? Or it could be
> orthogonal..

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

   Les

> 
> --
> Uma C.
> 
> -----Original Message-----
> From: Isis-wg [mailto:[e-mail]] On Behalf Of Stefano Previdi
> (sprevidi)
> Sent: Thursday, May 21, 2015 9:44 AM
> To: Hannes Gredler
> Cc: [e-mail]; [e-mail] 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 <[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 ! - 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg