Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

From: Eric Gray <[email-masked]>
Date: Wed, 10 Dec 2014 16:53:21 +0000

Folks,

Raising this issue in case it has not been raised already on this list.

The issue is with an announcement made by one of the Routing ADs
of the appointment of a design team with intention to provide DLL
encapsulation and protocol designers with advice on common ways
to interact with IP encapsulation on a number of issues.

As I understand this, this is an effort that may have started with a draft
written in March of this year.  Pat Thaler is one of the 3 co-authors (with
Bob Briscoe from BT and John Kaippallimalil from Huawei) on that draft.

The current (-04) version of the above draft expired in September,
most likely because people wanted to figure out what to do about it
(and related work).

That draft is:
    “Guidelines for Adding Congestion Notification to Protocols that
      Encasulate IP”
    http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines

There is also the Deterministic Networking (DetNet) WG, which sits
somewhat squarely in the middle of the “QoS” aspect of IP transport
protocols).

And there is the recent BIER work that may possibly have an impact on
IP transport over a few data link technologies.

I assume there is also related work on ECMP entropy, packet size and
fragmentation, OAM, security/privacy, extensibility and IPv6 header
protection as indicated in Alia’s mail (see below).

Alia sets what is in my opinion the right tone (consistent with the draft
mentioned above) in saying that the intention is to provide advice on
possible common ways to deal with these issues at the data-link layer
and how they may interact with IP.

As long as the design team stays with the spirit of that tone, it is likely
there will be issues for IEEE 802.

I believe this needs to be on our issues list for IEEE/IETF cooperation,
and folks should keep an eye on it.

In particular, some folks have expressed concerns that this might be
view as implying that the IETF is expanding its charter to include DLL
design.  I do not see that, but that best way to deal with this as a
perception issue is to track the activity.

--
Eric

From: routing-discussion [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, December 09, 2014 5:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: routing area design team on dataplane encapsulation considerations

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:

  Albert Tian <[email-masked]<mailto:[email-masked]>>
  Erik Nordmark <[email-masked]<mailto:[email-masked]>>
  Jesse Gross <[email-masked]<mailto:[email-masked]>>
  Jon Hudson <[email-masked]<mailto:[email-masked]>>
  Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]>>
  Pankaj Garg <[email-masked]<mailto:[email-masked]>>
  Pat Thaler <[email-masked]<mailto:[email-masked]>>
  Tom Herbert <[email-masked]<mailto:[email-masked]>>

The mailing list, [email-masked]<mailto:[email-masked]>, is closed but the archives are
publicly available at:
   http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/current/maillist.html

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Dec 2014 12:26:16 -0500

Hi Eric,

> to interact with IP encapsulation on a number of issues.

I think the above is a mis-characterization of what Alia announced.  The
design team is looking at data-plane, not data link layer, encapsulation
within IETF protocols.  Think of protocols like MPLS and LISP or for
that matter IP over UDP-based tunnels.

Regards,
Brian

> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 10 Dec 2014 17:43:14 +0000

Brian,

	You are correct in terms of Alia's posting, though the distinction was a
subtle one that had escaped me - possibly because of the similarity in wording
of the advice draft, and the mention of specific DLL encapsulation technologies.

	In this case, the draft I mentioned is likely unrelated to the work that 
is proposed for the design team.

	It's also possible that I was reading into this some work that we might
need to do (though I suspect that it would be a more natural fit for Transport,
than for Routing) - as a generalization of the notions behind the advice draft.

	In addition to the issues with cooperation between L2 and L3 layers
for congestion management, there are likely to be similar issues with a number
of the topics that Alia had listed (ECMP, for example, has similar issues).

	I brought this up because a couple of IEEE 802.1 folks had read this as
if it was suggesting that the IETF is looking to tell DLL designers how to design
link layer encapsulations and protocols.

	I see now that they were even more wrong than I thought.  :-)

	Note, however, that we should at least consider whether or not we
should track the advice draft, and/or similar work...

--
Eric

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Wednesday, December 10, 2014 12:26 PM
To: [email-masked]
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Hi Eric,

On 12/10/14 11:53 AM, Eric Gray wrote:
> The issue is with an announcement made by one of the Routing ADs of 
> the appointment of a design team with intention to provide DLL 
> encapsulation and protocol designers with advice on common ways to 
> interact with IP encapsulation on a number of issues.

I think the above is a mis-characterization of what Alia announced.  The design team is looking at data-plane, not data link layer, encapsulation within IETF protocols.  Think of protocols like MPLS and LISP or for that matter IP over UDP-based tunnels.

Regards,
Brian

> 
> As I understand this, this is an effort that may have started with a 
> draft written in March of this year.  Pat Thaler is one of the 3 
> co-authors (with Bob Briscoe from BT and John Kaippallimalil from Huawei) on that draft.
> 
>     "Guidelines for Adding Congestion Notification to Protocols that
>       Encasulate IP"
>     
> somewhat squarely in the middle of the "QoS" aspect of IP transport 
> protocols).
> 
> protection as indicated in Alia's mail (see below).
> 
> Alia sets what is in my opinion the right tone (consistent with the 
> draft mentioned above) in saying that the intention is to provide 
> advice on possible common ways to deal with these issues at the 
> data-link layer and how they may interact with IP.
> 
> As long as the design team stays with the spirit of that tone, it is 
> likely there will be issues for IEEE 802.
> 
> I believe this needs to be on our issues list for IEEE/IETF 
> cooperation, and folks should keep an eye on it.
> 
> Erik Nordmark has kindly agreed to lead this design team.  The members 
> of the design team are:
> 
> The mailing list, 
> [email-masked]<mailto:[email-masked]>, is closed but the archives are publicly available at:
>    
> 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.

---

From: Pat Thaler <[email-masked]>
Date: Wed, 10 Dec 2014 18:41:56 +0000

Hi Eric,

The issues of getting things like OAM, congestion control and QOS to operate as desired over a mixed layer 2 and layer 3 forwarding network are similar to the issues of getting them to work over tunnels. In some cases, they overlap - particularly when the tunnels are layer 2 in layer 3 as NVGRE and VXLAN can be. The Encap design considerations also include some items that don't have analogs for layer 3 and layer 2 forwarding.

While the intent is trying to provide advice for all the IETF tunneling work, putting IEEE 802 in the loop by adding this to the coordination list would be reasonable.

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Wednesday, December 10, 2014 9:43 AM
To: Brian Haberman; [email-masked]
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Brian,

--
Eric

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Wednesday, December 10, 2014 12:26 PM
To: [email-masked]
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Hi Eric,

Regards,
Brian

---

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Dec 2014 14:22:25 -0500

Eric,

The intent is absolutely not to address DLL designers. It is to address the
on-going work
in the Routing Area for new encapsulations (NVO3, SFC, potentially BIER)
and to provide
advice and thought so that where things don't have to be done differently,
they aren't.  For
instance, we don't need three slightly different ways of handling OAM.

The drafts that you alluded to are not a basis for the design team's work.
Pat Thaler was
asked to be on the design team because of her experience in this area and
interest in the NVO3 work.

I'd be quite happy to discuss further and see what we can do to mitigate
this misunderstanding.

Regards,
Alia

On Wed, Dec 10, 2014 at 12:43 PM, Eric Gray <[email-masked]> wrote:

> within IETF protocols.  Think of protocols like MPLS and LISP or for that
> matter IP over UDP-based tunnels.
>
> Regards,
> Brian
>
> >
> > I've bcc'd nvo3, sfc, bier, and rtgwg as the most directly relevant.
> Please keep any conversation in one place on routing-discussion.
> >
> >   Albert Tian <[email-masked]<mailto:[email-masked]
> >>
> > [email-masked]<mailto:
> [email-masked]>, is closed but the archives are
> publicly available at:
> >
> > 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.
> >
> > 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
> >
> >
> >

---

From: Eric Gray <[email-masked]>
Date: Wed, 10 Dec 2014 23:18:11 +0000

Alia,

                I think it may be under control now.  ☺

The issue was that – when someone with a different background (with
perhaps less background in IP) sees a sweeping statement along the lines of –

  “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.”

- they start to feel slightly territorial/defensive.

                Looked at from an outsider’s perspective, it is not hard to see how this may
be interpreted to mean “we’ve solved a bunch of problems and want to suggest
that you use our solution when solving similar problems.”

                The subtlety in this case (at least for me) is that the intersection between the
topics indicated and the ones that have been worked on (and, in some cases, been
something of a problem) at multiple layers (read “multiple encapsulations”) is fairly
substantial.

                As Pat said already, it certainly includes OAM, QoS and congestion avoidance.
As someone else pointed out privately, it also includes multi-pathing (which is usually
a touchy subject in any context), like ECMP and LAG.  And of course, security is also an
area of significant overlap.

                The degree of coincidental congruency is extraordinary, but understandable
when you consider that you’re bringing these issues up because they are always
coming up in a similar context.

                In any case, when looked at as Brian pointed out, it is clear that none of this
was included in what you were talking about.

                This is largely a matter of spin.

I’ve tried to make that clearer to some others…

--
Eric

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, December 10, 2014 2:22 PM
To: Eric Gray
Cc: Brian Haberman; [email-masked]
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations
Importance: High

Eric,

The intent is absolutely not to address DLL designers. It is to address the on-going work
in the Routing Area for new encapsulations (NVO3, SFC, potentially BIER) and to provide
advice and thought so that where things don't have to be done differently, they aren't.  For
instance, we don't need three slightly different ways of handling OAM.

The drafts that you alluded to are not a basis for the design team's work.  Pat Thaler was
asked to be on the design team because of her experience in this area and interest in the NVO3 work.

I'd be quite happy to discuss further and see what we can do to mitigate this misunderstanding.

Regards,
Alia

On Wed, Dec 10, 2014 at 12:43 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

--
Eric

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Haberman
Sent: Wednesday, December 10, 2014 12:26 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Hi Eric,

Regards,
Brian

> From: routing-discussion [mailto:[email-masked]<mailto:[email-masked]>]
> On Behalf Of Alia Atlas
> To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>   Albert Tian <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Erik Nordmark <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Jesse Gross <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Jon Hudson <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Pankaj Garg <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Pat Thaler <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>   Tom Herbert <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>
> The mailing list,
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>, is closed but the archives are publicly available at:
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
ieee-ietf-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: Alia Atlas <[email-masked]>
Date: Wed, 10 Dec 2014 18:21:00 -0500

Eric,

Thanks for helping clarify this to others!
I'll be more careful in phrasing that of course this is at the IP or MPLS
layer.
The WGs or BoFs mentioned (NVO3, SFC, BIER) are all doing that.

Alia

On Wed, Dec 10, 2014 at 6:18 PM, Eric Gray <[email-masked]> wrote:

>  Alia,
>
>
>
>                 I think it may be under control now.  J
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, December 10, 2014 2:22 PM
> *To:* Eric Gray
> *Cc:* Brian Haberman; [email-masked]
> *Subject:* Re: [ieee-ietf-coord] routing area design team on dataplane
> encapsulation considerations
> *Importance:* High
>
>
>
> Eric,
>
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2014 06:52:30 +0000

Hi,

I was watching this dialog for the last 24 hours or such, I believe that the issues are now quite clear. I suggest to put the topic on the agenda of our next IEEE-IETF coordination call – we can decide by then if there is a need for a specific follow-up and action items.

Regards,

Dan

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, December 11, 2014 1:21 AM
To: Eric Gray
Cc: Brian Haberman; [email-masked]
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Eric,

Thanks for helping clarify this to others!
I'll be more careful in phrasing that of course this is at the IP or MPLS layer.
The WGs or BoFs mentioned (NVO3, SFC, BIER) are all doing that.

Alia

On Wed, Dec 10, 2014 at 6:18 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

--
Eric

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, December 10, 2014 2:22 PM
To: Eric Gray
Cc: Brian Haberman; [email-masked]<mailto:[email-masked]>
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations
Importance: High

Eric,

Regards,
Alia

--
Eric

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Haberman
Sent: Wednesday, December 10, 2014 12:26 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [ieee-ietf-coord] routing area design team on dataplane encapsulation considerations

Hi Eric,

Regards,
Brian

> http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_html_draft-2Dbriscoe-2Dtsvwg-2Decn-2Dencap-2Dguidelines&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PTPwxe_eQYV1LJGinlxjZ42qtnsld0zlbcgw-qFEls8&s=BNJhNlDB3Yf-G5NWL9LtXMjY_dzwtyaFxudi48tKeIk&e=>
>
> http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/curre<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_mail-2Darchive_web_rtg-2Ddt-2Dencap-2Dconsiderations_curre&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PTPwxe_eQYV1LJGinlxjZ42qtnsld0zlbcgw-qFEls8&s=_PY0eXPkFR46Fl3zPRGDAXLHTG_G2XNVjiuO3QINC8U&e=>
> nt/maillist.html
>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ieee-2Dietf-2Dcoord&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PTPwxe_eQYV1LJGinlxjZ42qtnsld0zlbcgw-qFEls8&s=uQ2xlwiuRX7l9l1jIORlEflFH-D-V2wuOn869macLuA&e=>
>

_______________________________________________
ieee-ietf-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ieee-2Dietf-2Dcoord&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PTPwxe_eQYV1LJGinlxjZ42qtnsld0zlbcgw-qFEls8&s=uQ2xlwiuRX7l9l1jIORlEflFH-D-V2wuOn869macLuA&e=>