Skip to main content

Network Management Framework for MPLS-based Transport Networks
draft-ietf-mpls-tp-nm-framework-05

Yes

(Adrian Farrel)

No Objection

(Dan Romascanu)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

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

Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2010-02-18) Unknown
Section 7.1:

For IPv6, the
   reported Next-Hop MTU could be as low as 1280 octets (the minimum
   IPv6 MTU) [RFC2460].

Actually the reported MTU can be lower than 1280. The proper response is to send if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation header. 

From section 5 of RFC 2460:

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2010-02-14) Unknown
  The Gen-ART Review by Pete McCann on 2010-02-05 raises two points
  that should be considered:

  Section 2.2 seems like a lot of complexity (and acronyms) just to 
  talk about the internal architecture of one box, and to define
  interfaces that won't ever be standardized.

  In one place in section 2.2, EMF is expanded to "Element Management
  Function."  In the Terminology and elsewhere, this is "Equipment
  Management Function."
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown