Subject: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Fri, 3 Mar 2017 14:55:39 +0000

Heads-up… Happy to learn feedback and comments.

This draft is short and defines the attribute to use for BGP-LS to expose a 
node RLD "Readable Label Depth" to a centralised controller (PCE/SDN).

G/

On 03/03/2017, 14:21, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    has been successfully submitted by Gunter Van de Velde and posted to the
    IETF repository.
    
    Name:		draft-vandevelde-idr-bgp-ls-segment-routing-rld
    Revision:	01
    Title:		Signalling RLD using BGP-LS
    Document date:	2017-03-03
    Group:		Individual Submission
    Pages:		5
    URL:            https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/
    Htmlized:       https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
    
    Abstract:
       This document defines the attribute to use for BGP-LS to expose a
       node RLD "Readable Label Depth" to a centralised controller (PCE/
       SDN).

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 3 Mar 2017 15:54:19 -0500

Gunter,

> node RLD "Readable Label Depth" to a centralised controller (PCE/SDN).

This seems like a good idea.  I was not aware of the work in the other area,
so I believe my primary commment needs to go elsewhere as well:

While it's true that a given node may have a given limit on its readable
depth, this may potentially vary on a per interface basis.  What's the
intent, if any, to accommodate something beyond the least common
denominator?

Editorial nit, your references point to the ospf document twice.

-- Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 03 Mar 2017 12:51:59 -0800

Jeff,

This is the approach taken in MSD (Max SID Depth )drafts (IGPs/BGP), both node and link values can be signaled.

Cheers,
Jeff

On 3/3/17, 12:54, "Idr on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Gunter,

    

    -- Jeff
    
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: Gunter Van De Velde <[email-masked]>
Date: Fri, 03 Mar 2017 22:24:42 +0100

Yes, Indeed we already had a -02 version nearly ready with mentioning Link also in addition to node.
When i was writing the text i was in doubt to add it or not, but now indeed i think its best to add.

G/

> On 3 Mar 2017, at 21:54, Jeffrey Haas <[email-masked]> wrote:
> 
> Gunter,
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 4 Mar 2017 07:35:36 +0100

Hey Gunter,

Good proposal however why do you only think about labels ?

Seriously if this is to move fwd let's add ability to signal also following
elements:

* ability to punt SR-MPLS to local CPU (slow path) when not handled in
hardware (per node basis)

* add signalling for number of SRv6 SRHs supported per node/per LC

* add signalling for depth per SRH and total of SIDs supported per node/per
LC

* signal ability to punt to slow path or not for longer then support SRH
stack or number of SIDs in each SRH structure.

Cheers,
Robert.

On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <
[email-masked]> wrote:

>     URL:            https://www.ietf.org/internet-
> drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
>     Status:         https://datatracker.ietf.org/
> doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/
>     Htmlized:       https://tools.ietf.org/html/
> draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
>     Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
>
>     Abstract:

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 04 Mar 2017 08:40:57 +0000

Robert,

That's done in MSD drafts.
In the recently published isis draft we have also introduced MSD type flag
that would be used to signal different types of SID's: recirculated labels,
EL's, etc

Cheers,
Jeff

On Fri, Mar 3, 2017 at 22:35 Robert Raszuk <[email-masked]> wrote:

Hey Gunter,

Cheers,
Robert.

G/

On 03/03/2017, 14:21, "[email-masked]" <[email-masked]>
wrote:

    A new version of I-D,
draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    has been successfully submitted by Gunter Van de Velde and posted to the
    IETF repository.

    Name:               draft-vandevelde-idr-bgp-ls-segment-routing-rld
    Revision:   01
    Title:              Signalling RLD using BGP-LS
    Document date:      2017-03-03
    Group:              Individual Submission
    Pages:              5
    URL:
https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
    Status:
https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/
    Htmlized:
https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01
    Diff:
https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-bgp-ls-segment-routing-rld-01

    Abstract:

    Please note that it may take a couple of minutes from the time of
submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 4 Mar 2017 09:54:12 +0100

Jeff,

I am talking about max supported depth.

If this is already addressed elsewhere (which I doubt) I am not sure why
this draft would be needed at all then.

But if it has value let's make it complete.

Best,
R.

On Mar 4, 2017 09:41, "Jeff Tantsura" <[email-masked]> wrote:

> Seriously if this is to move fwd let's add ability to signal also
> following elements:
>
> * add signalling for depth per SRH and total of SIDs supported per
> node/per LC
>

---

From: Gunter Van De Velde <[email-masked]>
Date: Sat, 04 Mar 2017 11:01:33 +0100

