Hi Stéphane,
Please see 1 point inline
> 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 ?
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
> 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:[email protected]] On Behalf Of
> > [email protected]
> > Sent: Wednesday, May 28, 2014 9:18 AM
> > To: [email protected]
> > 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:[email protected]] On Behalf Of
> > [email protected]
> > Sent: Tuesday, May 27, 2014 23:36
> > To: [email protected]
> > Cc: [email protected]
> > 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
> > [email protected]
> > 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
> > [email protected]
> > 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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
