Inline <tp>
Tom Petch
From: mpls-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of
ext Thomas Nadeau
Sent: Thursday, January 12, 2012 10:30 PM
To: John E Drake
Cc: mpls(_at_)ietf(_dot_)org;
draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; ietf-bounces(_at_)ietf(_dot_)org
On Jan 12, 2012, at 3:18 PM, John E Drake wrote:
Snipped, comments inline.
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.
[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.
<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
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf