Subject: RE: Questions about draft-betts-itu-oam-ach-code-point

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Jan 2012 17:33:16 -0000

Hi Huub and Malcolm,

I recognise that the intervening month between my original email and this one
included an SG15 meeting, Christmas, and New Year, but I had hoped for a
response by now so that we could work out what to do with the document.

In the meantime, at least my question 4 has progressed. Can you confirm that the
version of G.8113.1 for which a code point is requested is that which has been
sent to WTSA by SG15 (i.e., that which was determined), and that there are no
plans to make any updates or revisions to that document until after it has been
approved.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
> Farrel
> Sent: 09 December 2011 10:49
> To: [email-masked]; 'Huub helvoort'
> Cc: [email-masked]; [email-masked]
> Subject: Questions about draft-betts-itu-oam-ach-code-point
> 
> Hi Malcolm and Huub,
> 
> I have squeezed a little time from the current ITU-T meeting to look at your
> draft and write-up. I have also read the email threads on the IETF discussion
> list and the MPLS list. Sorry that this has taken me a week to process, but
your
> publication request came at pretty much the worst possible time for getting me
> to do this task.
> 
> I don't like proliferating threads across multiple mailing lists. On the other
> hand it is difficult to ensure that all the constituencies are present, so I
am
> perpetuating the cross-posting.
> 
> My review of the document...
> 
> 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
> only one of these is real (the spurious space in a citation). The other nits
are
> spurious caused by citations wrapping across lines. Could you please keep a
note
> of the nit so that you can fix it the next time the draft is respun or so it
can
> be captured in an RFC Editor Note at a later stage (you don't have to post a
new
> revision to address this now unless you really want to).
> 
> 2. This document requests a code point from a registry that contains code
points
> that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
> whether it is your intention that your code point would also be applicable in
> both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
> need to be clarified?
> 
> 
> My review of the write-up and discussions...
> 
> 3. There seems to be quite a feeling on the mailing lists that this document
> should be run through the MPLS working group. The write-up makes a case for
> progressing it as AD sponsored. As far as I can see, the main assertions to
> answer are as follows. Do you have a view on these points before I make a
> decision on what to do?
> 
> a. This is a proposal to use an MPLS code point and so is part of MPLS by
> definition.
> 
> b. The type of network being managed by the OAM described in G.8113.1 is an
> MPLS network. Therefore, this is clearly relevant to the MPLS working .
> 
> Do you object to this going through the MPLS on principle, or were you just
> hoping to save the WG the work? If the latter, and if the WG wants to look at
> the draft, the easiest approach seems to be to redirect the work to the
working
> group.
> 
> 4. G.8113.1 is clearly important to understanding to which the code point is
> being put. Thus, an available and stable copy of group. G.8113.1 will be key
to
> the last call review of you I-D. Can you make a stable copy available (for
> example, through liaison)? How does the editing work currently in progress in
> the SG15 meeting affect that availability?
> 
> 5. Can you clarify for me why the suggested value has been suggested. This
will
> help guide IANA who would normally do their allocation in a "tidy" way.
> 
> Looking forward to your reply.
> 
> Thanks,
> Adrian

---

From: [email-masked]
Date: Wed, 11 Jan 2012 10:38:38 -0500

Hi Adrian, 

I can confirm that the draft is requesting a code point for the version of 
G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the 
draft that was determined in February 2011, I am not anticipating any 
changes prior to the approval decision at WTSA.  None of the changes in 
G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 
were implemented,  I will post a new version 
draft-betts-itu-oam-ach-code-point to correctly reflect the content and 
title on G.8113.1 and respond to the other questions later this week.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]> 
09/01/2012 12:33 PM
Please respond to
<[email-masked]>

To
<[email-masked]>, "'Huub helvoort'" 
<[email-masked]>
cc
<[email-masked]>, <[email-masked]>
Subject
RE: Questions about draft-betts-itu-oam-ach-code-point

Hi Huub and Malcolm,

I recognise that the intervening month between my original email and this 
one
included an SG15 meeting, Christmas, and New Year, but I had hoped for a
response by now so that we could work out what to do with the document.

In the meantime, at least my question 4 has progressed. Can you confirm 
that the
version of G.8113.1 for which a code point is requested is that which has 
been
sent to WTSA by SG15 (i.e., that which was determined), and that there are 
no
plans to make any updates or revisions to that document until after it has 
been
approved.

Thanks,
Adrian

your
am
are
note
can
new
points
working
to
will

---

From: [email-masked]
Date: Thu, 12 Jan 2012 12:17:27 -0500

Hi Adrian,

Please see in line below for my response to your questions.  I will post a 
revised version of the draft tomorrow.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]> 
Sent by: [email-masked]
09/12/2011 05:49 AM
Please respond to
[email-masked]

