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

From: [email-masked]
Date: Tue, 27 May 2014 14:36:08 -0700

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/

---

From: <[email-masked]>
Date: Wed, 28 May 2014 07:17:38 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 27, 2014 23:36
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt

Abstract:

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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
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.

---

From: <[email-masked]>
Date: Wed, 28 May 2014 08:20:43 +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

> From: rtgwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 28, 2014 9:18 AM
> To: [email-masked]
> Subject: FW: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-03.txt
> 
> Hi all,
> 
> 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.
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Fri, 30 May 2014 08:10:57 +0000

Hi Bruno

Answers inline ...

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

Hi Stéphane,

Looks good, thanks.

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.

[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 ...

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

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

Bruno

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

---

From: <[email-masked]>
Date: Fri, 30 May 2014 12:35:45 +0000

Hi Stéphane,

Please see 1 point inline

> 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.
> 
> 
> 
> [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 ...
> 
> 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
> 

loopFreeNH or may be "Next Hop" :  Next Hop (5), -- loop free alternate using an explicitly routed  tunnel toward the original Next Hop (link protection only)
This typically what is offered by a single hop RSVP-TE LSP over the protected link.

NextNextHop    (5), -- loop free alternate using an explicitly routed  tunnel toward the original Next Next Hop

By "original Next Hop" I mean the Next Hop in the current IGP topology (aka "old" during FRR activation/pre failure)

Thanks,
Bruno

> If you believe that we also need the type of tunnels/forwarding
> infrastructure, another object could be added