Re: [Lsr] IGP TE Metric Extensions

stefano previdi <stefano@previdi.net> Tue, 05 June 2018 12:42 UTC

Return-Path: <stefano@previdi.net>
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 0BCE4131064 for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 05:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.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 Z2ptybnoDQRR for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 05:42:37 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 A23E1131067 for <lsr@ietf.org>; Tue, 5 Jun 2018 05:42:36 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id k16-v6so2289180wro.0 for <lsr@ietf.org>; Tue, 05 Jun 2018 05:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zoMQBnMEvOIBg2OsUVrDlwLTul0Wl71S17r6zD2cQl0=; b=LBjeh3FKB/8Fy2Mj/G0zCnoIXdN3TUZyvJq9w4RaehULGH3r2hFlJOKNRc/Wp4Etb2 0T7eYktggWM30fZ2TZwdJRkm60UO2RbXiCRR4qhSLby/ONhgC8/q23toTgcdR3lB7rRG yk58U1edw6k3S6zud+qq6TU1EHCu2pG4rJOfjGC72f96ymFTl7uehtxpyFsDgD9Temv9 wN9zvJyuggaBPLWnX1bRkZWxqfGkVKHmWndXdk9AfRfPxJH0G2/QCFeBYF5/7skHT+Xe FaOcfElPI+Bo48ukkqQD0RkzAAqBLOW69OefCp27cqpLoR2gS55E/gCtpmnGbaIG+lrz 14jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zoMQBnMEvOIBg2OsUVrDlwLTul0Wl71S17r6zD2cQl0=; b=Df/k3yMtV1ZOEtf7mSukIQx2hqBoU6mSg6Ci5d8tugDa5RFyUdWRslDpsB6rD4K0uN gQB6ArWlrxJ/KHjr0bBK1JlHKtnItlIo5KOBE5kLEmt9iCFENZVJKZmJL+3bWq0J1M1H 2vW3ARV+fbmMnNeQLHAWzDJ/TiUm0Rb/u8UAVNgne8IHzVdfMFii0DA3VzjBd5WdEtNz vuaSUzeebOgmIMWB8P25bBlAfQw+npsolfN1F50PtvQVOU/aLwRJ8pIVqOrEedrMtXFL qJtBA/u02lrdsOwQ79xq8F1tu4IeBhzRe4WFPkhvB7Ia21Wrskp14dfka4uAbqtVkQnX PfWQ==
X-Gm-Message-State: ALKqPwduAgW5Y7U8SEyQPxyA8/TRa/pJDUdrmhxlceKq5NKC2xcxRXUx Bb40OFP6kl22OirhcUS7GztoTA==
X-Google-Smtp-Source: ADUXVKKjguV2vDvbseH0e2fypcPTNl8AYdrDnh2vKvVZg+Hzqt2spgbaozk1p0rwXTMn5yPDQW7qFQ==
X-Received: by 2002:adf:e6d0:: with SMTP id y16-v6mr21084846wrm.35.1528202555162; Tue, 05 Jun 2018 05:42:35 -0700 (PDT)
Received: from [192.168.43.78] ([5.170.104.68]) by smtp.gmail.com with ESMTPSA id w2-v6sm22735250wrn.77.2018.06.05.05.42.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jun 2018 05:42:33 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: text/plain; charset=utf-8
From: stefano previdi <stefano@previdi.net>
In-Reply-To: <CAKz0y8whN=KSR45V6kZ=TvCNwx=BG00v2xz=Dan2yO-jhbEnSg@mail.gmail.com>
Date: Tue, 5 Jun 2018 14:42:31 +0200
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31EBB6D4-E267-45DE-A500-6277E85A337D@previdi.net>
References: <CAKz0y8zTE_ZkN6_MdXF0hxoRJG81TpBJAk9vtvjYmzWpY6=FHw@mail.gmail.com> <B33C32CE-0EDA-41C9-B1A6-62E8DBA0E7B2@gmail.com> <CAKz0y8yGWg5=ZGyTcWiRSJQFKF7brZddnpVhMPk6GwmhhQr3Uw@mail.gmail.com> <CAJp-iyW2RRQOTfpdh4xLLqUK_xPwqLdDU7ijBPmDSXLn=HVBMQ@mail.gmail.com> <CAKz0y8wnP6PsJPOCTmXOzmHBs5X=2PuXCbgLJ_BWUm3XhNmURw@mail.gmail.com> <cb14fd79505a48f6b9fa57be5354673a@XCH-ALN-008.cisco.com> <CAKz0y8w7cO1AGZxp83Rf-_TvjeEz6zEjsB5UBLmAsC17c34e2w@mail.gmail.com> <b5583439198442cdab833a798985c377@XCH-ALN-008.cisco.com> <CAKz0y8whN=KSR45V6kZ=TvCNwx=BG00v2xz=Dan2yO-jhbEnSg@mail.gmail.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LebOeVTqAjeYxOhbcPB4dTtqx98>
Subject: Re: [Lsr] IGP TE Metric Extensions
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: Tue, 05 Jun 2018 12:42:49 -0000

