Thanks Acee. Looks good to me. I have cleared. Regards Suresh
On 06/29/2016 03:24 PM, Acee Lindem (acee) wrote: > Hi Suresh, > > We’ve updated the draft. > > Thanks, > Acee > > On 6/29/16, 11:10 AM, "Suresh Krishnan" <[email protected]> > wrote: > >> Hi Acee, >> Thanks for the quick turanround. All your proposed changes look good >> to >> me. I will clear as soon as a new version posts. We can probably discuss >> the >> "Updates:" issue on the telechat but I do not have strong feelings about >> this >> one way or another. >> >> Cheers >> Suresh >> >> On 06/29/2016 09:49 AM, Acee Lindem (acee) wrote: >>> Hi Suresh, >>> >>> On 6/28/16, 11:41 PM, "Suresh Krishnan" <[email protected]> >>> wrote: >>> >>>> Suresh Krishnan has entered the following ballot position for >>>> draft-ietf-ospf-transition-to-ospfv3-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I do think this is a good mechanism to transition from IPv4-only OSPFv2 >>>> to dual-stack capable OSPFv3 and I intend to switch to a Yes once my >>>> discuss points are addressed. >>>> >>>> * The calculation for the checksum field in the OSPFv3 packet is not >>>> specified in this document. The RFC5340 checksum calculation uses the >>>> IPv6 pseudo-header mechanism for upper layer checksums as specified in >>>> Section 8.1 of RFC2460. Since that obviously won't work here (as there >>>> are no source and dest IPv6 addresses) some different mechanism needs >>>> to >>>> be specified here. >>> >>> Agreed. We will add this - not sure how we missed it. Many IPv4 >>> protocols >>> (including OSPFv2 as described in RFC 2328) exclude the pseudo-header >>> from >>> the standard checksum calculation. Since we have it in OSPFv3 over IPv6 >>> with the RFC 2460 pseudo header, I feel we should retain it here lest we >>> open up OSPFv3 to a documented OSPFv3 vulnerably when authentication is >>> not used. >>> >>> I propose we just use a variant of the UDP pseudo header as described in >>> RFC 768. >>> >>> For IPv4 transport, the pseudo-header used in the checksum calculation >>> will >>> contain the IPv4 source and destination addresses, the OSPFv3 protocol >>> ID, >>> and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 [RFC5340]). >>> The format is similar to the UDP pseudo-header as described in [RFC768]. >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Source Address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Destination Address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0 | Protocol (89) | OSPFv3 Packet Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> >>> >>> >>>> * (based on the above) Why doesn't this document update RFC5340? >>> >>> It could. However, RFC 5340 solely describes OSPFv3 with IPv6 transport. >>> Whether or not an enhancement that doesn’t change an existing >>> specification but augments it has always been a debate. We usually err >>> on >>> the side of updating. What is the IESG take on this? >>> >>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I do have one question that I am curious about. Can this mechanism be >>>> run >>>> alongside OSPFv2 on the same router? If so, how does the demultiplexing >>>> take place to dispatch the packet to either the OSPFv2 or the >>>> OSPFv3-over-IPv4 implementation (as the endpoints are potentially the >>>> same and the IP proto number 89 is usually dispatched to OSPFv2)? Does >>>> it >>>> require inserting some sort of shim in the OSPFv2 implementation to >>>> further dispatch on the version number octet? >>> >>> No shim is necessary since both OSPFv2 and OSPFv3 will check the version >>> number in the first octet of the OSPF(v3) packet header. Commercial >>> implementations normally would normally drop the packet before this >>> stage >>> unless one has both OSPFv2 and OSPFv3 running on the same interface. >>> However, I think this should be discussed in a “Management >>> Considerations” >>> section. >>> >>> 5.0 Management Considerations >>> >>> 5.1 Coexistence with OSPFv2 >>> >>> Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use >>> exactly the same protocol and IPv4 addresses, OSPFv2 packets may be >>> delivered to the OSPFv3 process and vice versa. When this occurs, the >>> mismatched protocol packets will be dropped due to validation of the >>> version in the first octet of the OSPFv2/OSPFv3 protocol header. Note >>> that this will not prevent the packets from being delivered to the >>> correct protocol process as standard socket implementations will >>> deliver a copy to each socket matching the selectors. >>> >>> Implementations of OSPFv3 over IPv4 transport SHOULD implement >>> separate counters for a protocol mismatch and SHOULD provide >>> means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket >>> SNMP notifications as described in [RFC4750] and the >>> ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications >>> as described in [RFC5643] when an OSPFv2 packet is received by >>> the OSPFv3 process or vice versa. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>> >>> >> > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
