RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive C

Not recently John.  But my comments are general and not specific to this draft. 
 But it seems you are implying that the draft recognises my points.  If so I 
will look forward to reading it later today when I get chance and seeing AIS 
deprecated, TCM deprecated, CC functions deprecated, ability to tap off end-end 
CV/PM flows at intermediate nodes.

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the 
intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know 
immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

-----Original Message-----
From: John E Drake [mailto:jdrake(_at_)juniper(_dot_)net]
Sent: 08 July 2011 14:26
To: Harrison,N,Neil,DKQ7 R; RCosta(_at_)ptinovacao(_dot_)pt;
david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com; 
stbryant(_at_)cisco(_dot_)com
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
ietf-announce(_at_)ietf(_dot_)org
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

Neil,

I have a question for clarification.  Have you actually read draft-
ietf-mpls-tp-cc-cv-rdi-05.txt?  I know you don't like doing this but
generally it is considered good form to read something before
commenting on it.

Thanks,

John

Sent from my iPhone

-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org 
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf

Of

neil(_dot_)2(_dot_)harrison(_at_)bt(_dot_)com
Sent: Friday, July 08, 2011 12:16 AM
To: RCosta(_at_)ptinovacao(_dot_)pt; 
david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com;
stbryant(_at_)cisco(_dot_)com
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
ietf-announce(_at_)ietf(_dot_)org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

Got to say I agree with Rui on much of what he says here.  And I
absolutely resonate with his point on the need for simplicity.  The
reason OAM needs to be as simple as possible is because it must be
super reliable....we do not want to consciously build in weaknesses,
esp unnecessary ones.... this also implies minimal config.  We could
all do better on this.  For example:

-       Rui is dead right a CC function is fairly useless, we only

need

a CV function...the ATM OAM in I.610 suffers from this problem (and

few

others like AIS and the assumed use of request/response MLT to

diagnose

leaking/mismerging traffic...request/response OAM won't work with
unidirectional defects).

-       all packet layer networks should not have an AIS OAM
message....very obvious for the cl-ps mode of course.  The co-ps mode
is also not like the co-cs mode.  One has to consciously manufacture
AIS messages and target them to specific clients in the co-ps
mode....who may have taken action in their own layer network and

'moved

elsewhere' anyway, ie a total waste of time now.  AIS is actually
unnecessary wrt providing information anyway, it simply represents an
in-built weakness of just something else to go wrong which itself

will

create problems.

-       creating preconfigured TCM sublayers is just asking for

trouble

IMO.  It is far smarter to simply create a single end-end OAM CV (and
when required PM) flow and tap this off at intermediate nodes on the
*rare* occasions one wants to do.

regards, Neil

This email contains BT information, which may be privileged or
confidential.
It's meant only for the individual(s) or entity named above. If

you're

not the intended
recipient, note that disclosing, copying, distributing or using this
information
is prohibited. If you've received this email in error, please let me
know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org 
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On

Behalf

Of

Rui Costa
Sent: 08 July 2011 01:15
To: David Allan I; Stewart Bryant
Cc: ietf(_at_)ietf(_dot_)org; IETF-Announce; mpls(_at_)ietf(_dot_)org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

David,

Reading something, keeping it on record, without effect in the

draft

and "ignoring comments" have IMHO similar outcomes. As author of

the

draft you are free to do it. These standards have a great impact in

our

work, so i'm also free to write what i did.




Stewart,

My technical concerns regarding this draft were expressed...
...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i
believe);
...in operators' meetings' that took place during ITU-T's Feb/2011
plenary meeting;
...in a comparison session that took place during that same ITU-T
meeting.
Some:

CC/CV
I don't understand the need for 2 types of packets: a single type
allows CC; mismatching identifiers in the same CC packets allow CV.
Besides adding complexity, we whether always activate both or
potentiate undetected mismerges.
(BTW: can't understand how we propose one ACH codepoint to CC,

another

for CV, [counting other drafts, another for frame loss ...] but

don't

consider assigning 1 single ACH protocol identifier codepoint as
requested by ITU-T)

Uni P2P / P2MP
I can't see how BFD will support unidir and hence P2MP other

than...


...eliminating the session "state variable" (down, init, up),

aiming

just the state variables we really need, bringing us to something
similar to 1731, eventually with other bits on the wire or...
...using IP to create the reverse way, which we cannot assume per
requirements;
Will we create a complete different tool for that?
(BFD's B="bidirectional")

Provisioning list
This is an MPLS profile/subset (and i heard) achievable through a
particular configuration. So, i expect each draft-ietf-mpls-TP-* to
focus on that profile/configuration. However, i keep seeing

references

f.i. to IP encapsulations unexpected under TP's OAM.
I don't thus understand what the aim is: do we expect this in TP,

are

we talking about MPLS in general?... The TP profile is never quite
delimited.
Does chapter 4 contain ALL the configurable parameters list agreed

to

provide in the comparison session?

Backwards compatibility
This was the main argument risen to ground MPLS-TP OAM on BFD. It's

not

a better argument than grounding MPLS-TP OAM on 1731 due to its ETH
deployment plus coherence with SDH, OTN, as defended by ITU-T.
For reasons like the above, however, MPLS-TP BFD won't be backwards
compatible with previous BFD (even considering just CC/CV). They

don't

even share the same codepoint.

Simplicity
Whether we look to PDH, SDH, OTN or ETH, ITU-T's approach to CC is
simpler: in each flow, a standard defined nr of constant heartbeat
signals (with standard constant or provisioned period - no
auto/negotiated -) means OK. A standard defined number of misses

means

lost Rx connection. An RDI, the only articulation between Rx and Tx
flows, meaningful in bidirectional applications, allows each pear

to

identify Tx problems.
This OAM simplicity is the key for reliable fail finger pointing,
performance reports and protection. Also to allow scaling, more
implementation opportunities/manufacturers, which is valuable for
operators.


IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and

more

difficult to tell which is which.

Regards,
Rui









-----Original Message-----
From: David Allan I 
[mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: erminio(_dot_)ottone_69(_at_)libero(_dot_)it; Rui Costa; 
ietf(_at_)ietf(_dot_)org; IETF-
Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-

rdi-

05.txt> (Proactive Connectivity Verification, Continuity Check and
Remote Defect indication for MPLS Transport Profile) to Proposed
Standard

Hi Erminio:

<snipped>

Several service providers regarded this draft as not meeting their
transport networks' needs.


E> This is a true statement: the solution in this draft is useless

for

many MPLS- TP deployments.

The two statements do not necessarily follow.

What we established during discussions at the SG15 plenary in

February

was that the issue some service providers had was that the IETF BFD
solution exceeded their requirements in that there was additional
functionality they did not see a need for, and that they considered

any

additional functionality parasitic.

However this is a consequence of adapting an existing technology to

new application. I do not see any way around that. And the entire

joint

project was based on the premise of engineering re-use not

greenfield

design. That is what it said on the tin up front, and IMO why when

the

IETF started down this path packet transport transitioned from

being

minority sport to mainstream, so it is a bit late to cry foul....

My 2 cents
Dave




-----Original Message-----
From: David Allan I 
[mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: erminio(_dot_)ottone_69(_at_)libero(_dot_)it; loa(_at_)pi(_dot_)nu; 
Rui Costa
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv-

rdi-

05.txt> (Proactive Connectivity Verification, Continuity Check and
Remote Defect indication for MPLS Transport Profile) to Proposed
Standard

Hi Erminio:

Two of the three document editors were present at SG15 plenary in
February where the comments originated. The revised meeting

schedule

resulted in a day spent going through the document with the

editors.

IMO there were lots of discussion and legitimate issues with the
document identified and corrected so it was a useful session. The
liaison of same was in many ways *after the fact*.

Cheers
Dave




-----Original Message-----
From: erminio(_dot_)ottone_69(_at_)libero(_dot_)it

[mailto:erminio(_dot_)ottone_69(_at_)libero(_dot_)it]

Sent: quarta-feira, 6 de Julho de 2011 18:34
To: Rui Costa; ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

The way this draft has been developed is a bit strange.

The poll for its adoption as a WG document was halted by the MPLS

WG

chair
because "it is not possible to judge consensus":

http://www.ietf.org/mail-archive/web/mpls/current/msg04502.html

The lack of consensus was motivated by serious technical concerns
raised by
several transport experts during the poll.

Nevertheless the MPLS WG chair decided to adopt the draft as a WG
document:

http://www.ietf.org/mail-archive/web/mpls/current/msg04512.html

After several WG revisions and WG LCs, the technical issues have

not

been
resolved.

Several service providers regarded this draft as not meeting their

transport
networks' needs.

This is a true statement: the solution in this draft is useless for
many MPLS-
TP deployments.


-----Original Message-----
From: erminio(_dot_)ottone_69(_at_)libero(_dot_)it

[mailto:erminio(_dot_)ottone_69(_at_)libero(_dot_)it]

Sent: quarta-feira, 6 de Julho de 2011 18:26
To: loa(_at_)pi(_dot_)nu; Rui Costa
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

 Version -04 of the document was published June 28th.

 The publication request for draft-ietf-mpls-tp-cc-cv-rdi was

sent

 June 29th.


So when the WG LC to confirm the LC comment resolution has been
launched?

The proto write-up says:

            It has also passed a working roup call to verify that

LC

comments
were correctly with minor comments.

It also says:

            The comments has been
            carefully discussed between the authors and people

making

the
comments and
            has been resolved.

But it seems that some comments have not been discussed with the
authors of
the comments. When ITU-T Q10/15 has been involved in discussing its
comments?




-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: ietf(_at_)ietf(_dot_)org; IETF-Announce; mpls(_at_)ietf(_dot_)org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

All,

Since someone has commented about the process used for resolving
questions on
draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below.

The history of draft-ietf-mpls-tp-cc-cv-rdi working group review
process is:

On February 3rd 2011 the working group last call was issued
on version -03

      This was copied to the the Ad Hoc Team List
      and liaised to SG15 also on February 3rd

      This working group last call ended om Feb 28


      On Feb 28 we also received a liaison with comments from SG15


The authors compiled a list of all comments received  as part the

MPLS

working group last call; these  comments - and the intended

resolution

-
is included in the meeting minutes from the Prague meeting:


      http://www.ietf.org/proceedings/80/slides/mpls-9.pdf


  During the IETF meeting in Prague, we agreed with the BFD working
  group to do a separate working group last callfor the BFD working
  group

The (BFD) working group last call was started on March 30th and ran
for 13 days. The last call ended on April 11th.

  The authors have since worked hard to resolve comments, some
  issue has been brought to the working group mailing list for
  resolution.

  Version -04 of the document was published June 28th.

  The publication request for draft-ietf-mpls-tp-cc-cv-rdi was

sent

  June 29th.

  The AD review resulted in a "New ID needed" due to mostly

editorial

  comments. Version -05 was published on June 29 and the IETF last

call

  started as soon as the new ID was avaialbe.

  The current list of Last Call Comments resoltion is also avaiable

at:

  http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls

  The list of issues that the authors kept very carefully, shows
without
doubt
  that no comments been ignored.

  Loa
  mpls wg document shepherd







-----Original Message-----
From: David Allan I 
[mailto:david(_dot_)i(_dot_)allan(_at_)ericsson(_dot_)com]
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

Hi Rui:

The comments were not ignored, the resolution of the Q10 comments

as

well as those collected from the MPLS WG was presented at the last
IETF. My spreadsheet from which that report was generated and has

been

augmented to include the BFD WG comments is available at
http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls

So you know...
Dave


-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On

Behalf

Of

Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-

05.txt>

(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard

IMHO and for the record:

ITU-T comments regarding this draft haven't been discussed with

ITU-T

but were simply ignored. No LS describing these comments'

resolution

was sent.

Several service providers regarded this draft as not meeting their
transport networks' needs.

[The v03 draft was published in Feb and went to WG LC.
The v04 draft addressing WG LC comments was published on the 28th

June

(same date as the proto write-up).
When was the WG LC launched, to verify LC comments resolution?]

Regards,
Rui


-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org 
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On

Behalf

Of

The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
(Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile) to Proposed Standard


The IESG has received a request from the Multiprotocol Label

Switching

WG
(mpls) to consider the following document:
- 'Proactive Connectivity Verification, Continuity Check and Remote
   Defect indication for MPLS Transport Profile'
  <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and

solicits

final comments on this action. Please send substantive comments to

the

ietf(_at_)ietf(_dot_)org mailing lists by 2011-07-14. Exceptionally, 
comments

may

be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain 
the
beginning of the Subject line to allow automated sorting.

Abstract

   Continuity Check, Proactive Connectivity Verification and Remote
   Defect Indication functionalities are required for MPLS-TP OAM.

   Continuity Check monitors the integrity of the continuity of the
   label switched path for any loss of continuity defect.

Connectivity

   verification monitors the integrity of the routing of the label
   switched path between sink and source for any connectivity

issues.

   Remote defect indication enables an End Point to report, to its
   associated End Point, a fault or defect condition that it

detects

on

   a pseudo wire, label switched path or Section.

   This document specifies methods for proactive continuity check,
   continuity verification, and remote defect indication for MPLS-

TP

   label switched paths, pseudo wires and Sections using

Bidirectional

   Forwarding Detection.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/


No IPR declarations have been submitted directly on this I-D.
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard