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
Jeff Tantsura | 27 Mar 16:19 2015
Picon

RTGWG minutes available

RTGWG,

Please see the URL for the RTGWG minutes. Thanks to Acee Lindem and Ignas
Bagdonas for taking them.
https://www.ietf.org/proceedings/92/minutes/minutes-92-rtgwg

See you all in Prague.

Cheers,
Jeff
Jeff Tantsura | 24 Mar 16:30 2015
Picon

Please note - we are going to have 2 sessions - 1st today 17:30-18:30, 2nd - Thursday 13:00-15:00 (as planned originally)


Cheers,
Jeff
IETF Secretariat | 24 Mar 15:58 2015
Picon

Milestones changed for rtgwg WG

Changed milestone "Submit Document on Operational Experience of using
BGP in a Data Center for publication as Informational", set due date
to July 2015 from March 2015.

URL: http://datatracker.ietf.org/wg/rtgwg/charter/
IETF Secretariat | 19 Mar 19:37 2015
Picon

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

IESG state changed to AD Evaluation from Publication Requested
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/
Jeff Tantsura | 19 Mar 17:03 2015
Picon

Re: IETF92 RTGWG agenda - please note the 2nd slot

Hi RTGWG,

Updated agenda has been posted, please note - we have extended agenda with
2nd slot.
1 slot is:
TUESDAY, March 24, 2015
17:30 - 18:30  Afternoon Session III

2 slot is:
THURSDAY, March 26, 2015
13:00 - 15:00  Afternoon Session I

Presenters - please make sure we┬╣ve received your slides in time!

Thanks!

Cheers,
Jeff & Chris

-----Original Message-----
From: Jeff Tantsura <jeff.tantsura <at> ericsson.com>
Date: Sunday, March 15, 2015 at 2:25 PM
To: "rtgwg <at> ietf.org" <rtgwg <at> ietf.org>
Subject: Re: IETF92 RTGWG agenda

>Hi RTGWG,
>
>
>Updated agenda has been posted, in order to accommodate all the slots
>requested we cut down all the sessions to 8 minutes.
>When preparing slides please take into account the time limit and rather
>busy agenda.
>
>Thanks! 
>
>Cheers,
>Jeff & Chris
>
>
>
>
>>--Original Message-----
>>From: Jeff Tantsura <jeff.tantsura <at> ericsson.com>
>>Date: Monday, March 9, 2015 at 5:16 PM
>>To: "rtgwg <at> ietf.org" <rtgwg <at> ietf.org>
>>Subject: IETF92 RTGWG agenda
>>
>>>Hi RTGWG,
>>>
>>>Agenda for RTGWG meeting at IETF92 has been posted, found at
>>>http://www.ietf.org/proceedings/92/agenda/agenda-92-rtgwg
>>>
>>>See you in Dallas!
>>>
>>>Cheers,
>>>Jeff & Chris
>>>
>>>
>>>_______________________________________________
>>>rtgwg mailing list
>>>rtgwg <at> ietf.org
>>>https://www.ietf.org/mailman/listinfo/rtgwg
>>
>>_______________________________________________
>>rtgwg mailing list
>>rtgwg <at> ietf.org
>>https://www.ietf.org/mailman/listinfo/rtgwg
>
>_______________________________________________
>rtgwg mailing list
>rtgwg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/rtgwg
Ing-Wher Chen | 13 Mar 02:19 2015
Picon

FW: New Version Notification for draft-chen-rtg-key-table-yang-00.txt

1) Key Management

The base key-chain draft <https://datatracker.ietf.org/doc/draft-acee-rtg-yang-key-chain/>
 manages authentication keys using key-chains, where a key-chain consists of a set of keys.

However, the base key-chain draft also provides the flexibility to allow for different vendor
implementations and different protocol implementations to manage authentication keys using
the key-chain concept (or even using non-keychain concepts).

2) Properties of Keys

Regardless of how keys are managed, some, if not all, of the authentication-key attributes
defined in RFC 7210 are inherent attributes of an authentication-key, and are independent
of how keys are managed.  Examples of this include the "direction" of the key and the "KDF"
to use with a key.  (RFC 7210 is the standards-track definition of data needed for routing
protocol authentication.)

This draft <https://datatracker.ietf.org/doc/draft-chen-rtg-key-table-yang/> defines
OPTIONAL additions the key-chain draft so implementations MAY include all the
authentication-key attributes described in RFC 7210.  Because these additional
authentication-key attributes are OPTIONAL, any implementation MAY choose to omit them.
For example, a router that does not support the latest TCP-AO RFC to protect BGP would
not care about the authentication-key "direction".

Thanks,
Helen

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, March 09, 2015 5:14 PM
To: Ing-Wher Chen; Ing-Wher Chen
Subject: New Version Notification for draft-chen-rtg-key-table-yang-00.txt

A new version of I-D, draft-chen-rtg-key-table-yang-00.txt
has been successfully submitted by I. Chen and posted to the IETF repository.

Name:		draft-chen-rtg-key-table-yang
Revision:	00
Title:		YANG Data Model for RFC 7210 Key Table
Document date:	2015-03-09
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-chen-rtg-key-table-yang-00.txt
Status:         https://datatracker.ietf.org/doc/draft-chen-rtg-key-table-yang/
Htmlized:       http://tools.ietf.org/html/draft-chen-rtg-key-table-yang-00

Abstract:
   This document defines a YANG data model to describe the key table
   defined in RFC 7210.  The data model defined in this document
   augments the existing key-chain model with additional key attributes
   specified in RFC 7210.

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.

The IETF Secretariat
Jeff Tantsura | 10 Mar 02:16 2015
Picon

IETF92 RTGWG agenda

Hi RTGWG,

Agenda for RTGWG meeting at IETF92 has been posted, found at
http://www.ietf.org/proceedings/92/agenda/agenda-92-rtgwg

See you in Dallas!

Cheers,
Jeff & Chris
Uma Chunduri | 9 Mar 18:58 2015
Picon

FW: New Version Notification for draft-chunduri-rtgwg-lfa-extended-procedures-02.txt

Dear WG,

This version includes a minor references update.

Thoughts and comments are most welcome on this draft.

--
Uma C.

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, March 09, 2015 10:57 AM
To: Jeff Tantsura; Jeff Tantsura; Uma Chunduri; Chris Bowers; Chris Bowers; Uma Chunduri
Subject: New Version Notification for draft-chunduri-rtgwg-lfa-extended-procedures-02.txt

A new version of I-D, draft-chunduri-rtgwg-lfa-extended-procedures-02.txt
has been successfully submitted by Uma Chunduri and posted to the IETF repository.

Name:		draft-chunduri-rtgwg-lfa-extended-procedures
Revision:	02
Title:		Extended procedures and considerations for evaluating Loop-Free Alternates
Document date:	2015-03-09
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-chunduri-rtgwg-lfa-extended-procedures-02.txt
Status:         https://datatracker.ietf.org/doc/draft-chunduri-rtgwg-lfa-extended-procedures/
Htmlized:       http://tools.ietf.org/html/draft-chunduri-rtgwg-lfa-extended-procedures-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-chunduri-rtgwg-lfa-extended-procedures-02

Abstract:
   This document provide few clarifications and extended procedures to
   IP Fast Reroute using Loop-Free Alternates as defined in RFC 5286.

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.

The IETF Secretariat

Gmane