Encapsulating MPLS in UDP
draft-ietf-mpls-in-udp-11

Notification list changed to mpls@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-in-udp@ietf.org, draft-ietf-mpls-in-udp.ad@ietf.org, draft-ietf-mpls-in-udp.shepherd@ietf.org, loa@pi.nu from mpls-chairs@ietf.org, draft-ietf-mpls-in-udp@ietf.org, "Loa Andersson" <loa@pi.nu>, mpls@ietf.org

[Ballot discuss]

I think you're missing a little bit of spec needed for the
MPLS with DTLS case. (Are there implementations of the DTLS
stuff btw?)

1) I assume the intent is that the MPLS-with-DTPS port
(TBD2) is only ever used with DTLS, in which case don't you
need a MUST or MUST NOT somewhere?

2) Is a single listener on port TBD2 supposed to handle just
one DTLS session with one LSR or many DTLS sessions with
each LSR that's on a different host/port or something else?
Don't you need to say?

[Ballot comment]
- An editorial detail in the abstract. Take it or leave it
  The MPLS-in-UDP encapsulation technology must only be deployed within a
  single network (with a single network operator) or networks of an
  adjacent set of co-operating network operators where traffic is
  managed to avoid congestion, rather than over the Internet where
  congestion control is required.

We rarely see specifications ("must" sentences) in abstracts.
Do you want to say something like:
  The MPLS-in-UDP encapsulation applicability is for networks where
  traffic is managed to avoid congestion, rather than over the Internet
  where congestion control is required.

[Ballot comment]
Thanks to all involved for working through the issues with congestion and zero checksums. I'm happy to ballot Yes on this version (while watching Martin's Discuss out of the corner of my eye).

[Ballot discuss]
The draft improved a lot and I am on no-objection after discussing the point below:

The UDP source port is randomly chosen and I guess not further retained (*) for receiving incoming MPLS-over-UDP packets. In turn this means that "returning" packets are sent to the MPLS/UDP port number.

(*) nobody is listening on that UDP port.

This will cause issues when NATs/firewalls are in-between, as the return traffic, i.e., the traffic incoming from the public part of the NAT, is not matching any NAT binding that was created before by an outgoing packet. Similar for firewalls as no state was created when the packet traversed the firewall.

NATs are probably not a big issue in a carrier net, but firewalls will for sure. I guess this should be mentioned as an operational note.

[Ballot comment]
Thanks for clarifying my concerns that we aren't missing a case of upstream-assigned labels in a unicast tunnel.  We only really need upstream-assigned labels if the tunnel itself is multi-access.

[Ballot discuss]
I am still waiting for this review comment to be resolved.

In Sec 4, it says:
"That is to say, if the destination IP address is a multicast address, the top label SHOULD be upstream-assigned, otherwise if the destination IP address is a ..."  This seems to require that the IP network is capable of supporting multicast where one can easily see using MPLS-in-UDP tunnels to provide point-to-point tunnels.  Is there a reason that the negotiation mechanism to set up the MPLS-in-UDP tunnel wouldn't also be able to specify alternate destination IP addresses for upstrteam-assigned?  How much discussion and agreement has this limitation had??

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-in-udp-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about the Actions requested in the IANA Considerations section of this document.

For IETF stream documents, the requested port numbers will follow
the IETF I-D process and the assignments will be reviewed
and approved by IESG under the "IETF Review" process, the "IESG
Approval" process.

IANA understands that, upon approval of this document, there are two port numbers being requested.

These requests are as follows:

Service Name : MPLS-in-UDP
Transport Protocol(s) : UDP
Assignee: IESG
Contact : IETF Chair .
Description : Encapsulate MPLS packets in UDP tunnels.
Reference : [ RFC-to-be ]
Port number: [ TBD1 ]

Service Name : MPLS-in-UDP-with-DTLS
Transport Protocol(s) : UDP
Assignee: IESG
Contact : IETF Chair .
Description : Encapsulate MPLS packets in UDP tunnels with DTLS.
Reference : [ RFC-to-be ]
Port number: [ TBD2 ]

QUESTION: the second requested service name is invalid according
to RFC6335.  http://tools.ietf.org/html/rfc6335#section-5.1
defines the service name syntax.

