Skip to main content

Label Edge Router Forwarding of IPv4 Option Packets
draft-ietf-mpls-ip-options-07

Yes

(Adrian Farrel)
(Jari Arkko)

No Objection

(Alexey Melnikov)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)

Note: This ballot was opened for revision 07 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Ron Bonica Former IESG member
(was Discuss) Yes
Yes (2010-12-14) Unknown
- In the introduction, you say

"The IP packet header provides for various IP options as originally specified in [RFC791]." 

Not all options are defined in 791. Some are defined in RFCs 1191, 1385, 1393, 2213, and 4782.

- In the introduction, you say

"IP options extend the IP packet header length beyond the minimum of 20 octets.  As a result, IP  packets received with header options are typically handled as exceptions and in a less efficient manner due to their variable length and complex processing requirements.  For example, many router implementations, punt such IP option packets from the hardware forwarding (fast) path into the software forwarding (slow) path causing high CPU utilization."

Even when the forwarding plane can parse a variable length header, it still needs to punt to the control plane, because the forwarding plane may not have the clock cycles or intelligence required to process the option.

- in the introduction, your use of the word "transparent" is imprecise. Transparent means that you can see one thing through another (e.g., glass is transparent). IP options are not transparent when encapsulated in MPLS. MPLS would be transparent if you could see the IP header through it.

- In Section 4, you say:

When processing of signaling messages or data packets with more specific forwarding rules is enabled, this policy  SHOULD NOT alter the specific processing rules. 

What are these more specific forwarding rules?

Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2010-12-16) Unknown
I support Ron's DISCUSS and item #1 in David's DISCUSS
David Harrington Former IESG member
(was Discuss) No Objection
No Objection (2010-12-14) Unknown
Please consider addressing the issues rasied in the TSVDIR review by James Polk:

I've reviewed this document as part of the transport area 
directorate's ongoing effort to review key IETF documents. These 
comments were written primarily for the transport area directors, but 
are copied to the document's authors for their information and to 
allow them to address any issues raised. The authors should consider 
this review together with any other last-call comments they receive. 
Please always CC <mailto:tsv-dir@ietf.org>tsv-dir@ietf.org if you 
reply to or forward this review.

Summary:
This is a well written, concise and needed modification to MPLS.

That said, I don't understand why the 1st minor issue below is 
present. Recommend (fairly strongly) adding the

     "Document Updates: RFC 3031, RFC 3032"

as mentioned below on this first page of this RFC to be.


Transport Issues:
There are no issues


minor issues:
- S2 "Motivation", last sentence is

   "We believe that this document adds
   details that have not been fully addressed in [RFC3031] and [RFC3032]
   as well as complements [RFC3270], [RFC3443] and [RFC4950]. "

I find it surprising that this document does not formally update 3031 
and 3032, given that it is mandatory to implement, optional to 
invoke. ISTM, as an outsider to MPLS, this would in fact be the case 
given the impact of/to IP stacks not adhering to this proposed standard.

- Section 5.2 is about Router Alert Options, and states "At the time 
of this writing ...". I wonder if this subsection is valid, or needs 
another review against this IntArea ID
http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02
to still be valid in a month or two once the IntArea ID (currently in 
WGLC) is processed by the IESG and RFC-Editor?

IMO - these two docs are progressing near enough to each other to 
each consider what the other says - with or without a normative or 
informative reference in either or both docs to the other.

[dbh: the draft-ietf-intarea-router-alert-considerations draft does reference the mpls-ip-options draft as an example of tunneling to avoid RAO. The two drafts are closely linked, and authors should watch closely to make sure they stay in sync through the approval/publication process.]

nits:
- I'm surprised to see the Abstract on page 2. I thought we 
collectively fixed the case in which the Abstract can be on any page 
other than page 1.

- at the page Footer, in the middle of the line, there isn't a "short 
document name" - which has been there on all previous well formed IDs 
and RFCs that I have seen (which of course is not all of them). It is 
recommended the authors pick a short form name for the subject of 
this doc for this location, such as

      LER Header Option Behaviors

- S3, 4th para, second to last sentence is:

   "First a downstream LSR may
   have not have sufficient IP routing information to forward the packet
   resulting in packet loss. "

recommend removing the first instance of "have". The sentence reads 
better without it.

- S3, 4th para, last two sentences
list a "First" and a "Second" reason correctly, but are missing 
required commas after each word (i.e., "First, ...", and "Second, ..." )

- S3, 5th para, 1st sentence is lacking commas here:

   "...FEC, yet are forwarded
   into an IP/MPLS network without being MPLS-encapsulated,
    present..."

- S5.1, last bullet has this:

   "...MPLS encapsulation at a ingress LER ..."
                           ^^^^^
s/a/an

James
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2010-12-16) Unknown
INTRODUCTION, paragraph 4:
>   Requirements for Label Edge Router Forwarding of IPv4 Option Packets

  This document isn't really about requirements, it specifies a required
  behavior. Suggest to drop "Requirements for" from the title.


INTRODUCTION, paragraph 7:
>    This document specifies how Label Edge Routers (LER) should behave
>    when determining whether to MPLS encapsulate an IP packet with header
>    options.

  Although it's clear from the the title that this document is for IPv4,
  it would be good to s/IP/IPv4/ throughout, for clarity.
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2010-12-15) Unknown
I support Dave's first and Tim's discuss position.
Stewart Bryant Former IESG member
No Objection
No Objection (2010-12-13) Unknown
In Section 4. Ingress Label Edge Router Requirement

"Further, how an ingress LER processes the IP header options of packets before MPLS encapsulation is out of scope since the IP packets are received as they enter the MPLS domain."

The IP packet is not actually received in the IP component of the LSR, it is forwarded. 

You could delete "since the IP packets are received as they enter the MPLS domain.", or perhaps say "since these are processed before they enter the MPLS domain."

Tim Polk Former IESG member
(was Discuss) No Objection
No Objection (2010-12-15) Unknown
The conformance requirements could be stated more clearly. 
In the abstract "invoked" seems to be the wrong word.  To me at least, it implies that the
feature gets turned on as part of the protocol run. In light of the discuss issue, it also isn't
clear if it is mandatory to implement in any MPLS LSR, LER, or only implementations of 
this document.