Subject: [renum] draft-ietf-6renum-enterprise: review

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Dec 2012 18:24:08 +0100

Dear all,

I've been reviewing draft-ietf-6renum-enterprise

I have a concern with this document. Not really an objection in the form 
of a DISCUSS, but ...
 From the charter, I believe that this document fits the following:

    1. To undertake scenario descriptions, including documentation of
    current capability inventories and existing BCPs, for enterprise
    networks, including managed and unmanaged elements. These texts should
    contribute towards a gap analysis and provide an agreed basis for
    subsequent WG rechartering towards development of solutions (which may
    be more appropriate for other WGs to undertake) and improved practices.
    Operator input will be of high value for this text.

Reading this reading, I asked myself: what is the specific scope of this 
document? I see a mix of scenarios, listing of the existing solutions, 
best current practices, etc... and I'm wondering where this document 
fits in all the IPv6 documents renumbering documents: RFC 5887, this 
document, Enterprise IPv6 Deployment Guidelines 
draft-ietf-v6ops-enterprise-incremental-ipv6-01, rfc4192, etc...
By "etc", I mean searching for "renum" in 
https://www.ietf.org/download/rfc-index.txt.
It seems that many of these documents have the same type of content. Too 
many actually. Don't get me wrong, there is good text in this document.

Bottom line: if someone is interested in renumbering, what is the 
ordered list of documents to be read, with the respective content. My 
conclusion is that there will be a lot of overlap. I would happy to 
stand corrected.

Btw, this document title mentions "guidelines", while BCP is mentioned 
all over.

Note: I did my home trying to find the answer: read RFC 5887, listened 
to the IETF 85 meeting recording, etc...

- A side note!question, and I'm not sure it has to be addressed by this 
draft, but one day, I would like to find an answer.
How does a NMS do a discovery of a pure IPv6 network? With something 
better than ping sweep obviously...

_Editorial_
1.
Section 1, paragraph 1

    PI space is not always available
    for enterprises Therefore, it is desirable to develop mechanisms that
    simplify IPv6 renumbering.

Missing a "."

2.
Section 1, paragraph 1

    However, widespread use of PI might
    create serious BGP4 scaling problems

A reference, or a small explanation, would be welcome

Regards, Benoit

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 11 Dec 2012 17:54:19 +0000

Folks,

Because the document attracted similar comments from another AD, I have removed the document from Thursday's telechat so that the WG could take whatever time it needed to discuss the matter.

If we decided to move forward with this document, as is, I will put it back on the next telechat agenda.

Authors, could I ask you to respond to Benoit?

                                              Ron

From: Benoit Claise [mailto:[email-masked]]
Sent: Tuesday, December 11, 2012 12:24 PM
To: [email-masked]
Cc: Ronald Bonica
Subject: draft-ietf-6renum-enterprise: review

Dear all,

I have a concern with this document. Not really an objection in the form of a DISCUSS, but ...
1. To undertake scenario descriptions, including documentation of
current capability inventories and existing BCPs, for enterprise
networks, including managed and unmanaged elements. These texts should
contribute towards a gap analysis and provide an agreed basis for
subsequent WG rechartering towards development of solutions (which may
be more appropriate for other WGs to undertake) and improved practices.
Operator input will be of high value for this text.
Reading this reading, I asked myself: what is the specific scope of this document? I see a mix of scenarios, listing of the existing solutions, best current practices, etc... and I'm wondering where this document fits in all the IPv6 documents renumbering documents: RFC 5887, this document, Enterprise IPv6 Deployment Guidelines draft-ietf-v6ops-enterprise-incremental-ipv6-01, rfc4192, etc...
By "etc", I mean searching for "renum" in https://www.ietf.org/download/rfc-index.txt.
It seems that many of these documents have the same type of content. Too many actually. Don't get me wrong, there is good text in this document.

Bottom line: if someone is interested in renumbering, what is the ordered list of documents to be read, with the respective content. My conclusion is that there will be a lot of overlap. I would happy to stand corrected.

Btw, this document title mentions "guidelines", while BCP is mentioned all over.

Note: I did my home trying to find the answer: read RFC 5887, listened to the IETF 85 meeting recording, etc...

- A side note!question, and I'm not sure it has to be addressed by this draft, but one day, I would like to find an answer.
How does a NMS do a discovery of a pure IPv6 network? With something better than ping sweep obviously...

Editorial
1.
Section 1, paragraph 1

2.
Section 1, paragraph 1

Regards, Benoit

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 08:55:49 +0000

Hi, Benoit & Ron,

It was the conclusion from the WG was fairly clear that we were not really making any normative recommendations. But we probably need a new version anyway for clarifications, based on the other reviews.

For overlapping, yes, there are many document mentioned renumbering, only because it is a common issue. Different from other documents that mention renumbering as a minor relevant consideration, the 6renum-enterprise is dedicated for renumbering issue. It focuses on enterprise scenarios and makes a comprehensive analysis, which is not provided by the other documents.

BTW, Benoit’s editorial comments has been fixed in the ongoing version.

Best regards,

Sheng, Bing, Brain

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Wednesday, December 12, 2012 1:54 AM
To: Benoit Claise; [email-masked]
Subject: Re: [renum] draft-ietf-6renum-enterprise: review

Folks,

Because the document attracted similar comments from another AD, I have removed the document from Thursday’s telechat so that the WG could take whatever time it needed to discuss the matter.

                                              Ron

Dear all,

Editorial
1.
Section 1, paragraph 1

2.
Section 1, paragraph 1

Regards, Benoit

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2012 10:57:48 +0000

Benoit,

Here are my *personal* comments on your question. My co-authors may have
a different opinion!

> conclusion is that there will be a lot of overlap. I would happy to

This is a tricky point. RFC 5887 could probably never have been developed
by a WG - in fact it was a non-IAB revisit of an IAB document (RFC 1900).
And it succeeded, because 6renum was chartered. But 6renum was not
chartered to design solutions or even to write a cookbook. I believe
that the nature of the present draft is only to describe the situation
and the existing tools.

At some point the IESG will be given draft-ietf-6renum-gap-analysis
which "briefly introduces the existing mechanisms that could
be utilized for IPv6 site renumbering and tries to cover most of the
explicit issues and requirements of IPv6 renumbering. Through the gap
analysis, the document provides a basis for future works..."

I think that the whole picture will be clearer then - and the IESG
will hopefully decide which of the gaps require IETF action.

draft-carpenter-6renum-next-steps-00 may also help to answer
your question.

> Btw, this document title mentions "guidelines", while BCP is mentioned

I'm wondering whether the title is a bit misleading. We discuss (best)
current practice but the real objective is preparation for the gap
analysis.

> better than ping sweep obviously...

Good question!

> _Editorial_

Noted for the next version.

   Brian

> ------------------------------------------------------------------------
> 
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: S Moonesamy <[email-masked]>
Date: Wed, 12 Dec 2012 04:16:20 -0800

At 00:55 12-12-2012, Sheng Jiang wrote:
>For overlapping, yes, there are many document mentioned renumbering, 
>only because it is a common issue. Different from other documents 
>that mention renumbering as a minor relevant consideration, the 
>6renum-enterprise is dedicated for renumbering issue. It focuses on 
>enterprise scenarios and makes a comprehensive analysis, which is 
>not provided by the other documents.

I reviewed draft-ietf-6renum-enterprise-04 (see 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08511.html 
).  RFC 4192 and RFC 5887 are more informative than the draft.  I 
read the other 6renum drafts (which are not normative in this draft) 
to try to get a better idea of the subject the working group is 
trying to address.  I don't think that the analysis in this draft 
would be that helpful to enterprises.  The bottom line, in my humble 
opinion, is that it will not help IPv6 deployment significantly.

The 6renum charter says:

    "The task of the 6RENUM working group is to document existing renumbering
     practices for enterprise site networks and to identify specific
     renumbering problems or 'gaps' in the context of partial or site-wide
     renumbering."

In Section 1, it is mentioned that best renumbering practices are 
introduced.  That's at odds with the charter.