Valid service names are hereby normatively defined as follows:

  o  MUST be at least 1 character and no more than 15 characters long

  o  MUST contain only US-ASCII [ANSI.X3.4-1986] letters 'A' - 'Z' and
      'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or
      decimal 45)

  o  MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')

  o  MUST NOT begin or end with a hyphen

  o  hyphens MUST NOT be adjacent to other hyphens

Also,

Service names are case-insensitive; they may be
      provided and entered into the registry with mixed case for
      clarity, but case is ignored otherwise.

Please revise the service name in the next version.

IANA understands that these two actions are the only ones which need
to be completed upon approval of this document using the "IETF Review"
process.

If however early assignment is required, authors should submit
online templates for each port for Expert review as we advised
in June 2013.  Keep in mind, when using Expert Review, the document
should be stalled until the expert review is completed before go
to the Approval stage. Please see RFC 6335.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Encapsulating MPLS in UDP) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Encapsulating MPLS in UDP'
  as Proposed Standard

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@ietf.org mailing lists by 2015-01-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies an IP-based encapsulation for MPLS, called
  MPLS-in-UDP (User Datagram Protocol) for situations where UDP
  encapsulation is preferred to direct use of MPLS, e.g., to enable
  UDP-based ECMP (Equal Cost Multi-Pathing) or link aggregation.  MPLS-
  in-UDP is primarily applicable to service provider networks, and
  additional restrictions apply to MPLS-in-UDP usage for traffic that
  is not congestion controlled and to UDP zero checksum usage with
  IPv6.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ballot/


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

  http://datatracker.ietf.org/ipr/1941/
  http://datatracker.ietf.org/ipr/2198/

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol).

Working Group Summary

There is WG consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Loa Andersson is the Document Shepherd.
Alia Atlas is the Responsible Area Director.

Note: Until recently Ross Callon was the Document Shepherd, but as
part of the IETF Last Call process he became an author.
During the same process Adrian Farrel (former responsible AD) contributed
key text on Congestion Control and has been listed as contributor.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

Ross as Shepherd:
The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes that
it is ready for publication.

Loa as Shepherd:
The current shepherd was involved in the process to adopt this as a wg document
and reviewed the document carefully at that time. In the intermediate period the
reviews has been limited to folow what has been going on. The shepherd has
re-read version -08 now and agree with the former shepherd's assessment.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document has been well reviewed. It was reviewed by the MPLS Review Team. The IETF last call and discussions in the Transport area revealed concerns related
to congestion control and use of the UDP checksum.  A joint team of routing and
transport area experts and document authors have carefully reviewed and updated
the document to relieve these concerns.
No further review is felt necessary other than a repeat of the  IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

Don't know exactly where to place this. The document had - when publication was
requested - five authors. The process to resolve the IETF LC comments added two
new authors and one contributor, We have, after consulting with the authors, moved
two of the original authors to the contributor section.
 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors and contributors have indicated that they are not aware of any other IPR
that applies to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last calls.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs or BCPs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol).

Working Group Summary

There is WG consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Loa Andersson is the Document Shepherd.
Alia Atlas is the Responsible Area Director.

Note: Until recently Ross Callon was the Document Shepherd, but as
part of the IETF Last Call process he became an author.
During the same process Adrian Farrel (former responsible AD) contributed
key text on Congestion Control and has been listed as contributor.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

Ross as Shepherd:
The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes that
it is ready for publication.

Loa as Shepherd:
The current shepherd was involved in the process to adopt this as a wg document
and reviewed the document carefully at that time. In the intermediate period the
reviews has been limited to folow what has been going on. The shepherd has
re-read version -08 now and agree with the former shepherd's assessment.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document has been well reviewed. It was reviewed by the MPLS Review Team. The IETF last call and discussions in the Transport area revealed concerns related
to congestion control and use of the UDP checksum.  A joint team of routing and
transport area experts and document authors have carefully reviewed and updated
the document to relieve these concerns.
No further review is felt necessary other than a repeat of the  IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

Don't know exactly where to place this. The document had - when publication was
requested - five authors. The process to resolve the IETF LC comments added two
new authors and one contributor, We have, after consulting with the authors, moved
two of the original authors to the contributor section.
 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors and contributors have indicated that they are not aware of any other IPR
