IETF Secretariat | 16 Apr 21:37 2015
Picon

ID Tracker State Update Notice: <draft-ietf-rtgwg-mofrr-06.txt>

Last call has been made for draft-ietf-rtgwg-mofrr and state has been changed to In Last Call
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/
The IESG | 16 Apr 21:37 2015
Picon

Last Call: <draft-ietf-rtgwg-mofrr-06.txt> (Multicast only Fast Re-Route) to Informational RFC


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'Multicast only Fast Re-Route'
  <draft-ietf-rtgwg-mofrr-06.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2015-04-30. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   As IPTV deployments grow in number and size, service providers are
   looking for solutions that minimize the service disruption due to
   faults in the IP network carrying the packets for these services.
   This document describes a mechanism for minimizing packet loss in a
   network when node or link failures occur.  Multicast only Fast Re-
   Route (MoFRR) works by making simple enhancements to multicast
   routing protocols such as PIM and mLDP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/ballot/

The following IPR Declarations may be related to this I-D:

(Continue reading)

IETF Secretariat | 16 Apr 21:19 2015
Picon

Telechat update notice: <draft-ietf-rtgwg-mofrr-06.txt>

Placed on agenda for telechat - 2015-05-14
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/
Alia Atlas | 16 Apr 21:19 2015
Picon

progressing draft-ietf-rtgwg-mofrr-06

As is usual, I have done my AD review of draft-ietf-rtgwg-mofrr-06.  I don't have any specific comments on the text(assuming that the RFC Editor will pick up the typos I saw).  However, I do see a couple gaps that I think would be very useful to address.   Feel free to convince me otherwise - but I think these will make for a stronger RFC.

It would have been nice to have a sentence or two in there that considered the operational and troubleshooting aspects of MoFRR.  For instance, can mtrace work?  Would lsp-ping fail to work on the secondary UMH because of packets being dropped?

I also recall a private discussion about the interaction of MoFRR and IGP reconvergence after a failure and whether there can be relevant micro-forwarding loops as a result.  It would be very useful to have a sentence or two in this draft that discusses whether micro-forwarding loops are a concern that can either be frequently avoided because the secondary UMH or that needs to be considered in modeling or....

I'd welcome discussion to clarify these two aspects while the draft is in IETF Last Call.  I'd like to have these resolved by May 7 so that it can be on the IESG telechat on May 15.

Thanks for the good work,
Alia
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
IETF Secretariat | 16 Apr 21:18 2015
Picon

ID Tracker State Update Notice: <draft-ietf-rtgwg-mofrr-06.txt>

IESG state changed to Last Call Requested from AD Evaluation
I have two questions about missing content that I raised during my AD review.  Discussion can happen during
IETF Last Call.

It would have been nice to have a sentence or two in there that considered the operational and
troubleshooting aspects of MoFRR.  For instance, can mtrace work?  Would lsp-ping fail to work on the
secondary UMH because of packets being dropped?

I also recall a private discussion about the interaction of MoFRR and IGP reconvergence after a failure and
whether there can be relevant micro-forwarding loops as a result.  It would be very useful to have a
sentence or two in this draft that discusses whether micro-forwarding loops are a concern that can either
be frequently avoided because the secondary UMH or that needs to be considered in modeling or....
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/
Jeff Tantsura | 16 Apr 19:24 2015
Picon

Request for WG adoption of draft-litkowski-rtgwg-spf-uloop-pb-statement and draft-decraene-rtgwg-backoff-algo

Hi RTGWG,

The authors have requested the RTGWG to adopt:
draft-litkowski-rtgwg-spf-uloop-pb-statement and
draft-decraene-rtgwg-backoff-algo as working group documents.

There was support during the last IETF meeting (92) in Dallas.
Please indicate support or no-support by May 1st, 2015.

If you are listed as a document author or contributor please respond to
this email stating of whether or not you are aware of any relevant IPR.
The response needs to be sent to the RTGWG mailing list. The document will
not advance to the next stage until a response has been received from each
author and each individual that has contributed to the document.

Thanks,

Jeff & Chris
bruno.decraene | 2 Apr 15:05 2015

FW: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Re-sending…

 

From: DECRAENE Bruno IMT/OLN
Sent: Thursday, April 02, 2015 3:00 PM
To: 'Anil Kumar S N (VRP Network BL)'
Cc: pierre.francois <at> imdea.org; Alia Atlas; Robert Kebler; Gabor.Sandor.Enyedi <at> ericsson.com; Andras.Csaszar <at> ericsson.com; jeff.tantsura <at> ericsson.com; russw <at> riw.us; rtgwg <at> ietf.org; dhruv.ietf <at> gmail.com; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

 

Hi Anil,

 

Please see inline [Bruno2]

 

Thanks,

Regards,

Bruno

 

From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn <at> huawei.com]
Sent: Thursday, April 02, 2015 1:52 PM
To: DECRAENE Bruno IMT/OLN
Cc: pierre.francois <at> imdea.org; Alia Atlas; Robert Kebler; Gabor.Sandor.Enyedi <at> ericsson.com; Andras.Csaszar <at> ericsson.com; jeff.tantsura <at> ericsson.com; russw <at> riw.us; rtgwg <at> ietf.org; dhruv.ietf <at> gmail.com; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

 

Hi Bruno,

 

                J Lets finalize on the rephrased statement which need to be updated.  

                Please see inline [Anil]

 

Thanks & Regards

Anil S N

 

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

 

 

[…]

 

Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck  as below :

P Node Lable

P-Node to Q-Node Adj lable

Q-Node Lable

Destination Lable

[Bruno2] As a side note, “Q-Node Label” is not required. (with previous label, you reach “Q”. Then “Q” can directly reach the destination “D”)

 

Topology :

P----Q (Cost 10)

Q----Destination(Cost 10)

P----Destination (Cost 100)

 

[Bruno2] I understand the following topology

     10         10

P ------ Q ------- D

|                         |

+--------------+

      100

 

Faliure happens on the only link b/w Q-Node towards destination; Reachability to destination with SPF calculation or with FRR falls back towards P-Node (Q’s TI LFA calculation).

[Bruno] In this specific case, I don’t see a loop. Q, acting as the second PLR (in a row), has computed that  node “P” is its P node and node “D” is its Q node. P is reached via a node-SID (possibly implicit label) which is not affected by the first failure. Q is reached by a Adj-sid, which is not affected by the first failure.

 

[Anil] : Here P would send a packet to Q and as primary path to D is lost Q would return packet back to P till P learns link b/w Q and D is down.

[Bruno2] Q sees the failure of QD for destination D. It will swap Node_SID (D) to  Node_SID (P), Adj_SID PD, Node_SID (D).  (In MPLS, with PHP, first and last SID may be encoded with no label)

P will see, at the topo of the stack “Adj_SID PD” and hence will send the traffic to D.

No loop.

 

So there could be a loop.

[Bruno] I could not find one in this example, but I agree that we could find examples with loops.

e.g. the following topology

A – B

|  \  |

C – D

 

Where all links have a metric of 10, except AC which has 100. For the traffic from A to C, if both AC and BD links fails at the same time (and were not identified as SRLG), there will be a loop between A and B. (and funnily (is it? ;-) ) as packets are looped, the label stack seems to increase to “infinity” as additional P nodes (alternatively C and D) are used.

 

[Anil] : I understand Loop here but Label stack increase can you help me to understand.

[Bruno2] My mistake. Sorry. I meant all links have a metric of 10, except AD which has 100

Notation:

Prefix à Nominal Next-Hop

           => LFA Next-Hop

 

On node A:

C à C

   => B, push Node_SID(D),  Node_SID(C)

 

 

On node B:

D à D

   => A, push  Node_SID(C), Node_SID(D)

 

 

If both links AC & BD fails, each PLR (A & B) push 1 additional label (respectively to D & C). Since C & D are never reached, label are never poped. So at each iteration in the loop, an additional label is pushed.

 

Here primary path would be A->D->C  [Cost 20]  for A (LFA A->B->D->C), Primary path for B to would be B->D->C [Cost 20] (LFA B->A->D->C).

On A->C link failure A chooses A->B->D->C, On B->D failure B chooses B->A->D->C. A would send packet to B and B would send packet to A.

 

Here which label is inserted ?

 

         10        

   A           B 

    +---------+  

    | \       |  

    |  \      |  

    |   \     |  

    |    \10  | 10

100 |     \   |  

    |      \  |  

    |       \ |  

    |        \|  

    +---------+  

 C      10      D

 

 

 

So I still feel there is a tradeoff.

[Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any)

[Anil] : This Could be explicitly specified J

[Bruno2] Indeed, how each solution handles independent failure may be indicated. However, if space is limited in the draft, this is probably not the most important metric (IMHO) has this situation should rarely happen (assuming SRLG are known and the solution protects from SRLG)

 

Thanks

Regards

/Bruno

 

Thanks & Regards

Anil S N

 

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

 

_________________________________________________________________________________________________________________________ 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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Bruno,

 

                J Lets finalize on the rephrased statement which need to be updated.  

                Please see inline [Anil]

 

Thanks & Regards

Anil S N

 

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

 

 

From: bruno.decraene <at> orange.com [mailto:bruno.decraene <at> orange.com]
Sent: 02 April 2015 18:24
To: Anil Kumar S N (VRP Network BL)
Cc: pierre.francois <at> imdea.org; Alia Atlas; Robert Kebler; Gabor.Sandor.Enyedi <at> ericsson.com; Andras.Csaszar <at> ericsson.com; jeff.tantsura <at> ericsson.com; russw <at> riw.us; rtgwg <at> ietf.org; dhruv.ietf <at> gmail.com; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

 

Hi Anil,

 

Please see inline [Bruno]

 

From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn <at> huawei.com]
Sent: Thursday, April 02, 2015 10:53 AM
To: DECRAENE Bruno IMT/OLN; Chris Bowers
Cc: pierre.francois <at> imdea.org; Alia Atlas; Robert Kebler; Gabor.Sandor.Enyedi <at> ericsson.com; Andras.Csaszar <at> ericsson.com; jeff.tantsura <at> ericsson.com; russw <at> riw.us; rtgwg <at> ietf.org; dhruv.ietf <at> gmail.com; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt

 

Hi Bruno,Chris,

 

          Lets not talk about number of labels. With respect to TI LFA, In our implementation we have extended number labels much more than two,

[Bruno] Good job.

- For link protection only, in network with symmetric link cost, up to 2 labels may be required for. Never more than 2.

- For others cases, in particular node and/or SRLG protection, more than 2 labels may be required. In theory, there is no limit. In practice, there is a limit. In our networks, the max found was 4 labels. So it’s good to be able to push more than 2 labels to enforce the FRR detour.

 

[Anil] : Agreed

 

Ex: when there is no PQ node also when there no adjacency b/w any  P and Q node pair.  We find a shortest path from P & Q form; a label stack that will be pushed. In case L3 VPN PE label stack could become much more. This consumes more computation.

 

Best effort label for a destination is Destination Label , SR FRR label for the same destination is [P Node -> Label stack to reach Q Node -> Destination label].

 

[Bruno] I would propose

OLD: using an MPLS label stack with two labels

NEW: by pushing up to two additional labels

 

There is a possibility of Looping in TI-LFA; We can expect in case of multiple simultanious failure:

[Bruno] You are right. In case of independent/non FRR planned failures, the first PLR can’t avoid all failures since those failures were expected to not planned/expected to occur at the same time. The second PLR will try to protect the second failure. In good cases, the two protections are complementary and will achieve “de facto” protection. In bad cases, forwarding loop will occur. In theory, the handling of the second independent failure, is a (difficult) choice, between dropping or trying to repair. In theory TI-LFA could do both, but as of today, it tries the second protection

This is not specific to TI-LFA. FRR assumes _local_ protection (hence local knowledge) of a _pre_computed_ (hence pre-planned) failure.

I have been told ARC could handle multiple consecutive FRR (through some localize notification mechanism) but I don’t have the details.

 

[Anil] : I also suggested authors to add comparison with respect to ARC too.

 

Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck  as below :

P Node Lable

P-Node to Q-Node Adj lable

Q-Node Lable

Destination Lable

 

Topology :

P----Q (Cost 10)

Q----Destination(Cost 10)

P----Destination (Cost 100)

 

Faliure happens on the only link b/w Q-Node towards destination; Reachability to destination with SPF calculation or with FRR falls back towards P-Node (Q’s TI LFA calculation).

[Bruno] In this specific case, I don’t see a loop. Q, acting as the second PLR (in a row), has computed that  node “P” is its P node and node “D” is its Q node. P is reached via a node-SID (possibly implicit label) which is not affected by the first failure. Q is reached by a Adj-sid, which is not affected by the first failure.

 

[Anil] : Here P would send a packet to Q and as primary path to D is lost Q would return packet back to P till P learns link b/w Q and D is down.

 

 

So there could be a loop.

[Bruno] I could not find one in this example, but I agree that we could find examples with loops.

e.g. the following topology

A – B

|  \  |

C – D

 

Where all links have a metric of 10, except AC which has 100. For the traffic from A to C, if both AC and BD links fails at the same time (and were not identified as SRLG), there will be a loop between A and B. (and funnily (is it? ;-) ) as packets are looped, the label stack seems to increase to “infinity” as additional P nodes (alternatively C and D) are used.

 

[Anil] : I understand Loop here but Label stack increase can you help me to understand.

Here primary path would be A->D->C  [Cost 20]  for A (LFA A->B->D->C), Primary path for B to would be B->D->C [Cost 20] (LFA B->A->D->C).

On A->C link failure A chooses A->B->D->C, On B->D failure B chooses B->A->D->C. A would send packet to B and B would send packet to A.

 

Here which label is inserted ?

 

         10        

   A           B 

    +---------+  

    | \       |  

    |  \      |  

    |   \     |  

    |    \10  | 10

