Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd)

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 09:51:41 -0400

In message <[email-masked]>, Pekka Savola 
writes:
> FYI;
> 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt

As written it looks like a pretty worthless document.  If the authors
had any clue whatsover about which protocols are actually used and the
relationships between documents they'd not make statements such as
those dismissing BGP-4 as an IPv4 only protocol.

Nice idea.  Get some authors that know what they are doing and it
might be a more useful exercise.  As an informational document its a
NOOP anyway.

Curtis

ps - unrelated - Anyone remember the NOOP WG?

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 09:51:41 -0400

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Sep 2003 10:16:39 -0400

> those dismissing BGP-4 as an IPv4 only protocol.

If I recall correctly, this document is a survey of RFCs and IDs.
I don't recall any documents published that say you can run BGP
over IPv6 TCP transport sessions.

The fact that it just works is sort of besides the fact. :-)

> ps - unrelated - Anyone remember the NOOP WG?

I am but an egg. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Sep 2003 10:16:39 -0400

I am but an egg. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 11:41:05 -0400

> over IPv6 TCP transport sessions.

Part of the purpose of BGP-MP is to carry IPv6.

It turns out you can run over Ipv6 TCP.  The router-id can be a 4 byte
octet (see draft-ietf-idr-bgp-identifier-02.txt).  So not only does it
work but how it works is documented.

In IPv4 the common convention is that the loopback had an address and
that address was used for IBGP but that is not a requirement.

> The fact that it just works is sort of besides the fact. :-)

Right.  But you have a clue so you knew all this.  The point is its
contrary to what the draft indicates and so much of the draft is wrong
that it would be better to start over with new authors.

> > ps - unrelated - Anyone remember the NOOP WG?

Your boss was the WG chair.  She may have picked the name.  :-)

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 11:41:05 -0400

Curtis

---

From: Atanu Ghosh <[email-masked]>
Date: Wed, 03 Sep 2003 07:57:27 -0700

>>>>> "Jeffrey" == Jeffrey Haas <[email-masked]> writes:

    >> those dismissing BGP-4 as an IPv4 only protocol.

    Jeffrey> If I recall correctly, this document is a survey of RFCs and IDs.
    Jeffrey> I don't recall any documents published that say you can run BGP
    Jeffrey> over IPv6 TCP transport sessions.

2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
     Routing. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes)
     (Status: PROPOSED STANDARD)

4. Transport

   TCP connections, on top of which BGP-4 messages are exchanged, can be
   established either over IPv4 or IPv6. While BGP-4 itself is ...

   Atanu.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Sep 2003 21:46:48 +0300 (EEST)

> might be a more useful exercise.  As an informational document its a

Are you volunteering?

But seriously.. it's commonly held that to appropriately use BGP with 
IPv6, you need the multi-protocol extensions, period.  Do you have some 
other insight to shed here?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 17:52:25 -0400

In message <[email-masked]>, Pekka Savola 
> other insight to shed here?

What the draft says is:

  4.1  RFC 1771 A Border Gateway Protocol 4 (BGP-4) 

   This RFC defines a protocol used for exchange of IPv4 routing 
   information and does not support IPv6.  A new EGP must be defined
   for the exchange of IPv6 routing information. 

Would you agree that this is incorrect?  Particulary the sentence "A
new EGP must be defined for the exchange of IPv6 routing information."

A more appropriate entry would recognize the extensions to BGP-4 and
point out that to use BGP-4 simply refer to RFC-2858 (Multiprotocol
Extensions for BGP-4) and RFC-2545 (Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing).

Instead RFC-2858 is not mentioned and the entry for RFC-2545 says:

  5.22   RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-
    Domain Routing 

   This RFC documents IPv6 routing methods and is not discussed in
   this document.

For completeness the authors should also reference:

  "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan,
  04-Apr-03, <draft-ietf-idr-bgp-identifier-02.txt>

    To accommodate situations where the current requirements for the
    BGP Identifier are not met, this document relaxes the definition
    of the BGP Identifier to be a 4-octet unsigned, non-zero integer,
    and relaxes the 'uniqueness' requirement so that only AS-wide
    uniqueness of the BGP Identifiers is required. These revisions to
    the base BGP specification do not introduce any backward
    compatibility issue.

