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

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 13 June 2018 21:09 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0000130DFC; Wed, 13 Jun 2018 14:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2nRXODJTfM0; Wed, 13 Jun 2018 14:09:27 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D65130DF1; Wed, 13 Jun 2018 14:09:26 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id z1-v6so1848559pgv.12; Wed, 13 Jun 2018 14:09:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=0a3eHBeBJZ1K9UGD5A6/t1Wf/DfcwsSb9/H9nGTOWqg=; b=Ntxtu6H7xmm+xH5hVK+uk1xxMAnNXV9UvSBZ+A/fb5ka7VeD10fI3/2+L7C9TZPjMX 86w/bBAnBKtODpG50pkNc8T5e9KVItmPFU/Ap9roVnfeo3d4nj5vBOGsc/kFKjjRbHLU Aw+53+CbwtJpDDzG2aUoFFM6jsOL1cb96MNN+cOw4W7FD28vtlg/t0wmqMLStdp5ajV4 5+OyI5W0utioGEQih488BA0f8C4PK+n8TmnquMnyU0Zn/G6iAwNmz7ZJaYJp12G3Vor6 hmuxClkKhLXd+xVusEjGT8RWCiXrxwgCwsXg4rs0ZipzhBgG9YLOvpamCuCIIlZWYfqn /zyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=0a3eHBeBJZ1K9UGD5A6/t1Wf/DfcwsSb9/H9nGTOWqg=; b=cZwAHGBuVSqviTRMigwfIyaeTPNDXsvxBbAvplEjZf51g3tpL9rIiZSX/HfKDirqZD 4jeBSBGBfTeDnYIJFMA94qBkgl2swLGQmAnwajtggFnBhpefSmwBalFBfSnnXQInELCx OaiFNi7XQh48QKVVfpPwTlogSDkdijd6neCPJAkbi1RYEFA7C2NH5OfCz8Ie2hn5vLpT K2e3NOUJktXfBSfpACFs8mNvwJ8gfGQLISCfG3LF/Jiqc31ugL579O5M/Ksix6c6QLyZ L41PDL9JB9bJzT9Y/oC6qU69C+451VZWvxtoQ9RChUTVIX6NyaBaS8Pdbi+eKT96wet9 rJwA==
X-Gm-Message-State: APt69E1JWMMByD2kRqzKrRpUlkmJYKcx0srD+kSPKU5JWe0SoyL/tjsF B3uvwUriu/ueYrU1CpNr3D4pxw==
X-Google-Smtp-Source: ADUXVKLCjvRSUrLAZlZveGKurzy3LuMRYrZfL6FXzhz4GxTF6TP4mF3BjHAbPYqy5n8xUITYJAsPgw==
X-Received: by 2002:a63:7b03:: with SMTP id w3-v6mr5536749pgc.52.1528924166418; Wed, 13 Jun 2018 14:09:26 -0700 (PDT)
Received: from [10.11.13.172] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id n10-v6sm6558948pfb.27.2018.06.13.14.09.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 14:09:25 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Wed, 13 Jun 2018 14:09:22 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Message-ID: <18BFE8FF-4DEA-43A2-9262-8649D1A1692D@gmail.com>
Thread-Topic: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8DaHcswGfN0rVe5U5PPmmK6Jd8M>
Subject: Re: [Lsr] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 21:09:30 -0000

Gunter,

I have nothing to add to Les' comments, 100% agree.

Cheers,
Jeff
On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)" <idr-bounces@ietf.org on behalf of ginsberg=40cisco.com@dmarc.ietf.org> wrote:

    Gunter -
    
    I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD.
    This is the unified framework that the MSD advertisement has been designed to support.
    
    The following documents provide a unified definition of this mechanism:
    
    https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
    https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
    https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/
    
    (The last one needs a refresh.)
    
    If we can update the related ERLD documents to align I think we will have an excellent solution.
    
     (Note: in the case of https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ perhaps that can be combined with https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/  - but I leave that to the respective authors to work out.)
    
       Les
    
    
    
    > -----Original Message-----
    > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Van De Velde, Gunter (Nokia
    > - BE/Antwerp)
    > Sent: Wednesday, June 13, 2018 2:10 AM
    > To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; 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)
    > <gunter.van_de_velde@nokia.com>om>; 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)
    > <gunter.van_de_velde@nokia.com>
    > Sent: 13 June 2018 13:55
    > To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; 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)
    > <gunter.van_de_velde@nokia.com>om>; 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 <idr-bounces@ietf.org> 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
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr