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

Hope all is well with all.

I'll be happy to discuss in Montreal. Between now and then i am on vscation, so no new text from my side. Lsts better discuss first at IETF102.

G/

Gunter Van de Velde

On Fri, Jun 29, 2018 at 8:58 PM +0200, "Susan Hares" <shares@ndzh.com> wrote:

Stephane, Gunter, Ketan, Les, and Jeff:

Are you going to settle on option 2?  Will we be seeing drafts with this
change in this revision? 

Sue Hares 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of
stephane.litkowski@orange.com
Sent: Wednesday, June 13, 2018 6:05 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp); Ketan Talaulikar (ketant);
idr@ietf.org; lsr@ietf.org; spring@ietf.org
Subject: Re: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi,

As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD
means that the node is defacto ELC (so advertising ELC separately is not
necessary):

" The Entropy Readable Label Depth (ERLD) is defined as the number of
   labels a router can both:

   a.  Read in an MPLS packet received on its incoming interface(s)
       (starting from the top of the stack).

   b.  Use in its load-balancing function.

   The ERLD means that the router will perform load-balancing using the
   EL label if the EL is placed within the ERLD first labels.
"

"
To advertise an ERLD value, a SPRING router:

   o  MUST be entropy label capable and, as a consequence, MUST apply
      the dataplane procedures defined in [RFC6790].

   o  MUST be able to read an ELI/EL which is located within its ERLD
      value.

   o  MUST take into account this EL in its load-balancing function.
"

Brgds,

-----Original Message-----
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Van De Velde, Gunter
(Nokia - BE/Antwerp)
Sent: Wednesday, June 13, 2018 11:10
To: Ketan Talaulikar (ketant); idr@ietf.org; lsr@ietf.org; spring@ietf.org
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are
signaled for ISIS, OSPF and BGP-LS. 

If the WG's can manage to agree upon a decision (option1/2/3 or 4), then
next, have a look into how to encode the TLV so that we have a clean
technological solution space.

G/

-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
Sent: Wednesday, June 13, 2018 10:45
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
; idr@ietf.org; lsr@ietf.org; spring@ietf.org
Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)

Hi Gunter,

In that case, I concur with you that option (2) is better than the others.
My only difference in opinion is that ERLD not have its own separate TLV but
instead get advertised as a new MSD sub-type - it is just a different
encoding.

Thanks,
Ketan

-----Original Message-----
From: Van De Velde, Gunter (Nokia - BE/Antwerp)

Sent: 13 June 2018 13:55
To: Ketan Talaulikar (ketant) ; idr@ietf.org;
lsr@ietf.org; spring@ietf.org
Subject: RE: 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:ketant@cisco.com]
Sent: Wednesday, June 13, 2018 08:05
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
; idr@ietf.org; lsr@ietf.org; spring@ietf.org
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  On Behalf Of Van De Velde, Gunter (Nokia -
BE/Antwerp)
Sent: 12 June 2018 19:28
To: idr@ietf.org; lsr@ietf.org; spring@ietf.org
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:idr-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Tuesday, June 12, 2018 15:25
To: i-d-announce@ietf.org
Cc: idr@ietf.org
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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

____________________________________________________________________________
_____________________________________________

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.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr