Jeff Tantsura | 23 Jul 14:34 2015

Request for WG adoption of draft-liu-rtgwg-yang-rip


The authors have requested the RTGWG to adopt draft-liu-rtgwg-yang-rip

Please indicate support or no-support by August 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.


Jeff & Chris
Meetecho Team | 22 Jul 18:57 2015

Meetecho recordings of RTGWG 2nd WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
RTGWG 2nd WG session at IETF 93 is available at the following URL:

In case of problems with the playout, just drop an e-mail to ietf-support <at>

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

the Meetecho Team

rtgwg mailing list
rtgwg <at>
Meetecho Team | 22 Jul 17:00 2015

Meetecho recordings of RTGWG WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
RTGWG WG session at IETF 93 is available at the following URL:

In case of problems with the playout, just drop an e-mail to ietf-support <at>

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

the Meetecho Team

rtgwg mailing list
rtgwg <at>
Acee Lindem (acee | 22 Jul 11:30 2015


This is the IPR I was referring to:

I’m know there is other IPR in this area but this one is very similar with
the virtual instance in that it isolates the remotes sites and handles
back-door links w/o any update to the remote routers.


rtgwg mailing list
rtgwg <at>
Xuxiaohu | 22 Jul 10:37 2015

draft-kumar-sfc-nsh-udp-transport & draft-ietf-rtgwg-dt-encap

Hi all,

First of all, I like the idea of directly encapsulating NSH over UDP since it eliminates the unnecessary
VXLAN header encapsulation burden. However, there are still many headaches surrounding any UDP-based
encapsulation proposal such as congestion controll, IPv6/UDP checksum, MTU and fragmentation, UDP
dest port resource utilization. 

Since UDP has been selected as a tunnelling technology by more and more encapsulation proposals besides
NSH-in-UDP, including but not limited to VXLAN, VXLAN-GPE, MPLS-in-UDP, IP-in-UDP,  TRILL-in-UDP,
draft-ietf-rtgwg-dt-encap would be more useful in practice if it could give us concrete
recommendations regarding the above headaches surrounding the UDP tunnelling usage, IMHO.

Best regards,
stephane.litkowski | 20 Jul 13:35 2015

Comments on draft-shaikh-rtgwg-policy-model



As pointed this morning during the WG session :

-          We need to clarify (asap if possible) the boundary between this policy model and what should be defined in protocol models to extend the policy. In the current version, it looks like a mix of having part of IGP defined in the generic policy framework and so expecting some other extensions in IGP models. For BGP, all is within BGP. My proposal would be to let all the protocol extensions to be in protocol models, this includes :

o   Protocol specific matching

o   Protocol specific actions

o   Install-protocol identity for that protocol => so need to remove the existing ones for ISIS, OSPF, BGP in the current version.

-          Regarding tags, as pointed today, I would like to have “tag” to be a generic local identifier rather than pointing only to IS-IS and OSPF. Any route within a RIB may have a local tag (this local tag can be learned from the routing protocol or set by configuration or policy). So setting a tag does not refer to any igp-action.

-          Also regarding the “igp-action” container, I’m not in favor of having separate containers for igp-actions, bgp-actions and generic-actions. Two possibilities :

o   Each protocol creates a container (e.g. isis-actions, ospf-actions …) which augments the action container. Isis-actions and ospf-actions may be different (for example in setting route-type or metric type …)

o   Just having the “actions” container and put all the actions here whatever the applicable protocol.

o   Similar approach to be taken for protocol specific conditions

-          I would be in favor in adding routing table matching condition and a way to select also a destination routing table. E.g. , I use an import policy to force a routing protocol to insert routes in a specific routing table rather than the default one. Or I want to authorize routes from multiple routing tables to be exported to a particular protocol.



Best Regards,



Stephane Litkowski
Network Architect

Orange Expert Future Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski <at>



_________________________________________________________________________________________________________________________ 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>
Chris Bowers | 18 Jul 19:02 2015

Python implementation of MRT lowpoint algorithm

We wrote a Python implementation of the MRT lowpoint algorithm following the pseudo-code in the draft, and have included it in the text of draft-ietf-rtgwg-mrt-frr-algorithm-05. 
The code is also posted on github at:
At this point, the Python implementation is included in the draft as additional information, with the pseudo-code text representing the normative version of the algorithm.  For the next revision of the draft, I think it makes sense to make the Python implementation the normative version of the algorithm since it can actually be run to produce a definitive result for any input topology.  However, I want to elicit feedback from the WG as to whether or not it makes sense to do this.
We can also discuss this point at the RTGWG session on Wednesday where I will give an update on the MRT-related drafts.
rtgwg mailing list
rtgwg <at>
Jeff Tantsura | 18 Jul 00:27 2015

RTGWG slides for IETF 93


Please make sure to send the slides in time, for those presenting Monday
slides by Sunday would really be appreciated.

Jeff Tantsura | 9 Jul 00:06 2015

Preliminary agenda for RTGWG meetings at IETF93


Preliminary agenda for RTGWG meetings at IETF93 has been posted, found at

We will updated it as new requests are being received, please check it for
the correctness. 

Thanks and see you in Prague!

Jeff & Chris
David Lamparter | 7 Jul 02:05 2015

Fwd: New Version Notification for draft-lamparter-rtgwg-dst-src-routing-01.txt

Hi rtgwg,

addressing some of the feedback from IETF 91 (Hawai'i), I've posted -01
of the dst-src-routing draft.

The major change from -00 consists of the removal of all references to
the "extra qualifier" stuff.  (That was suggesting a registry to put new
route qualifiers into, flowlabel being one of the candidates.)

As it is now, the draft simply explains SADR for a non-homenet-savvy
implementor of a routing system.  It also looks at contact areas between
SADR and other parts of the routing system, in particular its
interaction with recursive route resolution is an open question.

This functionality is used in homenet but is rather out of scope there
since it changes the way basic routing works.  Therefore, I'd like to
get this adopted as WG document in rtgwg.  I'm hoping that homenet's
decision to depend on this provides sufficient argument on the
"interest"/"need" front of things.

Feedback of course very welcome,


----- Forwarded message from internet-drafts <at> -----

Delivery-date: Sat, 27 Jun 2015 10:34:23 +0200
From: internet-drafts <at>
To: David Lamparter <david <at>>, David Lamparter <david <at>>
Subject: New Version Notification for draft-lamparter-rtgwg-dst-src-routing-01.txt
Message-ID: <20150627083411.29410.88505.idtracker <at>>
Date: Sat, 27 Jun 2015 01:34:11 -0700

A new version of I-D, draft-lamparter-rtgwg-dst-src-routing-01.txt
has been successfully submitted by David Lamparter and posted to the
IETF repository.

Name:		draft-lamparter-rtgwg-dst-src-routing
Revision:	01
Title:		Destination/Source Routing
Document date:	2015-06-27
Group:		Individual Submission
Pages:		8

   This note specifies using packets' source addresses in route lookups
   as additional qualifier to be used in route lookup.  This applies to
   IPv6 [RFC2460] in general with specific considerations for routing
   protocol left for separate documents.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

----- End forwarded message -----
rtgwg mailing list
rtgwg <at>
Erik Nordmark | 7 Jul 01:07 2015

Uploaded draft-ietf-rtgwg-dt-encap-00

It had to be manually posted, which is perhaps why there wasn't an 
automatic email sent to the list.