> On Jun 5, 2018, at 2:21 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
> 
> If these are only implementation specific aspects and shouldn't get into the draft, what is the point of sections 5,6,7?


these sections describe the requirements implementations must address. The way they address them is out of scope of the document.

s.



> Why would it hurt to say what is generally expected to be part of the protocol machinery and what is not?

> 
> BTW, any known implementation for RFC 7810, also supporting sections 5,6,7?
> 
> Regards,
> Muthu
> 
> On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> Hi Muthu,
> 
>  
> 
> These are implementation specific aspects and I am not sure if this is something that the draft should be getting into.
> 
>  
> 
> Thanks,
> 
> Ketan
> 
>  
> 
> From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> 
> Sent: 05 June 2018 17:19
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>
> Cc: Stefano Previdi (IETF) <s@previdi.net>et>; lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
> 
> 
> Subject: Re: [Lsr] IGP TE Metric Extensions
> 
>  
> 
> Sounds reasonable to me..
> 
>  
> 
> Adding a clarification note in the draft would be useful, IMHO.
> 
>  
> 
> Regards,
> 
> Muthu
> 
>  
> 
> On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> Hi Muthu,
> 
>  
> 
> The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP protocol operation and stability though it is not an integral part of the IGP protocol machinery. This functionality in a system, whether achieved in the IGP/measurement/some-other module, is an implementation specific aspect.
> 
>  
> 
> To answer your question, these aspects may be implemented outside the core IGP module and the IGPs simply flood these while satisfying the aspects specified in the document.
> 
>  
> 
> Thanks,
> 
> Ketan
> 
>  
> 
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Muthu Arul Mozhi Perumal
> Sent: 05 June 2018 16:42
> To: Stefano Previdi (IETF) <s@previdi.net>
> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
> Subject: Re: [Lsr] IGP TE Metric Extensions
> 
>  
> 
>  
> 
> ​Please see inline..​
> 
>  
> 
> On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <s@previdi.net> wrote:
> 
>  
> 
> On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
> 
> Thanks, Jeff. Would be good to have this clarified in 
> 
> ​​
> 
> draft-ginsberg-isis-rfc7810bis. My original message seems to have been stripped off, so including it again for the lsr list..
> 
>  
> 
> ​Both RFC 7810 and RFC 7471 say that:
> 
>  
> 
>    The measurement interval, any filter coefficients, and any
> 
>    advertisement intervals MUST be configurable per sub-TLV.
> 
>  
> 
>    Additionally, the default measurement interval for all sub-TLVs
> 
>    SHOULD be 30 seconds.
> 
>  
> 
> However, both RFCs initially say that they only describe mechanisms for disseminating performance information and methods of measurements is outside their scope.
> 
>  
> 
> Moreover, for a first time reader, it seems to suggest that the measurement interval and filter coefficient must be supported and configurable under the IGP.
> 
>  
> 
>  
> 
> No. This is not suggested in any form.
> 
> It is clearly indicated that the draft does not deal with measurements which means no recommendation is made.
> 
>  
> 
>  
> 
> In a system supporting multiple IGPs, I would expect that they be implemented outside the IGP and the IGPs just disseminate the information provided to them.
> 
>  
> 
> Thoughts, especially from an implementation standpoint?
> 
>  
> 
>  
> 
> Again, the draft is only about dissemination, not measurements..
> 
>  
> 
> ​How is the measurement interval and filter coefficients described in the draft related to dissemination?​
> 
>  
> 
> ​   The measurement interval, any filter coefficients, and any
> 
>    advertisement intervals MUST be configurable per sub-TLV.
> 
>  
> 
>    Additionally, the default measurement interval for all sub-TLVs
> 
>    SHOULD be 30 seconds.​
> 
>  
> 
> If your question is related to configuration and implementation of measurements, well it will not be addressed by this draft.
> 
>  
> 
> We intentionally left out this part that does not belong to the igp protocol machinery.
> 
>  
> 
> ​Which of the functionalities described in sections 5, 6, 7 of the draft belong to the IGP protocol machinery?
> 
>  
> 
> Regards,
> 
> Muthu
> 
>  
> 
>  
> 
> s.
> 
>  
> 
>  
> 
>  
> 
> Regards.
> 
> Muthu
> 
>  
> 
> On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> 
> Muthu,
> 
> LSR would be a more suitable list to post to, CCed.
> 
> Regards,
> Jeff
> 
> > On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
> > 
> > Muthu
> 
>  
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>  
> 
>  
> 
>