Subject: [mpls] AD review of draft-ietf-mpls-ipv6-only-gap

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Oct 2014 23:21:53 +0100

Thank you for writing this document. I think it is an important 
piece of work and I will send it to IETF last call.

Set out below you will find comments from my AD review. I don't think
any is blocking or requires specific updates before IETF last call,
but I would be glad if you would address them along the way or send me
email to discuss them.

Thanks for the work,
Adrian

===

The choice of documents to reference for the different control plane
sections related to RSVP-TE seemed idiosyncratic to me. For example,
the GMPLS section (3.2.6) references RFC 4558, RFC 4990, and RFC 6370
all of which certainly are GMPLS documents, but there is no reference
to the base GMPLS protocol documents (RFC 3471 and 3473) nor a back
pointer to section 3.2.3. Similarly, the PCE section (3.2.4) 
  [Incidentally, this has a really weird section title! Where
   did "controller" come from, and why is the section named 
   after a component and not a protocol (PCEP)?]
includes references to a number of protocol extensions, but neither
3.2.3 nor 3.2.6 seem to care about the detailed protocol extensions to
RSVP-TE.

This issue isn't in any way a show-stopper. It just makes me wonder
about the precision of the survey wrt RSVP-TE given the amount of 
detail in some of the other sections.

---

Section 3.3.3 has

   MPLS-TP does not require IP (see section 2 of RFC 5921 [RFC5921]) and
   should not be affected by operation on an IPv6-only network.
   Therefore this is considered out of scope for this document, but is
   included for completeness.

This is odd! Just because MPLS-TP does not require the presence of IP,
does not mean it might not be there and used. Indeed, in Section 3.2.6
you reference RFC6370 and use it to state a minor GMPLS deficiency.
Yet 6370 is an MPLS-TP document! It is all about how identifiers are
generated and used in MPLS-TP networks, and (as the RFC says) in 
documents where IP is present, the identifiers can be generated using the
local IP addresses.

Similarly, section 3.4.5 is a little ambitious in its claims of zero 
dependence on IP since identifiers play an important part in MPLS-TP 
OAM.

This issue doesn't change the end result (although I would probably move
the paragraph on 6370 from section 3.2.6 to this section.

---

Throughout, you should probably refer to "MIB modules" not "MIBs"

---

I am sceptical about section 3.5. Earlier in the document you have 
mentioned the fact that RFC 4990 explains how to use existing MIB
modules with IPv6 addresses, but you don't mention that RFC here.
Conversely, you do mention an individual I-D that does not (yet?)
have working group support to fix a problem that it is not clear is
the problem that needs to be fixed in a way that seems to me to be
wrong.

---

I never object to my name being spelled correctly :-)

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Oct 2014 19:45:21 +0000

Adrian,

Many thanks for your detailed review. 

I am actually fixing also a couple of very small editorial nits I found.

Please see inline.

> On Oct 12, 2014, at 6:21 PM, Adrian Farrel <[email-masked]> wrote:
> 

All good points, all fixed (I believe).

> documents where IP is present, the identifiers can be generated using the

Ack.

> the paragraph on 6370 from section 3.2.6 to this section.

Added a new paragraph in each of the sections.

> ---
> 
> Throughout, you should probably refer to "MIB modules" not "MIBs”
> 

Indeed — fixed.

> the problem that needs to be fixed in a way that seems to me to be

RFC 4990 is MPLS-TP specific.

Added it though.

> I never object to my name being spelled correctly :-)

Fixed, with apologies!!!

I will send you a new revision momentarily.

Carlos.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Oct 2014 21:58:26 -0000

Hello,

Thanks for the work and I am advancing the I-D.

> RFC 4990 is MPLS-TP specific.

Well now, that comes as a surprise to someone who wrote part of the document and edited the final version :-)

RFC 4990 is most assuredly not about MPLS-TP. There is no mention of MPLS-TP in the document. 
It is quite true that if you were using the GMPLS MIB modules (that build on the MPLS-TE MIB modules) to manage an MPLS-TP network what you have written in the new revision would be perfectly true.
But RFC 4990 also explains the use of IPv6 in the MPLS-TE and GMPLS MIB modules. Section 8 is pretty specific about that and provides a mechanism to handle IPv6 extended tunnel IDs (it's a hack, Jim, but it might just work!).
That makes me somewhat sceptical about the size of the gap you have identified.
(I'm also not convinced that obsoleting an in-use TC will be a sound way to make backward-compatible changes if they turn out to be necessary.)

And now, of course, I start to worry about the level of review applied to section 3.5 of this document. The consequence is not good: if this section carries a bad analysis of the gaps then it is likely to be ignored; if one section of this document is open to be ignored, what of the other sections?

Cheers,
Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Oct 2014 22:11:05 +0000

Adrian,

I meant to type ³RFC 4990 is GMPLS specific², and not what I wrote.

Please ignore the associated consequences from my typo, I was thinking
³MPLS-TP² when I wrote the sentence in my response :-)

Basically, Section 3.5 says three things:
1. Major Gap! RFC 3811 TC for MPLS (which are use in a bunch of MPLS MIB
Modules) lack support for IPv6 in specific cases (Gap) and one I-D tries
to resolve that gap (incidentally authored by one of our contributors)
2. Other MIB Modules had adequate support for IPv4 and IPv6
3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing how to
handle IPv6.

Does that clarify?

We still do have a typo in Section 3.5, second paragraph though.

Thanks,

Carlos.

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Reply-To: Adrian Farrel <[email-masked]>
Date: Tuesday, October 28, 2014 at 5:58 PM
To: Carlos Pignataro <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: AD review of draft-ietf-mpls-ipv6-only-gap

>Well now, that comes as a surprise to someone who wrote part of the
>document and edited the final version :-)
>
>It is quite true that if you were using the GMPLS MIB modules (that build
>on the MPLS-TE MIB modules) to manage an MPLS-TP network what you have
>written in the new revision would be perfectly true.
>But RFC 4990 also explains the use of IPv6 in the MPLS-TE and GMPLS MIB
>modules. Section 8 is pretty specific about that and provides a mechanism
>to handle IPv6 extended tunnel IDs (it's a hack, Jim, but it might just
>work!).
>(I'm also not convinced that obsoleting an in-use TC will be a sound way
>to make backward-compatible changes if they turn out to be necessary.)
>
>And now, of course, I start to worry about the level of review applied to
>section 3.5 of this document. The consequence is not good: if this
>section carries a bad analysis of the gaps then it is likely to be
>ignored; if one section of this document is open to be ignored, what of
>the other sections?
>
>Cheers,
>Adrian
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Oct 2014 09:52:14 -0000

Hi again Carlos,

> ³MPLS-TP² when I wrote the sentence in my response :-)

Yeah, I know. Sometimes those fingers just won't type what you tell them to.
But, of course, and as you recognise in the new revision you just sent me, 4990
is not GMPLS specific since section 8 clearly notes it applies to MPLS-TE and
GMPLS.

> to resolve that gap (incidentally authored by one of our contributors)

Yup. It says this. And that is what I am questioning.
I agree that the 3811bis I-D tries to fix this gap, I just don't agree that it
is a "major" because 4990 shows how it can be circumvented.
That is not to say that 3811bis could not be valuable (with some work), but it
would be very wrong to imply that IPv6 deployment or operation is in some way
gated by this because there are ways of handling the situation.
This to me makes the issue minor, not major.

> 3. RFC 4990 takes if further for GMPLS (NOT MPLS-TP!) describing how to

See above (and note that it's OK to include MPLS-TP in the list :-)

I think we should continue to work through this discussion, but that the
document as it is should go forward to the IESG.

Thanks,
Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Oct 2014 10:14:42 +0000

Sounds great. 

> document as it is should go forward to the IESG.

I'll reply later on the other discussion points. 

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Oct 2014 15:05:24 +0000

Hi Adrian,

Continuing the discussion, please see inline.

> On Oct 29, 2014, at 5:52 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi again Carlos,
> 

I certainly do not disagree with this.

Here’s one quick proposal:

3.5.  MIB Modules

   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
   lack support for IPv6 in defining MplsExtendedTunnelId and
   MplsLsrIdentifier.  These textual conventions are used in the MPLS TE
   Management Information Base (MIB) specification RFC 3812 [RFC3812],
   GMPLS TE MIB specification RFC 4802 [RFC4802] and Fast ReRoute (FRR)
   extension RFC 6445 [RFC6445].  RFC 3811bis
   [I-D.manral-mpls-rfc3811bis] tries to resolve this gap by marking
   this textual convention as obsolete.

   The other MIB specifications for LSR RFC 3813 [RFC3813], LDP RFC 3815
   [RFC3815] and TE RFC 4220 [RFC4220] have support for both IPv4 and
   IPv6.

   Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and
   destinations in the MPLS and GMPLS Traffic Engineering (TE)
   Management Information Base (MIB) modules.  In particular, Section 8
   of RFC 4990 [RFC4990] describes a method of defining or monitoring an
   LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around
   some of the limitations in RFC 3811 [RFC3811].

   Gap: Minor.  Section 8 of RFC 4990 [RFC4990] describes a method to
   handle IPv6 addresses in the MPLS-TE RFC 3812 [RFC3812] and GMPLS-TE
   RFC 4802 [RFC4802] MIB modules.  Work underway to update RFC 3811 via
   RFC 3811bis [I-D.manral-mpls-rfc3811bis], may also need to update RFC
   3812, RFC 4802, and RFC 6445, which depend on it.

Thanks,

Carlos.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Oct 2014 16:56:36 -0000

I like this proposal. Thanks for going the extra mile.

Adrian

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: 29 October 2014 15:05
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked];
[email-masked]
> Subject: Re: AD review of draft-ietf-mpls-ipv6-only-gap
> 
> Hi Adrian,
>