• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: ospf

Current state: WG Document

Viewing the last 20 entries. Show full log.

2013-04-25 11:14 Cindy Morgan

State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation

2013-04-25 08:56 Cindy Morgan

[Ballot Position Update] Position for Pete Resnick has been changed to No Objection by Cindy Morgan

2013-04-25 05:17 Ted Lemon

[Ballot comment]
I'm probably missing something here, but the document doesn't mention the possibility of an MTU issue when a maximally large IPv4 packet is translated into an IPv6 packet: the larger IPv6 header would bump the packet over the MTU size. Has this been addressed, and I just missed it?

2013-04-25 05:17 Ted Lemon

[Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon

2013-04-24 21:45 Pete Resnick

[Ballot discuss]
The document writeup says:

(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?

Informational

Aside from the simple fact that the shepherd didn't fully answer the question, I'd really like to understand why this is not a standards track document. Please explain.

2013-04-24 21:45 Pete Resnick

[Ballot comment]
I do not understand why any of the MUSTs in section 3.1 are not simply "will". The MUSTs make no sense to me.

2013-04-24 21:45 Pete Resnick

[Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick

2013-04-24 21:27 Richard Barnes

[Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes

2013-04-24 04:21 Jari Arkko

[Ballot comment]
Thank you for this work, and thanks to Ben Campbell for the Gen-ART review.

> AFXLBR (Address Family Translation Border Router) is defined in this document.

Nice acronym! Are there any pronunciation guidelines? :-)

2013-04-24 04:21 Jari Arkko

Ballot comment text updated for Jari Arkko

2013-04-24 04:19 Jari Arkko

[Ballot comment]
Thank you for this work, and thanks to Ben Campbell for the Gen-ART review.

> AFXLBR (Address Family Translation Border Router) is defined in this document.

Are there any pronunciation guidelines? :-)

2013-04-24 04:19 Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko

2013-04-23 09:46 Benoit Claise

[Ballot comment]

- Maintaining a separate routing table for IPv4-embedded IPv6 routes
optimizes IPv4 packets forwarding.
Can you expand on why?

-

In an IPv6 network, in order to maintain a separate IPv6 routing
table that contains routes for IPv4-embedded IPv6 destinations only,
OSPFv3 needs to use the mechanism defined either in [RFC5838] or in
[I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
described in Section 3.3 and Section 3.4, respectively.

It looks to me that [I-D.ietf-ospf-mt-ospfv3] should be normative, like RFC 5838
See another sentence:

and
if the default OSPFv3 instance is used instead, configuration is
accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in
Section 3.4.

However, [I-D.ietf-ospf-mt-ospfv3] last updated is 2007
Is there an issue with this draft?

-
It is assumed that the IPv6 network that is inter-connected with IPv4
networks in this document is under one administration and as such, an
OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3
operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6
network. This IID is configured on OSPFv3 router interfaces that
participate in the IPv4-embedded IPv6 topology.

Instance ID is per interface, if I'm not mistaken.
So which interface have this interface ID configured: IPv4 facing and/or IPv6 facing?

-
4. IP Packets Translation

When transporting IPv4 packets across an IPv6 network with the
mechanism described above

There are 2 mechanisms: 3.3 and 3.4
So I guess:
When transporting IPv4 packets across an IPv6 network with one of the two
mechanisms described above (section 3.3 and 3.4)

-
OLD
1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 client network with a destination IPv4
address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as
described in Section 4, and the packet is then forwarded to the
destination AFXLBR that advertised the IPv4-embedded IPv6 address
into the IPv6 network.

NEW
1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 segregated client network with a destination IPv4
address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as
described in Section 4, and the packet is then forwarded to the
destination AFXLBR that advertised the IPv4-embedded IPv6 address
into the IPv6 network.

2013-04-23 09:46 Benoit Claise

[Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise

2013-04-23 08:06 Sean Turner

[Ballot comment]
Stephen beat me to it. I thought the whole point of RFC 6506 was that nobody did IPsec for OSPF.

2013-04-23 08:06 Sean Turner

[Ballot Position Update] New position, No Objection, has been recorded for Sean Turner

2013-04-22 13:26 Adrian Farrel

[Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel

2013-04-22 02:03 Martin Stiemerling

[Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling

2013-04-21 14:02 Stephen Farrell

[Ballot comment]

1.1, pedantic nit: OPEX might not be understood by some
readers

1.2, slightly less pedantic nit: "The P routers" isn't a
common term. While it is defined in 5565 it might be no harm
to also say here you mean the internal routers. (I had to go
look.)

11, 3rd para, is that "must" meant as a 2119 MUST? It looks
like it ought be.

11, 4th para, s/currently//

11, why no mention of RFC 6506? Seems like its as relevant as
IPsec maybe.

2013-04-21 14:02 Stephen Farrell

[Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell

Viewing the last 20 entries. Show full log.