RE: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt

<bruno.decraene@orange.com> Wed, 28 May 2014 08:20 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55C1A02A4 for <rtgwg@ietfa.amsl.com>; Wed, 28 May 2014 01:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 2lWKBIongXtn for <rtgwg@ietfa.amsl.com>; Wed, 28 May 2014 01:20:52 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C896A1A01F2 for <rtgwg@ietf.org>; Wed, 28 May 2014 01:20:51 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id EE9283B40DD for <rtgwg@ietf.org>; Wed, 28 May 2014 10:20:46 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CFD654C075 for <rtgwg@ietf.org>; Wed, 28 May 2014 10:20:46 +0200 (CEST)
Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 28 May 2014 10:20:43 +0200
From: bruno.decraene@orange.com
To: LITKOWSKI Stephane SCE/IBNF <stephane.litkowski@orange.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
Thread-Topic: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
Thread-Index: AQHPefOyESAdv20HH02eg6JxXc256ZtVlPwAgAALmjA=
Date: Wed, 28 May 2014 08:20:43 +0000
Message-ID: <29389_1401265246_53859C5E_29389_9110_1_6e0f1d94-6412-413d-b85b-cb17f18ccef9@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References: <20140527213608.31267.80528.idtracker@ietfa.amsl.com> <9235_1401261459_53858D93_9235_2274_1_9E32478DFA9976438E7A22F69B08FF92011FDB@OPEXCLILM34.corporate.adroot.infra.ftgroup>
In-Reply-To: <9235_1401261459_53858D93_9235_2274_1_9E32478DFA9976438E7A22F69B08FF92011FDB@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.75120
Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/61cGmVeFfdlJNEDMFZlwi_gdLZw
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2014 08:20:54 -0000

Hi Stéphane,

Looks good, thanks.

I have a question related to object "ipFrrAltType"

>       loopFreeRemote (4), -- remote loop free alternate
>       loopFreeTunnel (5), -- loop free alternate using a configured tunnel

>       loopFreeRemote : remote LFA as described in draft-ietf-rtgwg-remote-lfa
>       loopFreeTunnel : remote LFA reachable through a RSVP-TE or GRE tunnel

It's not clear to me what exactly is the difference between loopFreeRemote and loopFreeTunnel:
Is this the type of tunnels: explicitly routed (i.e. RSVP-TE) vs following the shortest path (i.e. LDP, GRE, draft-ietf-rtgwg-remote-lfa
Is this the determination of the required tunnels: automatically computed (i.e. draft-ietf-rtgwg-remote-lfa, automatic RSVP-TE LSP bypass tunnel to the next-hop) vs configured.

Current description seems to mix both aspects.

> loopFreeTI : remote LFA reachable through a SPRING tunnel
To some expect, the question also applies to "loopFreeTI" where there is a mix of FRR algorithm (how is the alternate computed i.e. TI FRR) and the type of tunnels to reach the alternate (here SPRING tunnels, while in theory the alternate could equally be reached using a RSVP-TE+ T-LDP tunnels

I'm open to any solution. IMHO the description of the FRR algo is the more important:
      ipFrrAltType OBJECT-TYPE
          SYNTAX   INTEGER {
                      other             (1), -- type not defined
                      equalCost         (2), -- primary path
                      loopFreeConnected          (3), -- loop free connected alternate (LFA)
                      loopFreeRemote    (4), -- remote loop free alternate (RLFA)
                      loopFreeNH    (5), -- loop free alternate using a tunnel toward the Next Hop
                      loopFreeNNH    (6), -- loop free alternate using a tunnel toward the Next Next Hop
                      loopFreeTI        (7), -- loop free alternate using topology independent algorithm
                      mrt               (8)  -- Maximally Redundant Trees
                   }

If you believe that we also need the type of tunnels/forwarding infrastructure, another object could be added
      ipFrrTunnType OBJECT-TYPE
          SYNTAX   INTEGER {
                      other             (1), -- type not defined
                      LDP         (2)
                      IP          (3),  GRE, L2TP...
                      RSVP-TE   (4)
                      SPRING MPLS  (5)
                      SPRING IPv6  (6)
                      Multi-topology (7)
                   }

Bruno

> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of
> stephane.litkowski@orange.com
> Sent: Wednesday, May 28, 2014 9:18 AM
> To: rtgwg@ietf.org
> Subject: FW: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> 
> Hi all,
> 
> To followup discussion in London, I updated the IP FRR MIB draft with some
> new things :
> - different objects for IPv4 and IPv6 protection stats
> - Interface configuration table
> - IPFRR instance table as we may expect to have multiple flavors running on a
> common node
> - Protectstats per instance table.
> - Few other things
> 
> Feel free to comment and propose addings/corrections.
> 
> 
> Stephane
> 
> 
> 
> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Tuesday, May 27, 2014 23:36
> To: i-d-announce@ietf.org
> Cc: rtgwg@ietf.org
> Subject: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Routing Area Working Group Working Group
> of the IETF.
> 
>         Title           : IP MIB for IP Fast-Reroute
>         Authors         : Alia Atlas
>                           Cisco Systems
>                           John Flick
>                           Stephane Litkowski
> 	Filename        : draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> 	Pages           : 26
> 	Date            : 2014-05-27
> 
> Abstract:
>    This draft defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes managed objects relevant for IP routes
>    using IP Fast-Reroute [RFC5714]
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-ip-mib/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-ip-mib-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ipfrr-ip-mib-03
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

_________________________________________________________________________________________________________________________

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.