Alia Atlas | 28 May 17:12 2015
Picon

Closed: routing area design team on dataplane encapsulation considerations

I would like to thank the Design Team for their hard work.  They have addressed comments and published draft-rtg-dt-encap-02 ( https://datatracker.ietf.org/doc/draft-rtg-dt-encap/ ).   This draft is being considered now by RTGWG for adoption.

Thanks again for the work and speed,
Alia

On Tue, Dec 9, 2014 at 5:46 PM, Alia Atlas <akatlas <at> gmail.com> wrote:
I have chartered a Routing Area Design Team to work on data-plane encapsulation considerations.

I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.  Please keep any conversation in one place on routing-discussion.

Erik Nordmark has kindly agreed to lead this design team.  The members of the design
team are:

  Erik Nordmark <nordmark <at> sonic.net>
  Jesse Gross <jgross <at> vmware.com>
  Jon Hudson <jon.hudson <at> gmail.com>
  Larry Kreeger (kreeger) <kreeger <at> cisco.com>
  Pankaj Garg <Garg.Pankaj <at> microsoft.com>
  Pat Thaler <pthaler <at> broadcom.com>
  Tom Herbert <therbert <at> google.com>

The mailing list, rgt-dt-encap-considerations <at> ietf.org, is closed but the archives are
publicly available at:

The Design Team is chartered as follows:

There have been multiple efforts over the years that have resulted in new or modified data plane behaviors involving encapsulations. That includes IETF efforts like MPLS, LISP, and TRILL but also industry efforts like Vxlan and NVGRE.  These collectively can be seen as a source of insight into the properties that data planes need to meet.  The IETF is currently working on potentially new encapsulations in NVO3 and SFC and considering working on BIER. In addition there is work on tunneling in the INT area.

This is a short term design team chartered to collect and construct useful advice to parties working on new or modified data plane behaviors that include additional encapsulations.  The goal is for the group to document useful advice gathered from interacting with ongoing efforts.  An Internet Draft will be produced for IETF92 to capture that advice, which will be discussed in RTGWG.

Data plane encapsulations face a set of common issues such as:

  * How to provide entropy for ECMP
  * Issues around packet size and fragmentation/reassembly
  * OAM - what support is needed in an encapsulation format?
  * Security and privacy.
  * QoS
  * Congestion Considerations
  * IPv6 header protection (non-zero UDP checksum over IPv6 issue)
  * Extensibility - e.g., for evolving OAM, security, and/or congestion control
  * Layering of multiple encapsulations e.g., SFC over NVO3 over BIER

The design team will provide advice on those issues. The intention is that even where we have different encapsulations for different purposes carrying different data, each such encapsulation doesn’t have to reinvent the wheel for the above common issues.

The design team will look across the routing area in particular at SFC, NVO3 and BIER. It will not be involved in comparing or analyzing any particular encapsulation formats proposed in those WGs and BoFs but instead focus on common advice.

Regards,
Alia

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Jeff Tantsura | 22 May 23:58 2015
Picon

Request for WG adoption of draft-rtg-dt-encap-02

Hi RTGWG,

The authors have requested the RTGWG to adopt draft-rtg-dt-encap-02 as
working group document.

Please indicate support or no-support by June 8, 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.

Cheers,
Jeff & Chris
Erik Nordmark | 22 May 18:40 2015
Picon

Fwd: New Version Notification for draft-rtg-dt-encap-02.txt


The design team has updated this document based on comments we received
in the meetings and hallways in the Dallas.

I think the chairs are planning to ask for WG adoption, so it would be
good for folks to take a look at the draft.

The change log section summarizes the changes:
    The changes from draft-rtg-dt-encap-01 based on feedback at the
    Dallas IETF meeting:
    o  Setting the context that not all common issues might apply to all
       encapsulations, but that they should all be understood before
       being dismissed.
    o  Clarified that IPv6 flow label is useful for entropy in
       combination with a UDP source port.
    o  Editorially added a "summary" set of bullets to most sections.
    o  Editorial clarifications in the next protocol section to more
       clearly state the three areas.
    o  Folded the two next protocol sections into one.
    o  Mention the MPLS first nibble issue in the next protocol section.
    o  Mention that viewing the next protocol as an index to a table with
       processing instructions can provide additional flexibility in the
       protocol evolution.
    o  For the OAM "don't forward to end stations" added that defining a
       bit seems better than using a special next-protocol value.
    o  Added mention of DTLS in addition to IPsec for security.
    o  Added some mention of IPv6 hob-by-hop options of other headers
       than potentially can be copied from inner to outer header.
    o  Added text on architectural considerations when it might make
       sense to define an additional header/protocol as opposed to using
       the extensibility mechanism in the existing encapsulation
       protocol.
    o  Clarified the "unconstrained TLVs" in the hardware friendly
       section.
    o  Clarified the text around checksum verification and full vs.
       header checksums.
    o  Added wording that the considerations might apply for encaps
       outside of the routing area.
    o  Added references to draft-ietf-pwe3-congcons,
       draft-ietf-tsvwg-rfc5405bis, RFC2473, and RFC7325
    o  Removed reference to RFC3948.
    o  Updated the acknowledgements section.
    o  Added this change log section.

    Erik (for the design team)

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-rtg-dt-encap-02.txt
Date: 	Thu, 21 May 2015 19:03:07 -0700
From: 	internet-drafts <at> ietf.org
To: 	Jon Hudson <jon.hudson <at> gmail.com>, Tom Herbert
<therbert <at> google.com>, Lawrence Kreeger <kreeger <at> cisco.com>, Patricia
Thaler <pthaler <at> broadcom.com>, Patricia Thaler <pthaler <at> broadcom.com>,
Jon Hudson <jon.hudson <at> gmail.com>, Albert Tian
<albert.tian <at> ericsson.com>, Jesse Gross <jgross <at> vmware.com>, Albert Tian
<albert.tian <at> ericsson.com>, Pankaj Garg <pankajg <at> microsoft.com>, Pankaj
Garg <pankajg <at> microsoft.com>, Tom Herbert <therbert <at> google.com>, Jesse
Gross <jgross <at> vmware.com>, Erik Nordmark <nordmark <at> arista.com>, Lawrence
Kreeger <kreeger <at> cisco.com>, Erik Nordmark <nordmark <at> arista.com>

A new version of I-D, draft-rtg-dt-encap-02.txt
has been successfully submitted by Erik Nordmark and posted to the
IETF repository.

Name:		draft-rtg-dt-encap
Revision:	02
Title:		Encapsulation Considerations
Document date:	2015-05-21
Group:		Individual Submission
Pages:		41
URL:            https://www.ietf.org/internet-drafts/draft-rtg-dt-encap-02.txt
Status:         https://datatracker.ietf.org/doc/draft-rtg-dt-encap/
Htmlized:       https://tools.ietf.org/html/draft-rtg-dt-encap-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-rtg-dt-encap-02

Abstract:
    The IETF Routing Area director has chartered a design team to look at
    common issues for the different data plane encapsulations being
    discussed in the NVO3 and SFC working groups and also in the BIER
    BoF, and also to look at the relationship between such encapsulations
    in the case that they might be used at the same time.  The purpose of
    this design team is to discover, discuss and document considerations
    across the different encapsulations in the different WGs/BoFs so that
    we can reduce the number of wheels that need to be reinvented in the
    future.

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

_______________________________________________
Rtg-dt-encap-considerations mailing list
Rtg-dt-encap-considerations <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations

draft-ietf-rtgwg-mrt-frr-algorithm-03

Hi Authors,

 

                Figure 18: Assigning direction to UNDIRECTED links,  I think for “each node x” should be “foreach node x in topo”

 

Run_Topological_Sort_GADAG(topo, root)

   Set_Block_Root_Incoming_Links(topo, root, MARK)

   foreach node x

      set x.unvisited to the count of x's incoming interfaces

          that aren't marked TEMP_UNUSABLE

   Initialize working_list to empty

   Initialize topo_order_list to empty

   add_to_list_end(working_list, root)

   while working_list is not empty

      y = remove_start_item_from_list(working_list)

      add_to_list_end(topo_order_list, y)

      foreach interface i of y

          if (i.OUTGOING) and (not i.TEMP_UNUSABLE)

             i.remote_node.unvisited -= 1

             if i.remote_node.unvisited is 0

                 add_to_list_end(working_list, i.remote_node)

   next_topo_order = 1

   while topo_order_list is not empty

      y = remove_start_item_from_list(topo_order_list)

      y.topo_order = next_topo_order

      next_topo_order += 1

   Set_Block_Root_Incoming_Links(topo, root, CLEAR)

 

 

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
Jeff Tantsura | 19 May 01:30 2015
Picon

FW: IETF hackathon

Dear RTGWG,

Happy to share - in Prague we will have a hackathon event:
http://www.ietf.org/blog/2015/05/ietf-hackathon/

Cheers,
Jeff

-----Original Message-----
From: Jari Arkko <jari.arkko <at> piuha.net>
Date: Sunday, May 17, 2015 at 2:17 AM
To: IETF WG Chairs <wgchairs <at> ietf.org>
Subject: IETF hackathon

>Chairs,
>
>I wanted to highlight that in Prague we will have a hackathon event:
>
>http://www.ietf.org/blog/2015/05/ietf-hackathon/
>
>Some of your working groups might have participants working actively on
>software who might benefit from some time together. Or could implement a
>small enhancement during the weekend. An opportunity for your
>consideration.
>
>Jari
>
Ben Campbell | 14 May 03:58 2015

Ben Campbell's No Objection on draft-ietf-rtgwg-mofrr-07: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-rtgwg-mofrr-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The following is a rant, and I do not expect any changes based on it
(edit: or even a response):

The security considerations are of the form of "No new considerations
beyond XXX". I have no opinion about the truth of that, but I wish draft
authors would, in general, include some supporting discussion when making
that sort of assertion.
Ben Campbell | 14 May 03:57 2015

Ben Campbell's No Objection on draft-ietf-rtgwg-mofrr-07: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-rtgwg-mofrr-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The following is a rant, and I do not expect any changes based on it:

The security considerations are of the form of "No new considerations
beyond XXX". I have no opinion about the truth of that, but I wish draft
authors would, in general, include some supporting discussion when making
that sort of assertion.
Stephen Farrell | 14 May 14:33 2015
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-rtgwg-mofrr-07: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-rtgwg-mofrr-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

What Ben said:-)
Joel Jaeggli | 14 May 04:16 2015

Joel Jaeggli's No Objection on draft-ietf-rtgwg-mofrr-07: (with COMMENT)

Joel Jaeggli has entered the following ballot position for
draft-ietf-rtgwg-mofrr-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

options 2-4 in section 5 assume a certain amount of flow or application
awareness that option 1 does not, option 1 is about control-plne awarness
of topology and it seems reasonable to make that distinction.
internet-drafts | 12 May 18:35 2015
Picon

I-D Action: draft-ietf-rtgwg-mofrr-07.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           : Multicast only Fast Re-Route
        Authors         : Apoorva Karan
                          Clarence Filsfils
                          IJsbrand Wijnands
                          Bruno Decraene
	Filename        : draft-ietf-rtgwg-mofrr-07.txt
	Pages           : 14
	Date            : 2015-05-12

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtgwg-mofrr-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mofrr-07

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/
Mike Shand | 7 May 12:15 2015
Picon

Mail regarding draft-decraene-rtgwg-backoff-algo

I have been assigned as Routing Directorate QA reviewer for this document.

The following web page contains a briefing on the QA process.

https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

The document is clear and concise and succinctly describes a proposed standardised SPF backoff algorithm.  This seems a useful step forward. The algorithm is not overly complex.

While suggested values for the various parameters are given, what is not clear to me is whether the intention is that these (or at least an agreed set) of these values are intended to be standardised as well as the algorithm. It would seem that different values might be suitable for different networks, but presumably the intention is that all the routers in a particular network SHOULD have the same values. Some discussion of this would be helpful.

I assume that "rib computation time" is the time that a RIB computation is to be (or was) STARTED? Obviously the FIB will not be updated for some time after this, in some cases for quite a long time after this! Does this delay need to be taken into account? I appreciate that in many cases it is difficult to ascertain reliably exactly when a FIB update has been completed.

In reading the document I spotted the following nits.

Intro para 3

"some back-off algorithm have"

presumably algorithms


and
"to enforce that all routers
   triggers their SPF

presumably trigger


Bottom of page 3
"SPF_DELAY back to INITAL_WAIT. e.g. 5 seconds."

obviously should be INITIAL_WAIT


4. Principle of SPG algorithm

3rd para

"and the while
   waiting for its stability,"

"and while waiting" would be better.


6 Impact on micro-loops

"FIB are installed"

The FIB is installed

or

FIBs are installed




Mike

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

Gmane