and the authors of this draft should look at the text in BGP-4 and
note that the text calls for TCP but makes no mention of whether it is
TCP over v4 or v6.

If the authors knew what was going on in the IETF and knew the
documents they'd know that consideration for IPv6 is in BGP-4 by way
of the extensions and would write that in the draft.

If the authors knew what they were doing they wouldn't reference
historic documents, particularly ones that have an "obsoleted by"
entry in the RFC index.

This draft also states:

  A new version of OSPF must be created to support IPv6.

The authors would not have written that had they bothered to look at
the following RFC:

  2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999.
     (Format: TXT=189810 bytes) (Status: PROPOSED STANDARD)

The authors appear not to understand the IETF document process since
when looking at the set of full standards they ignored all of the
proposed standards which update them.  The full standards just reflect
our long experience with these base protocols and confidence in them
(or at least confidence that we understand their strengths and
limitations), as opposed to our more limited experience with more
recent extensions to them, such as extensions for IPv6 which are all
proposed standards for that reason.

If the document was mostly right with some flaws it would be a good
starting point.  It is so far from accurate that I stand by my
original statement that the document is of no value to the IETF.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Sep 2003 17:52:25 -0400

What the draft says is:

This draft also states:

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Sep 2003 10:19:26 -0400

In message <[email-masked]>, Pekka Savola 
writes:
> 
> Again, are you volunteering to write better documents?  To edit the 
> current one?  To submit actual text updates which are in line with the 
> organization of the documents?

The organization of the document is flawed.  It has to be fixed.

> The document certainly needs quite a bit of work from the subject matter
> experts (routing folks).  Unfortunately, constructive feedback has been 
> slow in coming (but non-null, luckily -- thanks!).

OK lets start over with the comments.

> Please look at section 2, "Document Organization", in particular:
> 
>    Sections 3, 4, 5, and 6 each describe the raw analysis of Full,
>    Draft, and Proposed Standards, and Experimental RFCs.  Each RFC is
>    discussed in its turn starting with RFC 1 and ending with RFC 3247.
>    The comments for each RFC are "raw" in nature.  That is, each RFC is
>    discussed in a vacuum and problems or issues discussed do not "look 
>    ahead" to see if the problems have already been fixed.
> 
> .. this approach precludes "looking ahead".  On the other hand, "looking 
> ahead" is done in section 7, which states:

If you are going to make a reasonable document out of this, you going
to have to fix this first.

> Agreed, but certainly the original author didn't, and chose a document
> organization which is not exactly intuitive.

Its more than not intuitive.  It doesn't make any sense in the context
of the way IETF produces documents.  Base specs are rarely updated to
fold in all extensions.  If they are it is generally only when the
base document is determined to be of no longer of any use without a
particular extension.  Instead the extensions are defined in separate
documents.  As a practical matter the base BGP4 document is very
mature and is not going to be updated to include IPv6 extensions any
time soon.  Neither is OSPFv2.

The other major routing protocol is ISIS.  The base spec is a now
obsolete OSI spec, with multiprotocol extensions for IPv4 in RFC-1195.
Neither of these base specs are likely to be updated for IPv6.  The
ISIS WG seems to work in a one feature per document mode.  The
existance of draft-ietf-isis-iso-interoperable-00.txt and
draft-ietf-isis-ip-interoperable-00.txt should tell you that RFC-1195
is substantially wrong but rather than fix RFC-1195, the ISIS WG is
writing a separate document to advise implementors of what is wrong
with RFC-1195.  While not relevant to IPv6, this does indicate how
unlikely it is that a rewrite of RFC-1195 will be undertaken to handle
IPv6 in the base document.  The IETF does not have the authority to
modify ISO 10589.

> I agree the approach is not the best one, but it was the one given to us 
> by the person who did the initial work.  We're just trying to patch it up 
> to be ready for dissemination and use.

We can start with deleting any document classified as Historic since
Historic specifically means "don't use this".  We can also change any
entry for an obsoleted document to reflect the newer document plus any
"updated by" entries.

For example, RFC-1745 is not used.  It seemed like a good idea but it
never really was used in any deployment, was later declared to be
harmfull and was reclassified as historic.

> Agreed.

Do you then agree that we need to reorganize the document?

As is you've got completely wrong statements in it that you are
attributing to the organization of the document.  As a result, the
summary in section 7 is completely misleading, with its statements:

  7. Summary of Results 

   In the initial survey of RFCs 25 positives were identified out of a 
   total of 53, broken down as follows: 

   Standards                 2 of  7 or 28.57% 

   Draft Standards           1 of  2 or 50.00% 

   Proposed Standards       17 of 33 or 51.52% 

   Experimental RFCs         5 of 11 or 45.45% 

The document is therefore close to useless because it is substantially
wrong up to section 7.1.  Since experimental protocols that are not
used need not be considered, the entire useful part of this document
fits easily on two pages, plus a references page (and boilerplate).

Other minor points:

It has long been recognized that RFC-1822 should be updated to better
reflect IPv4 router requirements and when that is done IPv6 can be
addressed in that update or IPv6 can be addressed in a separate
document.

You need not cover experimental RFCs.  If the protocol has been
experimental for a few years it generally means it is unused and could
be reclassified as historic.  Until such time as it is reclassified as
Proposed Standard, you can ignore it for the purpose of this document.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Sep 2003 10:19:26 -0400

7. Summary of Results 

Other minor points:

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 08:54:20 +0300 (EEST)

> new EGP must be defined for the exchange of IPv6 routing information."

The first sentence is correct, in practice.  The second sentence is a
value judgment, and correct -- interpreted loosely.  If I had written the
document myself, I would certainly have used different wording.  Just 
think of it as an expression to say "BGP-4 needs to be enhanced to support 
IPv6, or we need to develop either a new version of the protocol or an 
entirely new protocol".

   7.2.1 Border Gateway Protocol 4 (RFC 1771)

   This problem has been fixed in RFC 2283, Multiprotocol Extensions for
   BGP-4.

.. which is pretty close to the mark, but could be improved, of course.
 
>    This RFC documents IPv6 routing methods and is not discussed in

Which is true.

>   04-Apr-03, <draft-ietf-idr-bgp-identifier-02.txt>
[...]

Agreed.

 

>   A new version of OSPF must be created to support IPv6.

This is correct.

>      (Format: TXT=189810 bytes) (Status: PROPOSED STANDARD)

.. again, this is contained in section 7.

Agreed.
 
> original statement that the document is of no value to the IETF.

Yes, but as it happens, nobody else was doing this job, one person was
contracted to do it, and we (v6ops WG) were given the results to deal
with.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 23:19:18 +0300 (EEST)

> The organization of the document is flawed.  It has to be fixed.

Again, are you volunteering to rework the document (or create new ones), 
with a better organization?  (I would certainly do so myself, if I/we had 
inifinite resources but we don't.)

I'd say "it would be good to have it fixed", but then I'll have to 
respond, "but it would require extensive rework of the documents of seven 
different areas, hundreds of pages total, and that doesn't seem to have a 
sufficiently high cost/benefit ratio, so we should just try to live with 
the current one".

> to have to fix this first.

Unfortunately, this would be such a huge undertaking, so we'd be very, 
very reluctant to do this .. especially has none of the areas themselves 
have not been forthcoming in editing the documents to taste themselves.  
It would just take too much resources, I think.

(However, we've agreed, on another thread, to enhance them a bit: remove 
now-Historic documents entirely, and when a document has been Obsoleted, 
always point to the most recent version.  That should help a bit.)

> IPv6 in the base document.  The IETF does not have the authority to

I agree here.  I think the main problem is with the words the original 
author chose, like "a new EGP must be defined".  Those are "overly 
aggressive", from someone who doesn't know how routing protocols are 
usually handled with this building blocks model.

Perhaps by toning down that advice a bit it might not "wave the red flag" 
so blatantly?

> harmfull and was reclassified as historic.

Will be done (as noted above).
 
> Do you then agree that we need to reorganize the document?

No, I agree that the author misunderstood the document process and the 
current organization is not optimal.  However, I disagree that we should 
change it significantly, because that would incur a tremendous amount of 
work.  We'll just try to live with the current set, and make smaller 
updates as necessary.
 
> fits easily on two pages, plus a references page (and boilerplate).

I disagree here on the "useless" part.  The reason why sections 3-6 exist, 
I believe, are to describe which parts of the RFC's exhibit the IPv4 
dependencies; it is by no means usually a trivial thing.  
 
> addressed in that update 

I've heard the same, but I've never heard anyone volunteering for that 
:-))

