Re: [Idr] [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

[" 徐小虎(义先) " <[e-mail]>]

If I understand it correctly, according to the ELC concept originated from RFC6790 (see below), the ELC itself doesn't mean the ELC originator should be capable of using the EL for load-balancing. It just means the egress of the tunnel advertising that capability is capable of popping the ELI/EI.

5.  Signaling for Entropy Labels

   An egress LSR Y can signal to ingress LSR(s) its ability to process
   entropy labels (henceforth called "Entropy Label Capability" or ELC)
   on a given tunnel.  In particular, even if Y signals an implicit null
   label, indicating that PHP is to be performed, Y MUST be prepared to
   pop the ELI and EL.

The ELC is only required for tunnel egress nodes. The EL-based load-balancing capability is only required for intermediate nodes and tunnel ingress nodes. In other words, the ERLD doesn't equal to the combination of ELC and RLD. RFC6790 allows ingress nodes to insert an ELI/EL pair as long as the tunnel egress has advertised the ELC. In the case where SR-IGP is just used as a replacement of LDP, why should the egress node be required to advertise its RLD in addition to the ELC before the ingress being able to impose an ELI/EL? Furthermore, although the major use case of RLD is entropy label-based load-balancing at the current stage, nobody can promise this is the only use case of RLD as well in the future. In a word, it seems better to advertise the RLD and ELC independently from the flexibility perspective.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
Send Time:2018年6月13日(星期三) 16:25
To:Ketan Talaulikar (ketant) <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject:Re: [spring] Signalling ERLD (ISIS, OSPF and BGP-LS)

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic motivation.

The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is available, then ELC can be implicitly assumed. No pragmatic reason to signal separately, as it just make things more complex then should be. 

>From a holistic perspective having something similar, yet different, in both IGP and BGP-LS encoding 
seems to make little sense and only bring confusion (router/controller implementers and network operators). 

The ways to address this in IGP and BGP-LS going forward:
1) do nothing and leave all as it is (it has potential to create massive confusion) 
2) only signal ERLD TLV in IGP and BGP
3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of ELC TLV compared to option (2)) 
4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more complex as option (2))

I believe that option (2) is the best option:
* it bring the needed readable label depth value to operators 
* most simple solution for implementers (routers and controller)  
* easy to understand with no confusion
* is compliant with draft-ietf-mpls-spring-entropy-label-10

G/

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

The difference in IGP signalling seems to be because the ELC is a capability which is advertised differently than ERLD which is a limit. Are you saying that ELC does not have value by itself without the ERLD?

IMHO it makes sense to retain ELC as capability of the router (as specified in the IGP specs) and position ERLD as a MSD sub-type for indicating the limit. This way we have the flexibility of signalling ERLD both per node and per ingress link/LC level.

Thanks,
Ketan

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: 12 June 2018 19:28
To: [e-mail]; [e-mail]; [e-mail]
Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

In LSR WG the following drafts document the signaling of ELC and RLD:
* draft-ietf-ospf-mpls-elc
* draft-ietf-isis-mpls-elc

When exporting this information using BGP-LS encoding to a controller, there is need for BGP-LS extension by means of new TLVs.

BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is signaling individually ELC and RLD

I was working upon the IANA section, and discovered some inconsistency that should be addressed:
* Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
* What are the plans to request IANA code points for these drafts?
* (E)RLD seems to have meaning only from NODE perspective, (I assume that LINK ERLD is not of any value at all, is that a correct assumption?)

G/


-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, June 12, 2018 15:25
To: [e-mail]
Cc: [e-mail]
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : Signalling ERLD using BGP-LS
        Authors         : Gunter Van de Velde
                          Wim Henderickx
                          Matthew Bocci
                          Keyur Patel
 Filename        : draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
 Pages           : 6
 Date            : 2018-06-12

Abstract:
   This document defines the attribute encoding to use for BGP-LS to
   expose ERLD "Entropy capable Readable Label Depth" from a node to a
   centralised controller (PCE/SDN).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring