Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt

From: Mach Chen <[email-masked]>
Date: Mon, 19 Sep 2011 01:28:48 +0000

Hi,

We submitted a new draft that updates RFC4379 to explicitly constraint the existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6 scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where the Sender's and Receiver's IP addresses are IPv6 addresses.) 

We'd appreciate that you could spend some time to read the draft (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your comments!

Thanks,
Mach

----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 17, 2011 11:08 AM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]; Mach Chen; [email-masked]
> Subject: New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt
> 
> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been
> successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository.
> 
> Filename:	 draft-chen-mpls-ipv6-pw-lsp-ping
> Revision:	 01
> Title:		 Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs
> Creation date:	 2011-08-16
> WG ID:		 Individual Submission
> Number of pages: 9
> 
> Abstract:
>    Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping
>    and Traceroute mechanisms are commonly used to detect and isolate
>    data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs.
>    The PW LSP Ping and Traceroute elements, however, are not specified
>    for IPv6 address usage.
> 
>    Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in
>    the LSP Ping and Traceroute mechanism are implicitly defined only for
>    IPv4 Provider Edge (PEs) routers, and are not applicable for the case
>    where PEs use IPv6 addresses.  There is, additionally, a degree of
>    potential ambiguity in the specification of these sub-TLVs since the
>    address family is not explicitly specified but it is to be inferred
>    from the sub-TLV length.
> 
>    This document updates RFC4379 to explicitly constraint these existing
>    PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP
>    Ping to the IPv6 scenario where an IPv6 LDP session is used to signal
>    the Pseudowire (i.e., where the Sender's and Receiver's IP addresses
>    are IPv6 addresses.)  This is done by defining two new LSP Ping sub-
>    TLVs for IPv6 Pseudowire FECs.
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Sep 2011 10:28:39 +0200