> or IPv6 can be addressed in a separate
> document.

right.

> Proposed Standard, you can ignore it for the purpose of this document.

Well, they're already there, and are of some use, so I think it makes 
sense to keep them in (they're cleanly separated from the standards track 
stuff).

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 08:54:20 +0300 (EEST)

Which is true.

[...]

Agreed.

 

This is correct.

 

Agreed.

---

From: "Cesar Olvera Morales" <[email-masked]>
Date: Thu, 4 Sep 2003 18:06:22 +0200

See inline.

César Olvera

> Would you agree that this is incorrect?  Particulary the 
> sentence "A new EGP must be defined for the exchange of IPv6 
> routing information."
> 

May be this sentence is no totally correct, and it could be changed by
the reference to BGP extensions.

> A more appropriate entry would recognize the extensions to 
> BGP-4 and point out that to use BGP-4 simply refer to 
> RFC-2858 (Multiprotocol Extensions for BGP-4) and RFC-2545 
> (Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing).
> 
>   5.22   RFC 2545 Use of BGP-4 Multiprotocol Extensions for 
> IPv6 Inter-Domain Routing 
> 

The reference to RFC-2858 is already in 5.27 section.

>     the base BGP specification do not introduce any backward

Ok, Agreed

> and the authors of this draft should look at the text in 
> BGP-4 and note that the text calls for TCP but makes no 
> mention of whether it is TCP over v4 or v6.
> 
> If the authors knew what was going on in the IETF and knew 
> the documents they'd know that consideration for IPv6 is in 
> BGP-4 by way of the extensions and would write that in the draft.
> 

There are some references:

5.27   RFC 2858 Multiprotocol Extensions for BGP-4 (MEXT-BGP4) 

   In the Abstract: 

   Currently BGP-4 [BGP-4] is capable of carrying routing information 
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to 
   enable it to carry routing information for multiple Network Layer 
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward 
   compatible - a router that supports the extensions can interoperate 
   with a router that doesnÆt support the extensions. 

   The document is therefore no examined further in this document.

And of course, a better remarks could be added.

> If the authors knew what they were doing they wouldn't 
> reference historic documents, particularly ones that have an 
> "obsoleted by" entry in the RFC index.
> 
> This draft also states:
> 
> The authors would not have written that had they bothered to 
> look at the following RFC:
> 

This RFC is already included in 5.23 section

> The authors appear not to understand the IETF document 
> process since when looking at the set of full standards they 
> ignored all of the proposed standards which update them.  The 
> full standards just reflect our long experience with these 
> base protocols and confidence in them (or at least confidence 
> that we understand their strengths and limitations), as 
> opposed to our more limited experience with more recent 
> extensions to them, such as extensions for IPv6 which are all 
> If the document was mostly right with some flaws it would be 
> a good starting point.  It is so far from accurate that I 
> stand by my original statement that the document is of no 
> value to the IETF.
> 

How can we work for improve the document?

> Curtis

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Cesar Olvera Morales" <[email-masked]>
Date: Thu, 4 Sep 2003 18:06:22 +0200

See inline.

César Olvera

Ok, Agreed

   In the Abstract:

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 23:19:18 +0300 (EEST)

right.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Sep 2003 11:07:55 -0400

In message <[email-masked]>, Pekka Savola w
> sufficiently high cost/benefit ratio, so we should just try to live with 

The IETF has not been known to accept shoddy work just because it was
inconvenient for the author to make it better.  I would hope that the
emphasis on quality and clarity are not waived in this case.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Sep 2003 11:07:55 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Sep 2003 21:46:48 +0300 (EEST)

Are you volunteering?

---

From: Atanu Ghosh <[email-masked]>
Date: Wed, 03 Sep 2003 07:57:27 -0700

4. Transport

   Atanu.