When i was looking the MSD draft is looking at “How Many labels can device (node/link) impose”.
(look at introduction in section 1 as it is explicitly written in the text)

The RLD draft is about “How many labels a device (node/link) can read”

Even for the IGPs there is are different documents in either OSPF or ISIS WG:
OSPF MSD: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-00 <https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-msd-00>
OSPF ELC/RLD: https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-04 <https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-04>

ISIS MSD: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-02 <https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-02>
ISIS ELC/RLD: https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-02 <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-02>

BGP MSD: https://tools.ietf.org/html/draft-tantsura-bgp-ls-segment-routing-msd-02 <https://tools.ietf.org/html/draft-tantsura-bgp-ls-segment-routing-msd-02>
BGP ELC/RLD: Was MIA … so now there is https://trac.tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 <https://trac.tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01>

Hence i assumed that there is sense for two drafts in IDR to be in sync with the IGP capabilities … one to make BGP-LS in alignment with the IGPs for MSD and one to make BGP-LS in alignment with ELC

@Robert, I do believe those data-points are of interrest to a network SDN controller. I am not convinced they all belong in the same document.
I think that on shorter term there is need that the IGP LSDB can be exported to BGP-LS because right now that is not possible for ISIS-ELC or OSPF-ELC. 
My understanding is it is potentially worth having a draft on signalling new functionality beyond the capability to signal it in the IGPs… It is an important deviation from anything that was done before with BGP-LS because main purpose has been to allow the export of IGP LSDB into BGP-LS

G/

> On 4 Mar 2017, at 09:54, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff,
> 
> If this is already addressed elsewhere (which I doubt) I am not sure why this draft would be needed at all then.
> 
> On Mar 4, 2017 09:41, "Jeff Tantsura" <[email-masked] <mailto:[email-masked]>> wrote:
> Robert,
> 
> In the recently published isis draft we have also introduced MSD type flag that would be used to signal different types of SID's: recirculated labels, EL's, etc
> 
> Cheers,
> Jeff
> 
> On Fri, Mar 3, 2017 at 22:35 Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> Hey Gunter,
> 
> Seriously if this is to move fwd let's add ability to signal also following elements:
> 
> * ability to punt SR-MPLS to local CPU (slow path) when not handled in hardware (per node basis)
> 
> * add signalling for depth per SRH and total of SIDs supported per node/per LC
> 
> * signal ability to punt to slow path or not for longer then support SRH stack or number of SIDs in each SRH structure.
> 
> Cheers,
> Robert.
> 
> 
> On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <[email-masked] <mailto:[email-masked]>> wrote:
> On 03/03/2017, 14:21, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     URL:            https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt <https://www.ietf.org/internet-drafts/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt>
>     Status:         https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/ <https://datatracker.ietf.org/doc/draft-vandevelde-idr-bgp-ls-segment-routing-rld/>
>     Htmlized:       https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 <https://tools.ietf.org/html/draft-vandevelde-idr-bgp-ls-segment-routing-rld-01>
>     Diff:           https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-bgp-ls-segment-routing-rld-01 <https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-bgp-ls-segment-routing-rld-01>
> 
>     Abstract:
>     until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
>     The IETF Secretariat
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 4 Mar 2017 15:24:06 +0100

Jeff,

MSD drafts (yours invluded) talks about labels while MSD as such seems to
be defined as maximum SID depth.

In SRv6 SID is *NOT* a label. So why not to define MSD properly across all
SR scenarios?

Are we going to have now new zoo of drafts now defining MSD for SRv6 vs
current docs just defining MSD for SR-MPLS ?

Cheers,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 4 Mar 2017 16:21:13 -0800

Robert,

Please take a look at 02 isis draft published yesterday, we have added type flag that defines the type of a SID and could be used with v6 dataplane.
The limitations wrt label operations are well understood across both custom and merchant  silicon and from use case prospective had to be addressed first.
V6 dataplane will be added.

Please let me know if this answers your questions and addresses concerns.

Regards,
Jeff

> On Mar 4, 2017, at 06:24, Robert Raszuk <[email-masked]> wrote:
> 
> Jeff,
> 
> MSD drafts (yours invluded) talks about labels while MSD as such seems to be defined as maximum SID depth.
> 
> In SRv6 SID is *NOT* a label. So why not to define MSD properly across all SR scenarios?
> 
> Are we going to have now new zoo of drafts now defining MSD for SRv6 vs current docs just defining MSD for SR-MPLS ?
> 
> Cheers,
> R.
> 
> 
> 
>> On Fri, Mar 3, 2017 at 3:55 PM, Van De Velde, Gunter (Nokia - BE) <[email-masked]> wrote: