Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@xxxxxxx>
To: "ext t.petch" <daedulus@xxxxxxxxxxxxx>; <stbryant@xxxxxxxxx>; "Adrian
Farrel" <adrian@xxxxxxxxxxxx>
Cc: "iesg" <iesg@xxxxxxxx>; "ietf" <ietf@xxxxxxxx>
Sent: Saturday, December 03, 2011 8:08 PM

Tom hi,
If this is Ethernet OAM delivered *transparently* over MPLS-TP networks,
then there is *no* need for a code point, they can simply use PWs.
If this is a solution aims to provide an alternative OAM solution for
MPLS-TP networks, and it is based on G.8110.1 and G.8110, and uses the
MPLS EtherType, then it is part of MPLS and MPLS-TP.
I believe it is the second case, therefore it requires the MPLS review
and a follow-up of the MPLS change process.

<tp>
Nurit

Yes, I think that it is more along the lines of the second case, an alternative
OAM solution, but it is the status of G.8113.1 that is in question, with Russ
saying that it cannot be part of MPLS-TP!
ITU-T are actively removing references thereto as in
the .pdf's that the ITU-T have made available to us, URI in the e-mail
from Russ, one of which says
<quote>

From: Johnson, Malcolm Sent: 01 December 2011 10:27 To: 'Russ Housley' Subject:
RE: MPLS
Dear Russ
..
(2) I attached a contribution which proposes amendments to the determined text
in COM15-R22. This includes the title change and makes changes to the
terminology throughout the document. What had previously been called "MPLS-TP
OAM" is now never referred to as such, but simply as "OAM" or "data-plane OAM".
As you can see there is a willingness to satisfy all the IETF concerns but if
there is still something else in the body of the draft Recommendation that
causes concern could you please specify what exactly it is so it can be
addressed?
</quote>

So my take is that the I-D we have needs review as specified in RFC4929, and the
IESG may well
decide that that involves review on the MPLS list, but I remain unconvinced that
that
makes in part of MPLS-TP; MPLS-TP has its OAM and does not need another one,
but some participants in the ITU-T do want another, 'not-MPLS-TP' OAM, and for
that, have requested a code point.  Obviously, this needs further discussion on
a suitable list
which we will doubtless engage in before too long.

Incidentally, has G.8113 been liaised to the MPLS WG?  If so, I might have
missed that.

Tom Petch
</tp>

Best regards,
Nurit


-----Original Message-----
From: ext t.petch [mailto:daedulus@xxxxxxxxxxxxx]
Sent: Saturday, December 03, 2011 7:44 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@xxxxxxxxx; Adrian
Farrel
Cc: iesg; ietf
Subject: Re: Request to publish
draft-betts-itu-oam-ach-code-point-01.txt

----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@xxxxxxx>
To: <stbryant@xxxxxxxxx>; "Adrian Farrel" <adrian@xxxxxxxxxxxx>
Cc: <draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx>;
<iesg@xxxxxxxx>;
<Ietf@xxxxxxxx>
Sent: Saturday, December 03, 2011 5:06 PM
> Hi,
> I fully support Stewart!
> G.8113.1 proposes a OAM solution for MPLS-TP networks.
> It uses the MPLS EtherType (when transmitted inband and getting the
same
> treatment as the data traffic).
> The document is built on G.8110.1 (MPLS-TP architecture) which refers
to
> G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back...
> This makes it part of MPLS and MPLS-TP.

Nurit and others,

I would commend to you the e-mail that Russ posted here 30Nov2011 in
which he
says, to Malcolm Johnson, Director of the ITU Telecommunication
Standardization
Bureau,

>> IETF consensus continues to be required to allocate the code point.
My
experience leads me to believe that careful clarity about the proposed
content
changes to G.8113.1, as well as specific clarity that G.8113.1 is not
part of
MPLS and MPLS-TP, will aid in achieving such a consensus. The current
situation
has engendered quite a bit of ambiguity in wording which, in my
experience, will
not produce IETF consensus.

so claiming what is and is not part of MPLS-TP calls for some thought.

My interpretation is that this is not part of MPLS-TP, but that the code
point
should be allocated in accordance with RFC4929 which, as I pointed out
on the
MPLS list, does not require a standards track RFC and requires review by
what
the IESG considers suitable, which could, or could not, include the MPLS
list;
but the starting point should be the prior art which Russ has provided
us with.

The deadline would appear to be 12Jan2012 which Malcolm and Huub would
appear to have provided us with the wherewithall to meet.

Tom Petch

> And it should be reviewed by the MPLS WG.
> Best regards,
> Nurit
>
> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf
Of
> ext Stewart Bryant
> Sent: Friday, December 02, 2011 1:55 PM
> To: Adrian Farrel
> Cc: draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; iesg@xxxxxxxx;
> Ietf@xxxxxxxx
> Subject: Re: Request to publish
> draft-betts-itu-oam-ach-code-point-01.txt
>
> Adrian
>
> "It is the opinion of the document shepherd that discussion of
> this document on the working group lists would be a distraction
> from the technical protocol work that the working groups
> need to do."
>
> I disagree with the document shepherd in his evaluation.
>
> The draft clearly sets out to enable the standardization
> of an additional OAM for MPLS, and as such the MPLS WG
> need to review the document and its references to
> determine the consequences of the technology  being
> deployed.
>
> Furthermore, all MPLS documents that have so far requested
> ACH codepoints have I believe been standards track. Why
> is this not also a standards track document?
>
> Stewart
>
>



_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]