that applies to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last calls.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs or BCPs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol).

Working Group Summary

There is WG consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Loa Andersson is the Document Shepherd.
Alia Atlas is the Responsible Area Director.

Note: Until recently Ross Callon was the Document Shepherd, but as
part of the IETF Last Call process he became an author.
During the same process Adrian Farrel (former responsible AD) contributed
key text on Congestion Control and has been listed as contributor,

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

Ross as Shepherd:
The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes that
it is ready for publication.

Loa as Shepherd:
The current shepherd was involved in the process to adopt this as a wg document
and reviewed the document carefully at that time. In the intermediate period the
reviews has been limited to folow what has been going on. The shepherd has
re-read version -08 now and agree with the former shepherd's assessment.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document has been well reviewed. It was reviewed by the MPLS Review Team. The IETF last call and discussions in the Transport area revealed concerns related
to congestion control and use of the UDP checksum.  A joint team of routing and
transport area experts and document authors have carefully reviewed and updated
the document to relieve these concerns.
No further review is felt necessary other than a repeat of the  IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

Don't know exactly where to place this. The document had - when publication was
requested - five authors. The process to resolve the IETF LC comments added two
new authors and one contributor, We have, after consulting with the authors, moved
two of the original authors to the contributor section.
 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors and contributors have indicated that they are not aware of any other IPR
that applies to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last calls.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs or BCPs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol).

Working Group Summary

There is WG consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Loa Andersson is the Document Shepherd.
Alia Atlas is the Responsible Area Director.

Note: Until recently Ross Callon was the Document Shepherd, but as
part of the IETF Last Call process he became an author.
During the same process Adrian Farrel (former responsible AD) contributed
key text on Congestion Control and has been listed as contributor,

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

Ross as Shepherd:
The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes that
it is ready for publication.

Loa as Shepherd:
The current shepherd was involved in the process to adopt this as a wg document
and reviewed the document carefully at that time. In the intermediate period the
reviews has been limited to folow what has been going on. The shepherd has
re-read version -08 now and agree with the former shepherd's assessment.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document has been well reviewed. It was reviewed by the MPLS Review Team. The IETF last call and discussions in the Transport area revealed concerns related
to congestion control and use of the UDP checksum.  A joint team of routing and
transport area experts and document authors have carefully reviewed and updated
the document to relieve these concerns.
No further review is felt necessary other than a repeat of the  IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

Don't know exactly where to place this. The document - at publication requested
- had five authors. The process to resolve the IETF LC comments

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors and contributors have indicated that they are not aware of any other IPR
that applies to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last calls.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs or BCPs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol).

Working Group Summary

There is WG consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Loa Andersson is the Document Shepherd.
Adrian Farrel is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team and the joint Transport and Routing/MPLS
team. This is a relatively simple protocol and the document shepherd believes that
it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document has been well reviewed. It was reviewed by the MPLS Review Team. The
IETF last call and discussions in the Transport area revealed concerns related to congestion
control and use of the UDP checksum.  A joint team of routing and transport area experts
and document authors have carefully reviewed and updated the document to relieve
these concerns. No further review is felt necessary other than a repeat of the  IETF last call.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors have indicated that they are not aware of any other IPR that applies to this
document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last calls.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understands the document. There are multiple people in favor,
one person was earlier opposed, and a significant number of people are neutral.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs or BCPs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. Two UDP
Port numbers will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.



=== Note below you'll find the earlier version of the write-up ======
======== kept her temporarily for reference reasons ===========

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol). It also  describes the applicability of this encapsulation
in presence of other IP-based encapsulations for MPLS. This encapsulation allows for
two Label Switching Routers (LSR) to be adjacent on a Label Switched Path (LSP),
while separated by an IP network.

Working Group Summary

There is consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Ross Callon is the Document Shepherd.
Adrian Farrel is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team. This is a relatively simple protocol and the
document shepherd believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document was reviewed by the MPLS Review Team. No further review is felt
necessary (other than the normal IETF last call).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors have indicated that they are not aware of any other IPR that applies to this
document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last call.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands the document. There are multiple people in favor,
one person opposed, and a significant number of people who are neutral. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals. 

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. One UDP
Port number will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

his document seems to have addressed all of the substantive comments made in IETF last call. It is currently in a new WG last call (due to end December 8th) and will then go through another IETF last call

We will need a revised I-D to capture the results of the discussions with the Transport Area at IETF-89. The AD has pledged to help with text.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol). It also  describes the applicability of this encapsulation
in presence of other IP-based encapsulations for MPLS. This encapsulation allows for
two Label Switching Routers (LSR) to be adjacent on a Label Switched Path (LSP),
while separated by an IP network.

Working Group Summary

There is consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment.
One or more other vendors are believed to be either implementing or planning to
implement. The document has been well reviewed.

Personnel

Ross Callon is the Document Shepherd.
Adrian Farrel is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team. This is a relatively simple protocol and the
document shepherd believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document was reviewed by the MPLS Review Team. No further review is felt
necessary (other than the normal IETF last call).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors have indicated that they are not aware of any other IPR that applies to this
document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last call.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands the document. There are multiple people in favor,
one person opposed, and a significant number of people who are neutral. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals. 

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. One UDP
Port number will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is clearly marked on the title page. This is appropriate since
this documents a protocol standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies an IP-based encapsulation for MPLS, referred to as MPLS-in-
UDP (User Datagram Protocol). It also  describes the applicability of this encapsulation
in presence of other IP-based encapsulations for MPLS. This encapsulation allows for
two Label Switching Routers (LSR) to be adjacent on a Label Switched Path (LSP),
while separated by an IP network.

Working Group Summary

There is consensus to progress this document.

Document Quality

There are at least three existing implementations of the protocol, and some deployment. One or more other vendors are believed to be either implementing or planning to implement. The document has been well reviewed.

Personnel

Ross Callon is the Document Shepherd.
Adrian Farrel is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

The document shepherd has read the document and has also checked the reviews
that we done by the MPLS review team. This is a relatively simple protocol and the
document shepherd believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

This document was reviewed by the MPLS Review Team. No further review is felt
necessary (other than the normal IETF last call).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes. One IPR disclosure was filed on the individual document before it was considered
for adoption as a WG document, and was reissued to apply to the WG document. All
authors have indicated that they are not aware of any other IPR that applies to this
document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure was filed and was mentioned in the call for adoption and in the
WG last call.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG as a whole understands the document. There are multiple people in favor,
one person opposed, and a significant number of people who are neutral. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

There are no threats of appeals. 

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No IDnits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative reference are already RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

All normative references are to Standards Track RFCs.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA section looks correct and appropriate to the document shepherd. One UDP
Port number will need to be assigned.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no formal language in the document.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-in-udp-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about the Actions requested in the IANA Considerations section of this document.

For IETF stream documents, the requested port numbers will follow
the IETF I-D process and the assignments will be reviewed
and approved by IESG under the "IETF Review" process, the "IESG
Approval" process.

IANA understands that, upon approval of this document, there are two port numbers being requested.

These requests are as follows:

Service Name : MPLS-in-UDP
Transport Protocol(s) : UDP
Assignee: IESG
Contact : IETF Chair .
Description : Encapsulate MPLS packets in UDP tunnels.
Reference : [ RFC-to-be ]
Port number: [ TBD ]

Service Name : MPLS-in-UDP with DTLS
Transport Protocol(s) : UDP
Assignee: IESG
Contact : IETF Chair .
Description : Encapsulate MPLS packets in UDP tunnels with DTLS.
Reference : [ RFC-to-be ]
Port number: [ TBD ]

QUESTION: the second requested service name is invalid according
to RFC6335.  http://tools.ietf.org/html/rfc6335#section-5.1
defines the service name syntax.  Please revise the service name
in the next version.

IANA understands that these two actions are the only ones which need
to be completed upon approval of this document using the "IETF Review"
process. 

If however early assignment is required, authors should submit
online templates for each port for Expert review as we advised
in June 2013.  Keep in mind, when using Expert Review, the document
should be stalled until the expert review is completed before go
to the Approval stage.  Please see RFC 6335, section 8.1.1:

IANA MAY accept early assignment [RFC4020] requests (known as "early
allocation" therein) from IETF working groups that reference
a sufficiently stable Internet-Draft instead of a published
Standards-Track RFC.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Encapsulating MPLS in UDP) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Encapsulating MPLS in UDP'
  as Proposed Standard

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@ietf.org mailing lists by 2014-01-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document specifies an IP-based encapsulation for MPLS, called
  MPLS-in-UDP (User Datagram Protocol).


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp/ballot/


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

  http://datatracker.ietf.org/ipr/1941/
  http://datatracker.ietf.org/ipr/2198/

AD review
=======

Hi authors of draft-ietf-mpls-in-udp,

I have performed my usual AD review of your document following the
publication request from the working group. The purpose of this
review is to catch and fix any issues as early in the process as
possible.

There are a number of concerns listed below. Some are minor editorial
points, and a good number of the rest can be handled by the simple
addition of text to describe things that I believe need extra words.
a few of the issues are a little more significant and need direct
discussion or modification of the draft.

I am not requiring changes, but we do need to talk about any of the
points that you don't think need to be addressed by updates to the
document.

Thanks for your work,
Adrian

---

It seems to me that the issue raised by Sri on the mailing list during
WG last call was not addressed. Maybe it was not of concern to this
working group because you are only interested in encapsulating MPLS.

The question asked, however, seems to be very valid for the people
charged with looking after UDP port allocation and the future use of
UDP. It can be summarised as:

  What would happen if every protocol asked for a port number to
  encapsulate it? Why don't you ask for a single port number to indicate
  "there is a payload protocol" and insert a shim to identify and demux
  the payload?

I don't have a view on this, but I don't see that the WG either
discussed the issue or asked for input from the TSV area. I have asked
the TSV ADs to solicit input from the TSV directorate and the Port
Doctors. You should not wait for this input (which may come any time
between now and the end of IESG evaluation, but you should consider the
issue and be prepared to discuss with the reviewers.

---

Abstract

  This document specifies an additional IP-based encapsulation for
  MPLS, referred to as MPLS-in-UDP (User Datagram Protocol), which is
  applicable in some circumstances. This document only describes the
  MPLS-in-UDP encapsulation.

"Additional" to what?

Why "referred to as"? Isn't that exactly what it is?

The second sentence seems redundant since the first sentence say exactly
that.

"...applicable in some circumstances" says nothing, of course. Either
don't say this, or explicitly state the circumstance. Since (see below)
the applicability is very specific and there is a clear use case that is
the target of your work, I strongly suggest that you call out this case
in the Abstract.

---

Introduction

Many of the same comment apply here as I noted for the Abstract, but in
addition:

  This document specifies an additional IP-based encapsulation for
  MPLS, referred to as MPLS-in-UDP (User Datagram Protocol). It also
  describes the applicability of this encapsulation in presence of
  other IP-based encapsulations for MPLS.

s/presence/the presence/

  This encapsulation allows for two Label Switching Routers (LSR) to
  be adjacent on a Label Switched Path (LSP), while separated by an
  IP network.

This makes it sound like a new feature, but (of course) MPLS-in-IP and
MPLS-in-GRE allows this as well.
 
  In order to support this encapsulation, each LSR needs
  to know the capability to decapsulate MPLS-in-UDP by the remote
  LSRs. This specification defines only the data plane encapsulation
  and does not concern itself with how the knowledge to use this
  encapsulation is conveyed.

While this a fundamentally reasonable thing to say, it also makes the
encapsulation entirely unusable. Since implementations already exist,
perhaps you could tell us how this works. I suspect that in some
environments the ability exist de facto (in other words, all devices are
capable) while in other environments it is configured. You could say
this and then suggest that distribution of this capability between
participating nodes is for future study.

  An applicability statement will compare situations in which using
  the MPLS-in-UDP encapsulation might be advantageous over other IP-
  based encapsulations for MPLS. One of the key considerations in
  this respect is how to achieve efficient load-balance of traffic
  over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group
  (LAG).

I don't understand this paragraph. Are you saying that a future document
might be written? That isn't very helpful!

It appears that you are trying to say "This encapsulation is better than
other encapsulations" but without actually demonstrating it. Either
delete this paragraph or actually do the work by adding a section to
this document.

---

Section 1

There is quite a lot missing from this section. I don't mind whether the
information goes in the main part of Section 1 or in Section 1.2, but it
needs to show up.

- What environment / use case is this work targeted at?
- Forward reference to the Security section and a note about the non-
  availability of security. This is key since the applicability of this
  is significantly restricted by this feature.
- Brief overview of the mechanism (which is very simple, so doesn't need
  more than a sentence mentioning "direct encapsulation", "use of dest
  port" and a high-level observation about using the source port for
  entropy and why.

---

Section 1.1

  Currently, there are a number of IP-based encapsulations for MPLS.
  These include MPLS-in-IP, MPLS-in- GRE (Generic Routing
  Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer Two Tunneling
  Protocol - Version 3)[RFC4817]. In all these methods, the IP
  addresses can be varied to achieve load-balancing.

"These include..." implies you know of others. What are they and why
haven't you mentioned them?

I think the statement about varying the IP addresses could be clearer.
Probably by saying how this is done (since simply picking another
destination address may balance the load by sending it somewhere else
:-)

---

Section 1.1

  In terms of MPLS-based encapsulations, load-balancing is achieved
  with the introduction of the Entropy Label [RFC6790]. 

I think you need to delete the word "encapsulations".

---

Section 1.2

s/ECMP paths/ECMPs/

---

Section 1.2

As noted above, the explanation in this section is very sparse and could
benefit from additional material.

---

Section 3 Source Port of UDP

I think this description needs to describe how a source behaves when the
flow does not need entropy.

Furthermore, the text is not clear about the objective of "providing
entropy". What type of algorithm should the source use and what must it
not do?

                For example, the
                entropy value can be generated by performing hash
                calculation on certain fields in the customer packets
                (e.g., the five tuple of UDP/TCP packets).

I find this to be a poor example because the source has in hand an MPLS
packet with an arbitrary label stack and an unknown payload. Indeed,
your Section 5 notes that the MPLS payload might not be TCP or UDP.

---

Section 3 Destination Port of UDP

The text about upstream/downstream label assignment is perfectly fine,
but doesn't belong in the description of this field.

---

Section 3 UDP Checksum 

I note that RFC 6935 says that using a zero UDP checksum for a UDP
tunnel is appropriate when the payload protocol header includes its own
protection. MPLS headers do not contain this form of protection. How do
you justify the zero checksum in this case?

I also don't think that proper attention has been paid to Section 5 of
RFC 6936. You need to examine the requirements and describe additional
behavior within your document.

---

Section 4

  As for other common processing procedures associated with tunneling
  encapsulation technologies including but not limited to Maximum
  Transmission Unit (MTU) and preventing fragmentation and reassembly,
  Time to Live (TTL) and differentiated services, the corresponding
  "Common Procedures" defined in [RFC4023] which are applicable for
  MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed. 

I think it is probably important to consider PMTU in the presence of
ECMP (probably not necessary in the case of LAG). How does the source
know the PMTU for each different value of the source port that it might
apply?

---

As far as I can see Section 5 is not ECN-friendly and says that when the
payload protocol of the MPLS packet is not "TCP-friendly" the
application generating the packets must use magic to avoid swamping the
network.

We will see what the TSV area congestion experts have to say, but I
think we will find that the approach here is simplistic unless the
network across which the UDP tunnel runs is used for no other traffic
except UDP tunnels carrying MPLS packets.

---

Section 6 seems to indicate a major draw-back of this scheme. You have
to note that MPLS networks are able to get away with having very little
security because it is very hard to inject MPLS packets into a network.
But MPLS-in-(foo-in-)IP encapsulation provides a way to inject packets
just like any packet can be injected into an IP network.

Security (such as IPsec) provides a way to ensure that rogue packets do
not have their headers stripped and their payload MPLS packets added to
an LSP.

You are making a clear statement that using IPsec means that there is no
point in doing MPLS-in-UDP encapsulation. You need to follow up on this!

The first thing to do is to enhance the applicability text in Section 1
to say where you would deploy this such that security is not an issue.

The second thing is to talk about the security mechanisms that can be
applied at the edges of the network to reduce the likelihood of such
attacks being possible.

Lastly (or probably firstly!) you need to describe the attack vector and
the implications of such an attack so that the implementer/deployer is
clear what the risks are.

---

10.1

RFC 4023 needs to be a normative reference since you rely on it to
describe how to set TTL and avoid fragmentation.