---- Original Message -----
From: "Mach Chen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 19, 2011 3:28 AM
> Hi,
>
> We submitted a new draft that updates RFC4379 to explicitly constraint the
existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping
(by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6
scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where
the Sender's and Receiver's IP addresses are IPv6 addresses.)
>
> We'd appreciate that you could spend some time to read the draft
(http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your
comments!

Mach

It looks ok, but I sort of get worried when I have to spend too much time
working out the details.  Specifically, the IANA registries that RFC4379 created
have been given names by IANA, even though RFC4379 itself did not do so, so I
think that this I-D should use these names.  The registry in question, MPLS -
LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making early
allocations to it so it is quite a big and volatile registry.

Technically this is not a problem but it sort of worries me.  This I-D is in a
sense putting right a lack of foresight in RFC4379, nailing down what RFC4379
might have nailed down, so is there anything still missing that needs nailing
down?  I cannot see anything but think I am probably missing something:-(

Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you
are updating three.  TLV Type21 has 19 sub-TLVs which closely parallel those of
Type 1 which you are not updating (ok there is another I-D that should do so but
have the authors of that I-D - namely you! - any thoughts on this?).  Should the
registry be looked at more widely to see if it can better be rationalised?

Tom Petch

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

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 20 Sep 2011 17:59:26 +0530

Tom,

Many thanks for the comments, please see inline.

> allocations to it so it is quite a big and volatile registry.

This is a good point, and frankly I'm not sure why we didn't -- I meant
to. We can add "Multi-Protocol Label Switching (MPLS) Label Switched
Paths (LSPs) Ping Parameters" "TLVs and sub-TLVs Registry", and a
pointer to <http://www.iana.org/assignments/mpls-lsp-ping-parameters>
(although it would be changed to <http://www.iana.org>). Thanks.

> down?  I cannot see anything but think I am probably missing something:-(

Please note that this I-D is not a cleanup exercise for RFC4379; it's
purposely narrowly focused to LSP Ping for IPv6 PW FECs.

> have the authors of that I-D - namely you! - any thoughts on this?).

I am not an author of this I-D,
draft-ietf-mpls-return-path-specified-lsp-ping, but my sense is that
this I-D draft-ietf-mpls-return-path-specified-lsp-ping should point to
draft-chen-mpls-ipv6-pw-lsp-ping and figure out TLV 21. This is because
TLV 21 is defined by draft-ietf-mpls-return-path-specified-lsp-ping, and
compounded by the fact that these are temporary allocations.

>  Should the

I think you just did, mostly -- note that a cleanup or rationalization
of this registry is not a goal of this I-D.

Thanks,

-- Carlos.

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Sep 2011 16:20:49 +0200

----- Original Message -----
From: "Carlos Pignataro" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Mach Chen" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 20, 2011 2:29 PM

> purposely narrowly focused to LSP Ping for IPv6 PW FECs.

Yup, I understand that, and that is my concern, that we are getting to the point
where a cleanup may be needed.  With the benefit of (wonderful) hindsight, how
much better it would be to have a range of sub-TLVs, say 1-63, that are common
across TLVs, and another, say 128-191 that are unique to a TLV.  Reading
draft-ietf-mpls-return-path-specified-lsp-ping
makes the need for that clear, but, too late.  At the moment, RFC4379 is clear;
"The number spaces for the
   sub-TLVs of various TLVs are independent."
which is a problem for
draft-ietf-mpls-return-path-specified-lsp-ping
and not for you; sigh.

But I think that it does behove authors like yourself to keep an eye on, e.g.,
draft-ietf-mpls-return-path-specified-lsp-ping
to see if it needs the same actions as you are proposing, and since
they have an Editor in common ( I was referring to M. Chen(Ed.) rather than
yourself), hopefully that will be the case.

Tom Petch

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 20 Sep 2011 21:31:13 +0530

Tom,

Please see inline. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Sep 20, 2011, at 8:55 PM, "t.petch" <[email-masked]> wrote:

> makes the need for that clear, but, too late.

I think that this I-D makes clear the need for two particular TLVs to share sub-TLVs, but not necessarily have common sub-TLVs across the whole TLV range (which includes Experimental, etc)

>  At the moment, RFC4379 is clear;

I think that the problem perhaps is that this ID refers directly to (the frozen in time) RFC 3479 and not jus say explicitly that subTLVs are shared between those two:
http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-03#section-6.2.1

> yourself), hopefully that will be the case.

I do see the point you bring up. I agree. I think however that for a solution, the direction of expectation is backwards: mpls-return-path needs to ensure alignment on the TLV is itself defining. 

And EFFJI in the response earlier, I expect Mach will speak about mpls-return-path. 

Thanks,

Carlos.

---

From: Mach Chen <[email-masked]>
Date: Wed, 21 Sep 2011 06:28:44 +0000

Hi Tom,

Many thanks for your comments.

Please see my response inline...

> LSP Ping Parameters - TLVs and sub-TLVs, 

Good suggestion, will do that in the later version.

>already has four I-Ds making early

I did a rough checking when I wrote this draft, and found that the PW FEC is the only one that needs nailing down, which impacts two documents, one is RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping.

> registry be looked at more widely to see if it can better be rationalised?

As the author of the two drafts, I have noticed that and have plan to update the return-path-specified-lsp-ping draft, and make a point to this new draft is the straightforward and simple solution. 

Since that draft is still working in progress and has the common author, it's easier to update.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Wed, 21 Sep 2011 06:49:50 +0000

Hi Tom,

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Tuesday, September 20, 2011 10:21 PM
> To: Carlos Pignataro
> Cc: Mach Chen; [email-masked]; [email-masked]
> Subject: Re: [mpls] New Version Notification for
> draft-chen-mpls-ipv6-pw-lsp-ping-01.txt
> 
> > > existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire
> LSP
> Ping
> > > have been given names by IANA, even though RFC4379 itself did not do so,
> so
> I

Yes, as replied in my previous email, an update to draft-ietf-mpls-return-path-specified-lsp-ping is needed. 

Best regards,
Mach
> > > are updating three.  TLV Type21 has 19 sub-TLVs which closely parallel
> those
> of

---

From: "t.petch" <[email-masked]>
Date: Wed, 21 Sep 2011 10:27:01 +0200

Mach

Since you mention updating
draft-ietf-mpls-return-path-specified-lsp-ping
below, I offer two more revolutionary ideas.

First is the relationship between the subTLVs of TLV Type1 and those of TLV
Type21.  Looking at the IANA page, I think that IANA have the same problem as I
do.  Are the subTLVs of  TLV Type21 intended to approximate to those of Type1,
be an exact match at this point in time (a fast moving target with three I-Ds
with the IESG and RFC Editor), be an exact match for all time (with the
implications on future editors being aware of that) r what? (I think that the
IANA page is currently a 'what?' :-)

Second, we are getting several RFC updating the registry that RFC4379
established, which makes it harder to find what is defined where and to make
subsequent updates accurate, so the fewer RFC, the better.  So were the chairs
to poll for the adoption of
draft-chen-mpls-ipv6-pw-lsp-ping-01
I would oppose, rather seeing its content, important but slight, rolled into
draft-ietf-mpls-return-path-specified-lsp-ping
which is the I-D, after all, that creates much of the complexity by introducing
TLV Type 21.

Tom Petch

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 21, 2011 8:28 AM

> I did a rough checking when I wrote this draft, and found that the PW FEC is
the only one that needs nailing down, which impacts two documents, one is
RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping.
> As the author of the two drafts, I have noticed that and have plan to update
the return-path-specified-lsp-ping draft, and make a point to this new draft is
the straightforward and simple solution.

---

From: Mach Chen <[email-masked]>
Date: Thu, 22 Sep 2011 09:42:06 +0000

Hi Tom,

Please see inline...

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> t.petch
> Sent: Wednesday, September 21, 2011 4:27 PM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] New Version Notification
> fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt
> 
> Mach
> 

Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for Type21 TLV, and vice versa.

Strictly speaking, Type21 is totally independent of Type1 TLV, it just "borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and their sub-TLVs registries should be created, updated and maintained independently. 

> subsequent updates accurate, so the fewer RFC, the better. 

I basically agree with you here, but the practice of the IETF normally like this, a spec and then subsequent extensions with time.

>So were the
> chairs

I personally prefer to let them separate, because the two drafts have different purposes and functions. If the WG has the consensus to do it, I will be OK with that.

Best regards,
Mach

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 28 Sep 2011 11:07:38 -0400

Tom,

Please find one or two additional comments inline.

Note also we posted
<http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-02>
addressing your IANA comment, diffs at
<http://tools.ietf.org/rfcdiff?url2=draft-chen-mpls-ipv6-pw-lsp-ping-02.txt>.

> I basically agree with you here, but the practice of the IETF normally like this, a spec and then subsequent extensions with time.

I disagree. Nothing wrong with multiple RFCs updating a specific
registry -- that's actually potentially a good thing if it speaks to
protocol growth and adoption!

I also do not think there is confusion since registries have a
"Reference" column with a pointer to the document (not even necessarily
an RFC in general) that is authoritative for a given entry. Lastly,
minimizing RFC.count by potentially agglutinating different issues
together is actually not something I'd recomment; in fact, Truth #5 of
<http://tools.ietf.org/html/rfc1925> comes to mind.

>> draft-ietf-mpls-return-path-specified-lsp-ping

IMHO, this is putting the cart before the horse. These are not documents
created to update IANA registries. These are protocol documents with
completely different goals, solving totally different problems. Both
update the same registry, as a consequence, as a means and not an end.

Thanks,

-- Carlos.

---

From: "t.petch" <[email-masked]>
Date: Fri, 30 Sep 2011 12:05:08 +0200

<inline>
----- Original Message -----
From: "Carlos Pignataro" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 28, 2011 5:07 PM
> > Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but
not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not
necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for
Type21 TLV, and vice versa.
> >
> > Strictly speaking, Type21 is totally independent of Type1 TLV, it just
"borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and
their sub-TLVs registries should be created, updated and maintained
independently.
> > I basically agree with you here, but the practice of the IETF normally like
this, a spec and then subsequent extensions with time.
> protocol growth and adoption!

It is a characteristic of the IETF, perhaps truth 13, to produce small
incremental steps, and neglect the larger picture.  It is certainly easier
to produce an I-D and RFC which is short and only covers a small
part of the solution.  But a year or two down the line, with 10 or
20 or 50 RFC to go through to assemble the big picture, it is much
more work, more mistake-prone, for all involved to track back what
a value in a field means (in this instance how the length of a field is
defined differently in different TLV or what the current meaning of
subtype 10 is); TCP might be the poster child for this.

To produce fewer, larger RFC is, in the long run, more productive for
all but the writers of short RFC.

The fact that both these RFC impact the same registry does link them,
willy nilly, they are both about LSP Ping and they are both saying
things about subTypes to Type one and that, for me,
needs more clarification that is currently in the I-Ds, if
only to say that Type 1 and Type 21 are completely independent and any
updates to Type 1 after RFC4379 should be ignored (all much easier with
just the one RFC).

Tom Petch
> > I personally prefer to let them separate, because the two drafts have
different purposes and functions. If the WG has the consensus to do it, I will
be OK with that.
> >>>> Technically this is not a problem but it sort of worries me.  This I-D is
in
> >> a
> >>>> Type 1 which you are not updating (ok there is another I-D that should do
so
> >> but
Should
> >> the
> >>> Since that draft is still working in progress and has the common author,
it's
> >> easier to update.

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 30 Sep 2011 08:46:17 -0400

> subtype 10 is); TCP might be the poster child for this.

Keeping the focus of the comment on the particular case at hand, you are
assuming there is a common big picture between these two I-Ds (or
between all I-Ds adding sub-TLVs to TLV 1). Instead they are (all)
rather independent. You are also assuming in this comment that the big
picture will stay unchanged without any need for pruning.

I do very much agree with you that there is a need to be quite precise
on the definition of a TLV (21) that mimics/follows another TLV (1).
However, amalgamating and blending documents is, IMHO, the wrong
conclusion. This is a comment that should be targeted to
draft-ietf-mpls-return-path-specified-lsp-ping, and I think you wrote
before the level of precision needed with three alternatives.

If you look at
<http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#mpls-lsp-ping-parameters-7>,
does draft-ietf-mpls-return-path-specified-lsp-ping need to be combined
with all I-Ds that deal with TLV Type 1, namely
{RFC-ietf-mpls-p2mp-lsp-ping + draft-ietf-mpls-tp-on-demand-cv +
draft-chen-mpls-ipv6-pw-lsp-ping + ...}? I expect not.

> all but the writers of short RFC.

Now, onto the generalities front, sure: as few as possible, but not
fewer. I think it is more important to have appropriate definitions,
pointers and relationships.

> updates to Type 1 after RFC4379 should be ignored (all much easier with

I know, there are a lot of intersection points between a lot of
documents, all from the same WG, all written in English, updating the
same sub-registry, and the same TLV within that sub-registry. At least
four or five I-Ds match these as per above, willy nilly. But, IMHO, key
is what is the intended goal (i.e., problem being solved) in each doc,
and *all* those are quite independent.

Thanks,

-- Carlos.