100 |     \   |  

    |      \  |  

    |       \ |  

    |        \|  

    +---------+  

 C      10      D

 

 

 

So I still feel there is a tradeoff.

[Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any)

[Anil] : This Could be explicitly specified J

 

Thanks

Regards

/Bruno

 

Thanks & Regards

Anil S N

 

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

 

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
IETF Secretariat | 30 Mar 22:46 2015
Picon

IPR Disclosure Cisco's Statement about IPR related to draft-litkowski-rtgwg-uloop-delay

Dear Stephane Litkowski, Bruno Decraene, Pierre Francois, Clarence Filsfils:

An IPR disclosure that pertains to your Internet-Draft entitled "Microloop
prevention by introducing a local convergence delay"
(draft-litkowski-rtgwg-uloop-delay) was submitted to the IETF Secretariat on 
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/2565/). The title of the IPR
disclosure is "Cisco's Statement about IPR related to
draft-litkowski-rtgwg-uloop-delay"

Thank you

IETF Secretariat

draft-ietf-rtgwg-mrt-frr-architecture-05.txt

Hi Authors,

 

      In  “comparison of IP/LDP FRR Methods” section of the document , I feel we should add comparison with TI-LFA (draft-francois-spring-segment-routing-ti-lfa-01) where TI-LFA approach achieves guaranteed coverage  against link or node failure, in any IGP network, relying on the  flexibility of SR. This will give readers better picture and enables them with more information so that they can choose MRT if they feel it suites their requirement better; compared to IT-LFA.

 

Changes :

 

1.  Introduction :

 

   Other existing or proposed solutions are partial solutions or have

   significant issues, as described below.

 

                 Summary Comparison of IP/LDP FRR Methods

 

   +---------+-------------+-------------+-----------------------------+

   |  Method |   Coverage  |  Alternate  |    Computation (in SPFs)    |

   |         |             |   Looping?  |                             |

   +---------+-------------+-------------+-----------------------------+

   | MRT-FRR |     100%    |     None    |         less than 3         |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |   LFA   |   Partial   |   Possible  |         per neighbor        |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   |  Remote |   Partial   |   Possible  |    per neighbor (link) or   |

   |   LFA   |  Link/Node  |             |  neighbor's neighbor (node) |

   |         |             |             |                             |

   | Not-Via |     100%    |     None    |      per link and node      |

   |         |  Link/Node  |             |                             |

   |         |             |             |                             |

   | TI-LFA  |     100%    |   Possible  |    per neighbor (link) or   |

   |         |  Link/Node  |             |  neighbor's neighbor (node) |

   |         |             |             |                             |

   +---------+-------------+-------------+-----------------------------+

 

                                  Table 1

 

 

   TI-LFA: Topology Independent Loop-free Alternate Fast

   Re-route (TI-LFA), aimed at providing link and node protection of

   node and adjacency segments within the Segment Routing (SR)

   framework [draft-francois-spring-segment-routing-ti-lfa-01].

   Has improved coverage over LFAs and Remote LFA for link and node

   protection and also guarantees complete coverage. The trade-off

   of looping traffic to improve coverage is still made.

  The computation required is quite high with added complexity.

   TI-LFA is supported only MPLS data plane with a requirement to

   carry additional MPLS label stack on the link failure; on certain

   topologies stack size can grow significantly based repair path.

 

Thanks & Regards

Anil S N

 

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

 

 

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Reshad Rahman (rrahman | 27 Mar 16:52 2015
Picon

Clearing counters

This is regarding the comment I made yesterday during draft-liu-rtgwg-yang-vrrp, Xufeng rightfully stated that this was a question which had to be addressed for all YANG models. 

I have attached Juergen’s email on this topic.

Regards,
Reshad.

Picon
From: Juergen Schoenwaelder <j.schoenwaelder <at> jacobs-university.de>
Subject: Re: [Rtg-yang-coord] Clearing all stats in a container
Date: 2015-03-05 07:45:29 GMT
On Wed, Mar 04, 2015 at 10:30:37PM -0800, Mahesh Jethanandani wrote:
> Assuming one has defined stat counters in one container, like
ietf-interfaces has done with its statistics, does anyone have suggestions
on how one can essentially clear (reset to 0) all the counters in that
container.
>

Resetting counters is a bad idea. Once you have more than one
application trying to reset counters you get into trouble. Note
this RFC 6991 (lifted from RFC 2578):

       Counters have no defined 'initial' value, and thus, a
       single value of a counter has (in general) no information
       content.

Applications have to read a counter C at time t0 and then again at
time t1 and then calculate the difference C(t1) - C(t0). This allows
applications to obtain statistics at different time granularities
without stepping on each other.

/js

--

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Gmane