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

Hi Bruno

Answers inline ...

-----Original Message-----
From: DECRAENE Bruno IMT/OLN 
Sent: Wednesday, May 28, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF; rtgwg@ietf.org
Subject: RE: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt

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.

[SLI] Good point ! :) I had some concern to express this ... the idea was to differentiate rLFA alternates (based on the draft) from other tunneled alternate. If you have a good way to express it , I will take it ...

> 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
                   }

[SLI] Agree, but in your proposal what is exactly loopFreeNH and loopFreeNNH ?

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)
                   }

[SLI] Yes , this may be very interesting, I will add it. 

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.