To
<[email-masked]>, "'Huub helvoort'" 
<[email-masked]>
cc
[email-masked], [email-masked]
Subject
Questions about draft-betts-itu-oam-ach-code-point

Hi Malcolm and Huub,

I have squeezed a little time from the current ITU-T meeting to look at 
your
draft and write-up. I have also read the email threads on the IETF 
discussion
list and the MPLS list. Sorry that this has taken me a week to process, 
but your
publication request came at pretty much the worst possible time for 
getting me
to do this task.

I don't like proliferating threads across multiple mailing lists. On the 
other
hand it is difficult to ensure that all the constituencies are present, so 
I am
perpetuating the cross-posting.

1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I 
think
only one of these is real (the spurious space in a citation). The other 
nits are
spurious caused by citations wrapping across lines. Could you please keep 
a note
of the nit so that you can fix it the next time the draft is respun or so 
it can
be captured in an RFC Editor Note at a later stage (you don't have to post 
a new
revision to address this now unless you really want to).

[MB] OK fixed in the update

2. This document requests a code point from a registry that contains code 
points
that are used equally for MPLS LSPs and pseudowires. I can't tell from the 
I-D
whether it is your intention that your code point would also be applicable 
in
both cases. What is your intention? Is this "obvious" from G.8113.1 or 
does it
need to be clarified?

[MB] The draft requests a code point to support Ethernet based OAM 
messages the use of these messages on MPLS-TP LSPs and PWs is described in 
G.8113.1 other uses are not prohibited by this draft.

3. There seems to be quite a feeling on the mailing lists that this 
document
should be run through the MPLS working group. The write-up makes a case 
for
progressing it as AD sponsored. As far as I can see, the main assertions 
to
answer are as follows. Do you have a view on these points before I make a
decision on what to do?

b. The type of network being managed by the OAM described in G.8113.1 is 
an MPLS
network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you 
just
hoping to save the WG the work? If the latter, and if the WG wants to look 
at
the draft, the easiest approach seems to be to redirect the work to the 
working
group.

[MB]  G.8113.1 supports a subset of the functions defined in 
draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March 2009, 
the draft was presented at several meetings in 2009 and early 2010 and had 
extensive discussion on the MPLS mailing list.  However, the MPLS WG have, 
by rough consensus, adopted a different approach.  Therefore, further 
review by the MPLS WG is of little value. 

4. G.8113.1 is clearly important to understanding to which the code point 
is
being put. Thus, an available and stable copy of group. G.8113.1 will be 
key to
the last call review of you I-D. Can you make a stable copy available (for
example, through liaison)? How does the editing work currently in progress 
in
the SG15 meeting affect that availability?

[MB] The draft is requesting a code point for the version of G.8113.1 that 
was forwarded to WTSA by SG 15 in December, this is the same as the draft 
that was determined in February 2011, I am not anticipating any changes 
prior to the approval decision at WTSA.  None of the changes in G.8113.1 
that were discussed during the drafting sessions and were anticipated in 
draft-betts-itu-oam-ach-code-point-01 were implemented,  as I stated above 
I will post a new version draft-betts-itu-oam-ach-code-point to correctly 
reflect the content and title of G.8113.1 later this week.

[MB]  This value corresponds to the Ethertype used for Ethernet OAM

Thanks,
Adrian

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

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Jan 2012 12:18:01 -0800

Snipped, comments inline.

b. The type of network being managed by the OAM described in G.8113.1 is an MPLS
network. Therefore, this is clearly relevant to the MPLS working .

Do you object to this going through the MPLS on principle, or were you just
hoping to save the WG the work? If the latter, and if the WG wants to look at
the draft, the easiest approach seems to be to redirect the work to the working
group.

[MB]  G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list.  However, the MPLS WG have, by rough consensus, adopted a different approach.  Therefore, further review by the MPLS WG is of little value.

[JD]   Um, I don't think so.
Since, as you state above, G.8113.1 is  effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission.
So, I think it  is clear that your draft belongs in the MPLS WG.
Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 12 Jan 2012 15:29:51 -0500

On Jan 12, 2012, at 3:18 PM, John E Drake wrote:

> [JD]   Um, I don’t think so. 
> 

	Well said John. I couldn't have put it any better myself, and so agree with that statement %100.

	--Tom

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 12 Jan 2012 21:38:52 +0100

Hi,

I fully agree with John and Tom.

G.8113.1 intends to provide an OAM solution for MPLS-TP networks and the
discussion on your draft completely belongs in the MPLS WG and also in
the PWE3 WG.  

Two more points:

*         Malcolm, you say that that the requested code point is not
limited to G.8113.1..."other uses are not prohibited by this draft." I
think it should be very clear for what exactly use it is requested. 

*         Malcolm, you mention that the value of the code point
corresponds to the Ethertype used for Ethernet OAM....are you sure you
approached the appropriate organization for the code point you are
looking for? It seems that you either need to approach the IEEE and look
for an EtherType or simply use PWs to transmit Ethernet OAM. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Thomas Nadeau
Sent: Thursday, January 12, 2012 10:30 PM
To: John E Drake
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point

3. There seems to be quite a feeling on the mailing lists that this
document
should be run through the MPLS working group. The write-up makes a case
for
progressing it as AD sponsored. As far as I can see, the main assertions
to
answer are as follows. Do you have a view on these points before I make
a
decision on what to do?

a. This is a proposal to use an MPLS code point and so is part of MPLS
by
definition.

Do you object to this going through the MPLS on principle, or were you
just
hoping to save the WG the work? If the latter, and if the WG wants to
look at
the draft, the easiest approach seems to be to redirect the work to the
working
group.

[MB]  G.8113.1 supports a subset of the functions defined in
draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March
2009, the draft was presented at several meetings in 2009 and early 2010
and had extensive discussion on the MPLS mailing list.  However, the
MPLS WG have, by rough consensus, adopted a different approach.
Therefore, further review by the MPLS WG is of little value. 

Since, as you state above, G.8113.1 is  effectively draft-bhh and since
draft-bhh was explicitly rejected by the MPLS WG, your draft, which
requests a code point for G.8113.1, is basically an attempt to subvert
the decision by the MPLS WG to reject draft-bhh by attempting to bypass
the WG with an individual submission. 

Incidentally, the MPLS/GMPLS change process was put in place in reaction
to the publication of another individual submission, RFC3474, which was
completely non-interoperable with standard RSVP, a surprisingly similar
situation.

            Well said John. I couldn't have put it any better myself,
and so agree with that statement %100.

            --Tom

---

From: Ross Callon <[email-masked]>
Date: Fri, 13 Jan 2012 00:43:42 -0500

> Adrian wrote:

My personal opinion (speaking as an individual)...

It is pretty clear that there is a lot of interest in this topic in the MPLS WG. It also is clear that this proposal is very much about MPLS. Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG. 

It seems clear that the document also needs IETF last call. I assume this means that one last call would be posted to both the MPLS and IETF WG lists. 

It seems that this same last call should also be copied to the PWE3 list. 

Ross

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Jan 2012 11:46:31 +0100

All (taking chair hat off),

I agree with Ross's comments below that if the document is last called
it should go through a wg last call (pwe3 and mpls) and through an IETF
last call.

I agree that these last calls could be in parallel is necessary, but I
believe that running the wg last call first and the IETF last call would
be beneficial. Given that we have a stable document with stable
references to last call.

/Loa

On 2012-01-13 06:43, Ross Callon wrote:
> It is pretty clear that there is a lot of interest in this topic in the
MPLS WG. It also is clear that this proposal is very much about MPLS.
Thus draft-betts-itu-oam-ach-code-point needs to be last called in the 
MPLS WG.
>
> It seems clear that the document also needs IETF last call. I assume this
means that one last call would be posted to both the MPLS and IETF WG lists.
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 13 Jan 2012 05:58:16 -0500

Also taking my chair hat off ... as Malcolm stated that G.8113.1
applies to PWs, and the requested allocation is in a registry that
originated in the PWE3 working group, I agree that a PWE3 WG last call
is warranted. This could certainly take place in parallel with the
MPLS WG last call.

Cheers,
Andy

On Fri, Jan 13, 2012 at 5:46 AM, Loa Andersson <[email-masked]> wrote:
> Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS
> WG.
>>
>>

---

From: "t.petch" <[email-masked]>
Date: Fri, 13 Jan 2012 12:48:06 +0100

Inline <tp>

Tom Petch

<tp>

This I think is the danger of having the MPLS WG review the document.

draft-bhh was rejected by the MPLS WG and that is history.  Another SDO
wants to standardise the technology and, while the IETF may think that that
is the wrong approach, that is not our decision.  We do however lay claim
to control of the code points which would make this technology easier to
deploy and that is what this I-D requests.  Unless there is some inherent 
problem in having a code point that invokes a different technology, then
there is no reason why we should reject this reasonable request.

The risk is that the request for a code point will degenerate into a draft-bhh,
now in its G. form, bashing exercise, which can have no positive outcome.
We have already decided that draft-bhh is not something we want to 
standardise, we have already said that having two competing standards
is not a good idea (which the current draft recognises); allocating a code
point does no more than let the market place decide which approach is
better.

Tom Petch

            --Tom