In Section 4, the paragraph for DNS starts with a reference to RFC 
2874.  The draft then has to explain that A6 RRs are not 
recommended.  If I am not mistaken there is only one line about ACLs 
in the draft.  That's the part which breaks stuff.  I would pay 
attention to ACLs as it can have a more significant impact than 
forgetting about DNS changes.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2012 14:49:46 +0000

On 12/12/2012 12:16, S Moonesamy wrote:
>> only because it is a common issue. Different from other documents that
>> mention renumbering as a minor relevant consideration, the
>> enterprise scenarios and makes a comprehensive analysis, which is not
>> provided by the other documents.
> 
> ).  RFC 4192 and RFC 5887 are more informative than the draft.  I read
> the other 6renum drafts (which are not normative in this draft) to try
> to get a better idea of the subject the working group is trying to
> address.  I don't think that the analysis in this draft would be that
> helpful to enterprises.  

Actually, that isn't the intention. Analysis is not the same thing
as a solution. I think we need to change the title and Introduction a bit
to make this more clear.

> The bottom line, in my humble opinion, is that
> it will not help IPv6 deployment significantly.

What it helps is to document how we derived the gap analysis (coming
soon, it has not yet left the WG). Then the gap analysis will drive
whatever specification or BCP work needs to be done.

> introduced.  That's at odds with the charter.

Well, in the sense that we imply a judgment, perhaps, but is it really
useful to delete the word "best"?

> 2874.  The draft then has to explain that A6 RRs are not recommended. 

Yes, because one of the main reasons A6 was proposed was to assist
renumbering. The main reason that RFC 6563 was published this year
is that 6renum noticed that RFC 2874 was not marked "Historic"
and was still confusing some people.

> If I am not mistaken there is only one line about ACLs in the draft. 
> That's the part which breaks stuff.  I would pay attention to ACLs as it
> can have a more significant impact than forgetting about DNS changes.

Why? Are application programmers coding IPv6 addresses into their
applications instead of using FQDNs?

Of course ACLs are important, and we have been reminded by another
reviewer that they should be mentioned in draft-ietf-6renum-static-problem
too. But what more is there to say than "they need to be updated"?
New mechanisms are out of scope in this draft.

    Brian

---

From: S Moonesamy <[email-masked]>
Date: Wed, 12 Dec 2012 08:14:51 -0800

Hi Brian,
>as a solution. I think we need to change the title and Introduction a bit

That would help.  I was confused about what the document was about as 
it mentions guidelines and best practices.

>whatever specification or BCP work needs to be done.

The above makes matters clearer.  From Section 4:

   "This section recommends some solutions or strategies for the
    enterprise renumbering, chosen among existing mechanisms."

Section 4 comes out as recommendations about Best Current Practices.

>useful to delete the word "best"?

I would describe it as existing practices or some wording around 
"best" if you would like to keep that word.  The above comments 
clarifies what the document is about.  I suggest having such an 
explanation in the document.

>and was still confusing some people.

I was confused about why RFC 2874 is being referenced.

 From Section 4.1:

    "It is recommended that the site have an automatic and systematic
     procedure for updating/synchronizing its DNS records, including
     both forward and reverse mapping [RFC2874].

The above makes a recommendation about DNS synchronization and refers 
to RFC 2874.  In the following paragraph it is mentioned that RFC 
2874 is not recommended.  I cannot recall off-hand a good reference 
for forward and reverse mapping.  I suggest removing the RFC 2874 
reference (see quoted text above).  The draft could keep things easy 
by also dropping the RFC 3364 reference and relying on RFC 6563 to 
explain why A6 RRs are no longer recommended.

>applications instead of using FQDNs?

I hope that application programmers are not hard-coding IPv6 
addresses.  Section 4.1 mentions "system/network 
administrators".  Here is some text (from RFC 4038):

   "Many applications use IP addresses to identify network nodes and to
    establish connections to destination addresses."

I suggest using some variation of that text in the "Usage of FQDN" 
discussion.  The point is to explain that "it is a bad idea" and then 
say that using FQDNs avoids renumbering issues.

>New mechanisms are out of scope in this draft.

I misunderstood what the draft was about (see above).

Regards,
S. Moonesamy