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

From: Rui Costa <[email-masked]>
Date: Fri, 8 Jul 2011 01:14:42 +0100

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:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: [email-masked]; Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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 a 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 a minority sport to mainstream, so it is a bit late to cry foul....

My 2 cents
Dave

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: [email-masked]; [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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: [email-masked] [mailto:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 18:34
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 18:26
To: [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: [email-masked]; IETF-Announce; [email-masked]
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:[email-masked]] 
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: [email-masked]; IETF-Announce
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
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
[email-masked] mailing lists by 2011-07-14. Exceptionally, comments may be
sent to [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

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

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 06:25:55 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, July 08, 2011 12:16 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
>
>
>
>
>
>
>
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Rui Costa
> > Sent: 08 July 2011 01:15
> > To: David Allan I; Stewart Bryant
> > 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,
> >
> > 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.
> > (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
> > ...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...
> > 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.
> > 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.
> >
> >
> > 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>
> > E> This is a true statement: the solution in this draft is useless
> for
> > many MPLS- TP deployments.
> >
> > 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 a
> > 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
> a
> > minority sport to mainstream, so it is a bit late to cry foul....
> >
> > My 2 cents
> > Dave
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> > 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
> >
> > 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
> >
> > 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,
> >
> > working group last call; these  comments - and the intended
> resolution
> > -
> > 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
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Rui Costa
> > 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.
> >
> > The v04 draft addressing WG LC comments was published on the 28th
> June
> > (same date as the proto write-up).
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > The IESG
> > 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
> > [email-masked] mailing lists by 2011-07-14. Exceptionally, comments
> may
> > be

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 08:15:57 +0100

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

> draft you are free to do it. These standards have a great impact in our
> (BTW: can't understand how we propose one ACH codepoint to CC, another
> focus on that profile/configuration. However, i keep seeing references
> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not
> compatible with previous BFD (even considering just CC/CV). They don't
> auto/negotiated -) means OK. A standard defined number of misses means
> What we established during discussions at the SG15 plenary in February
> functionality they did not see a need for, and that they considered any
> new application. I do not see any way around that. And the entire joint
> 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 a
> Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
> Subject: R: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
> IETF. My spreadsheet from which that report was generated and has been

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 14:37:05 +0100

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

> From: John E Drake [mailto:[email-masked]]
> Sent: 08 July 2011 14:26
> To: Harrison,N,Neil,DKQ7 R; [email-masked];
> [email-masked]; [email-masked]
> 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
>
>
> > > Does chapter 4 contain ALL the configurable parameters list agreed
> to
> > > provide in the comparison session?
> > >
> > > Backwards compatibility
> > > IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and
> more
> > > difficult to tell which is which.
> > >
> > > Regards,
> > > Rui
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The poll for its adoption as a WG document was halted by the MPLS
> WG
> > > chair
> > > After several WG revisions and WG LCs, the technical issues have
> not
> > > been
> > > resolved.
> > >
> > >             It has also passed a working roup call to verify that
> LC
> > > comments
> > >             carefully discussed between the authors and people
> making
> > > the
> > > comments and
> > >             has been resolved.
> > >
> > >    associated End Point, a fault or defect condition that it
> detects
> > on

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 8 Jul 2011 11:26:36 -0400

> -       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/respon…

	While you are entitled to your opinion, I personally think there are enough requirements elsewhere to have both CC and CV functions.  But we digress. Are you actually asking that the CC functionality be removed from the draft or just making a general comment?

> -       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 manufactu…

	What does that comment have to do with the actual draft in question?

> -       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…

	Again, what does this have to do with the actual draft in question?

	--tom

---

From: John E Drake <[email-masked]>
Date: Fri, 8 Jul 2011 08:30:37 -0700

Neil,

AIS and CC are ITU requirements but I personally agree with you regarding their utility.  TCM is an ITU concept that doesn't really apply in an MPLS context because of the way the label stack works, and as I have told you before, the tap-off function you mention is sensible but it is strictly an implementation issue - no protocol work is required.

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 08, 2011 6:37 AM
> To: John E Drake; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
>
> > > > ...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;
> > > > However this is a consequence of adapting an existing technology
> to
> > a
> > > > This is a true statement: the solution in this draft is useless
> for
> > > > many MPLS-
> > > > TP deployments.
> > > >
> > > >
> > > > the comments. When ITU-T Q10/15 has been involved in discussing
> its
> > > > comments?
> > > >
> > > >
> > > >
> > > >
> > > >   comments. Version -05 was published on June 29 and the IETF
> last
> > > call
> > > >   The current list of Last Call Comments resoltion is also
> avaiable
> > > at:
> > > > final comments on this action. Please send substantive comments
> to
> > > the
> > > >    continuity verification, and remote defect indication for
> MPLS-
> > TP

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 8 Jul 2011 17:33:53 +0200

Hi,
Just to make it clear, this is not a discussion on the requirements. I
would like to encourage this kind of discussion but in the right
context.
The CC-CV-RDI draft aims to satisfy the OAM requirements which are
specified in RFC 5860. One of the requirements there is to provide a
tool for CC as well as for CV. 
In the context of this LC, we should focus now on the proposed solution.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Thomas Nadeau
Sent: Friday, July 08, 2011 6:27 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] LastCall: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
(Proactive Connectivity Verification,Continuity Check and Remote Defect
indicationfor MPLS Transport Profile) to Proposed Standard

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).

	While you are entitled to your opinion, I personally think there
are enough requirements elsewhere to have both CC and CV functions.  But
we digress. Are you actually asking that the CC functionality be removed
from the draft or just making a general comment?

> -       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.

	What does that comment have to do with the actual draft in
question?

> -       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.

	Again, what does this have to do with the actual draft in
question?

	--tom

confidential.
not the intended
information
know immediately
Of
our
another
references
not
don't
means
for
February
any
joint
the
a
resolution
been
Of
June
Of
Switching
may

---

From: David Allan I <[email-masked]>
Date: Fri, 8 Jul 2011 12:13:18 -0400

Rui:

You wrote:

>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.

Numerous comments did have effect on the draft and those that didn't were either simply not actionable, were rhetorical or not constructive, and a few had to be balanced against comments coming from the MPLS & BFD WGs. I would translate "ingored" or "without effect" to "did not get one'e way". In the standards process it happens.

Meanwhile as an editor of the document, I'll take the liberty of responding to some of the points you raise...

>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting;

I and the WG don't really have access to private grumblings.

>...in a comparison session that took place during that same ITU-T meeting.

Lots of other opinions were expressed as well, and they did not all agree with you.

>Besides adding complexity, we whether always activate both or potentiate undetected mismerges.

OK, lets walk through this.

We want CV all the time so that any misconectivity can be detected, but on the list it was expressed that the group did not want the overhead of processing the source MEP TLV in every packet in order to achieve this. We could carry it in every packet and have the receiver simply ignore most of them, but then that would make the defect entry criteria compeltely random and the exit criteria unreliable as well, not really a good design. Hence they are separated using different ACH code points and the receiver is obliged to process every source MEP TLV it receives. I hope this is clear.

>(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)

Because that puts you into two protocol ID demultiplexing steps per OAM PDU recevied to determine the intended function. Hence COSTS MORE. That is pretty basic...

> (BFD's B="bidirectional")

I would not go so far as to say "similar to 1731", there is actually a lot of difference under the hood. As for uni-directional BFD, that is a BFD WG problem at the moment.

> 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.

It should. As for encapsulations, unless TP is in a complete island not connected to anything (which as a network is rather useless) it will be expected to interoperate with the rest of the MPLS architecture, and the stated intention of tool development was that what resulted was applicable to the broader MPLS architecture. Which means backwards compatiblity and procedures for interoperation.

> 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.

The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic.

>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.

Well IMO there was not a lot of interest in T-MPLS until the IETF was going to re-define it and make it compatible with IP/MPLS. So there was an industry wide "design intent" implied here.

> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which.

That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite.

Hope this helps
D

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: [email-masked]; Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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>

My 2 cents
Dave

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: [email-masked]; [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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:

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:34
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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 poll for its adoption as a WG document was halted by the MPLS WG chair because "it is not possible to judge consensus":

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

After several WG revisions and WG LCs, the technical issues have not been resolved.

>Several service providers regarded this draft as not meeting their

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:26
To: [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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

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:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: [email-masked]; IETF-Announce; [email-masked]
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,

  Loa

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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:

So you know...
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: [email-masked]; IETF-Announce
Cc: [email-masked]
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:

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
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

Abstract

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 17:13:36 +0100

Thanks Tom...these are general observations which I think are valid and respond to Rui's point about the need for simplicity....and they are as much directed to folks pushing overblown OAM in ITU as folks in IETF.  You may of course disagree with them.  I recall someone once saying MPLS did not need DP OAM at all....

regards, Neil

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: 08 July 2011 16:27
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; ietf-
> [email-masked]
> 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
> are enough requirements elsewhere to have both CC and CV functions.
> But we digress. Are you actually asking that the CC functionality be
> removed from the draft or just making a general comment?
>
> 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.
>

---

From: David Allan I <[email-masked]>
Date: Fri, 8 Jul 2011 12:30:07 -0400

I think there is some confusion here....

The only CC in isolation in the draft is the option to use RFC 5885. Which then is a network design issue.

Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY PDU that requires CV processing so there are CC and CV PDUs interleaved. Mis-connectivity detection is network wide and fairly authoritative (unless we are discussing a mode of failure in which only "some" packets leak, which means even an always on CV may not be so unlucky as to leak and be detected).

So I think we are in agreement on that front...
Dave

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Friday, July 08, 2011 8:27 AM
To: [email-masked]
Cc: [email-masked]; David Allan I; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

        --tom

> 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.
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
> England no: 1800000
>
>
>
>
>
>
>
>> Of Rui Costa
>> our work, so i'm also free to write what i did.
>>
>>
>>
>>
>> Stewart,
>>
>> ...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
>> 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
>> ...using IP to create the reverse way, which we cannot assume per
>> requirements; Will we create a complete different tool for that?
>> 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.
>> don't even share the same codepoint.
>>
>> Simplicity
>> means lost Rx connection. An RDI, the only articulation between Rx
>> and Tx flows, meaningful in bidirectional applications, allows each
>> E> for
>> 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.
>>
>> 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 a minority sport to mainstream, so it is a bit late to cry foul....
>>
>> My 2 cents
>> Dave
>>
>>
>>
>>
>> The poll for its adoption as a WG document was halted by the MPLS WG
>> chair because "it is not possible to judge consensus":
>>
>> The lack of consensus was motivated by serious technical concerns
>> raised by several transport experts during the poll.
>>
>>            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
>> 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?
>>
>>
>>
>>
>> questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details
>> below.
>>
>> On February 3rd 2011 the working group last call was issued on
>> version -03
>>
>> The authors compiled a list of all comments received  as part the
>> MPLS working group last call; these  comments - and the intended
>> resolution
>> -
>>  The authors have since worked hard to resolve comments, some  issue
>> has been brought to the working group mailing list for  resolution.
>>
>>  The list of issues that the authors kept very carefully, shows
>> without doubt  that no comments been ignored.
>>
>>  Loa
>> been augmented to include the BFD WG comments is available at
>> Of Rui Costa
>> June (same date as the proto write-up).
>> Of The IESG
>> Switching WG
>> final comments on this action. Please send substantive comments to
>> the [email-masked] mailing lists by 2011-07-14. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 17:39:32 +0100

Thanks Dave.  If we don't have this (ie CV function on all connections/LSPs) then there is potential security risk wrt leaking traffic.  Note that besides trad nested sublayered LSPs in the same layer network this also applies to nested LSPs belonging to different MPLS-TP layer networks (may be same or different party ownership).  This point about the OAM CV function also ought to be captured in any security drafts.

regards, Neil

> Sent: 08 July 2011 17:30
> To: Thomas Nadeau; Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Draft cc-cv-rdi used by itself is CV always on. It is just not EVERY
> PDU that requires CV processing so there are CC and CV PDUs
> interleaved. Mis-connectivity detection is network wide and fairly
> authoritative (unless we are discussing a mode of failure in which only
> "some" packets leak, which means even an always on CV may not be so
> unlucky as to leak and be detected).
>
> Cc: [email-masked]; David Allan I; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
>         While you are entitled to your opinion, I personally think
> there are enough requirements elsewhere to have both CC and CV
> functions.  But we digress. Are you actually asking that the CC
> functionality be removed from the draft or just making a general
> comment?
>

---

From: David Allan I <[email-masked]>
Date: Fri, 8 Jul 2011 12:42:01 -0400

Hi Neil:

As a result of Adrians AD review, some text to that effect was added to the Security Considerations section.

Have a good weekend
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 08, 2011 9:40 AM
To: David Allan I; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

regards, Neil

> authoritative (unless we are discussing a mode of failure in which
> only "some" packets leak, which means even an always on CV may not be
> so unlucky as to leak and be detected).
>
> (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).
>
> 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.
>
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Rui Costa
> >> Sent: 08 July 2011 01:15
> >> 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,
> >>
> >> Feb/2011 plenary meeting; ...in a comparison session that took
> >> place during that same ITU-T meeting.
> >> Some:
> >>
> >> CC/CV
> >> ...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...
> >> 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>
> >> greenfield design. That is what it said on the tin up front, and
> >> IMO why when the IETF started down this path packet transport
> >> 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:
> >>
> >> February where the comments originated. The revised meeting
> >> schedule resulted in a day spent going through the document with the editors.
> >> WG chair because "it is not possible to judge consensus":
> >>
> >> not been resolved.
> >> making the comments and
> >> issue has been brought to the working group mailing list for  resolution.
> >>
> >>  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
> >> 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
> >> 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.
> >>

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 17:43:56 +0100

Excellent...well done Adrian!  Thanks Dave for the info.  Have a nice one yourself....

regards, Neil

> Sent: 08 July 2011 17:42
> To: Harrison,N,Neil,DKQ7 R; [email-masked]
> Thanks Dave.  If we don't have this (ie CV function on all
> connections/LSPs) then there is potential security risk wrt leaking
> traffic.  Note that besides trad nested sublayered LSPs in the same
> layer network this also applies to nested LSPs belonging to different
> MPLS-TP layer networks (may be same or different party ownership).
> This point about the OAM CV function also ought to be captured in any
> security drafts.
>
> regards, Neil
>
> > >> Behalf Of The IESG

---

From: Rui Costa <[email-masked]>
Date: Thu, 14 Jul 2011 18:32:48 +0100

David,

T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our interest started with ITU-T's work in T-MPLS and not when IETF joined.

We value IETF's work, and in 2008, when the IETF rose doubts about future interoperability between T-MPLS and MPLS/IP (and the "danger to the internet"), even though all T-MPLS Recommendations were approved and the OAM one was ready for approval, a decision was made to listen carefully to MPLS/IP's top experts' input.

IETF's unilateral decision to select BFD was IMHO a surprise: being a primary goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/expertise or at least a compromise between the 2 SDOs. ITU-T's not just a boilerplate stamper.
Hearing that "the decision was expressed in mpls-tp-analysis draft" was another surprise: among the possible ways, the document showed, IMHO, 1731 as the closest one to requirements.

We don't need a requirement to agree on reusing as most as possible MPLS and PW: it's common sense. However, it can't distract us from primary goals.

"The issue is not code point, which is the trivial part. It is reuse of the majority of the implementation. Again, pretty basic."
In other words, the problem is not backwards compatibility, (ergo the "danger to the internet" problem never really existed) but maintaining particular deployed platforms. If we had to convert cars into planes, we couldn't say "to reuse the implementation, we can't add wings": they wouldn't fly.
I'm used to FW/HW development and i don't share your cost/simplicity view. (Please check other LC responses on this particular point.) I know field network support and think you'd change your opinion if you had to work on 24h field network support.

I agree with you that other opinions exist, counting not only manufacturers but also operators. On the operators that don't agree with you are certainly clients of yours. It's none of my business that you view their opinions as "grumblings", but that's far from describing the polls' results in the Feb2011 WG3 and SG15 plenaries, showing a minority sharing your view, and that, although those not subscribing it tolerate its evolution, you don't theirs.
Operators and their clients are the ones that, at the end of the day, pay for networks. From the above, it'll be IMHO impossible to understand if these Recommendations don't take into account these "grumblers'" view, other than the obsession of those insisting to sell swiss knifes to those who just want sharp scalpels. Why don't we call that also "not constructive"?
"[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more difficult to tell which is which.
[D:]That is because MPLS-TP is not a new techology, it is an addition to the entire MPLS protocol suite."
Yes, i understand your view, David, but i'm sure you and i don't subscribe this one:
"The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which".

Hope this helps. My comrade cents,
Rui

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: [email-masked]; [email-masked]; [email-masked]; IETF-Announce
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

Rui:

Hope this helps
D

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: [email-masked]; Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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>

My 2 cents
Dave

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: [email-masked]; [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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:

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:26
To: [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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

The proto write-up says:

It also says:

            The comments has been

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: [email-masked]; IETF-Announce; [email-masked]
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,

  Loa

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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:

So you know...
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: [email-masked]; IETF-Announce
Cc: [email-masked]
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:

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
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

Abstract

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 14 Jul 2011 19:49:57 +0200

Rui,
I kindly propose not to refer in this context to the Feb2011 WP3 and
SG15 plenary meetings....
Very unfortunately, it was far away from being a technical
discussion.....or technical poll. 
Therefore it cannot be a reference to any argument in this context.  
Regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Rui Costa
Sent: Thursday, July 14, 2011 8:33 PM
To: David Allan I
Cc: [email-masked]; [email-masked]; IETF-Announce
Subject: RE: [mpls] Last Call:
<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity
Verification, Continuity Check and Remote Defectindication for MPLS
Transport Profile) to Proposed Standard

David,

T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the
simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the
work in T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our
interest started with ITU-T's work in T-MPLS and not when IETF joined.

We value IETF's work, and in 2008, when the IETF rose doubts about
future interoperability between T-MPLS and MPLS/IP (and the "danger to
the internet"), even though all T-MPLS Recommendations were approved and
the OAM one was ready for approval, a decision was made to listen
carefully to MPLS/IP's top experts' input.

IETF's unilateral decision to select BFD was IMHO a surprise: being a
primary goal in T-MPLS, i'd assume OAM definition was ITU-T's
responsibility/expertise or at least a compromise between the 2 SDOs.
ITU-T's not just a boilerplate stamper.
Hearing that "the decision was expressed in mpls-tp-analysis draft" was
another surprise: among the possible ways, the document showed, IMHO,
1731 as the closest one to requirements.

We don't need a requirement to agree on reusing as most as possible MPLS
and PW: it's common sense. However, it can't distract us from primary
goals.

"The issue is not code point, which is the trivial part. It is reuse of
the majority of the implementation. Again, pretty basic."
In other words, the problem is not backwards compatibility, (ergo the
"danger to the internet" problem never really existed) but maintaining
particular deployed platforms. If we had to convert cars into planes, we
couldn't say "to reuse the implementation, we can't add wings": they
wouldn't fly.
I'm used to FW/HW development and i don't share your cost/simplicity
view. (Please check other LC responses on this particular point.) I know
field network support and think you'd change your opinion if you had to
work on 24h field network support.

I agree with you that other opinions exist, counting not only
manufacturers but also operators. On the operators that don't agree with
you are certainly clients of yours. It's none of my business that you
view their opinions as "grumblings", but that's far from describing the
polls' results in the Feb2011 WG3 and SG15 plenaries, showing a minority
sharing your view, and that, although those not subscribing it tolerate
its evolution, you don't theirs.
Operators and their clients are the ones that, at the end of the day,
pay for networks. From the above, it'll be IMHO impossible to understand
if these Recommendations don't take into account these "grumblers'"
view, other than the obsession of those insisting to sell swiss knifes
to those who just want sharp scalpels. Why don't we call that also "not
constructive"?
"[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and
more difficult to tell which is which.
[D:]That is because MPLS-TP is not a new techology, it is an addition to
the entire MPLS protocol suite."
Yes, i understand your view, David, but i'm sure you and i don't
subscribe this one:
"The creatures outside looked from pig to man, and from man to pig, and
from pig to man again; but already it was impossible to say which was
which".

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: [email-masked]; [email-masked]; [email-masked];
IETF-Announce
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

Rui:

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.

Numerous comments did have effect on the draft and those that didn't
were either simply not actionable, were rhetorical or not constructive,
and a few had to be balanced against comments coming from the MPLS & BFD
WGs. I would translate "ingored" or "without effect" to "did not get
one'e way". In the standards process it happens.

believe);

Lots of other opinions were expressed as well, and they did not all
agree with you.

We want CV all the time so that any misconectivity can be detected, but
on the list it was expressed that the group did not want the overhead of
processing the source MEP TLV in every packet in order to achieve this.
We could carry it in every packet and have the receiver simply ignore
most of them, but then that would make the defect entry criteria
compeltely random and the exit criteria unreliable as well, not really a
good design. Hence they are separated using different ACH code points
and the receiver is obliged to process every source MEP TLV it receives.
I hope this is clear.

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)

Because that puts you into two protocol ID demultiplexing steps per OAM
PDU recevied to determine the intended function. Hence COSTS MORE. That
is pretty basic...

> ...using IP to create the reverse way, which we cannot assume per
requirements;
> (BFD's B="bidirectional")

I would not go so far as to say "similar to 1731", there is actually a
lot of difference under the hood. As for uni-directional BFD, that is a
BFD WG problem at the moment.

> Does chapter 4 contain ALL the configurable parameters list agreed to
provide in the comparison session?

It should. As for encapsulations, unless TP is in a complete island not
connected to anything (which as a network is rather useless) it will be
expected to interoperate with the rest of the MPLS architecture, and the
stated intention of tool development was that what resulted was
applicable to the broader MPLS architecture. Which means backwards
compatiblity and procedures for interoperation.

> 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.

The issue is not code point, which is the trivial part. It is reuse of
the majority of the implementation. Again, pretty basic.

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

Well IMO there was not a lot of interest in T-MPLS until the IETF was
going to re-define it and make it compatible with IP/MPLS. So there was
an industry wide "design intent" implied here.

> IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more
difficult to tell which is which.

That is because MPLS-TP is not a new techology, it is an addition to the
entire MPLS protocol suite.

Hope this helps
D

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 19:25
To: [email-masked]; Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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>
>transport networks' needs.

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

My 2 cents
Dave

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:36
To: [email-masked]; [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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: [email-masked] [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:34
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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 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:

After several WG revisions and WG LCs, the technical issues have not
been resolved.

>Several service providers regarded this draft as not meeting their

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 18:26
To: [email-masked]; Rui Costa
Cc: [email-masked]; [email-masked]; 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

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

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

The proto write-up says:

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:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 16:44
To: Rui Costa
Cc: [email-masked]; IETF-Announce; [email-masked]
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,

  Loa

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: quarta-feira, 6 de Julho de 2011 14:58
To: Rui Costa; [email-masked]; IETF-Announce
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Rui Costa
Sent: segunda-feira, 4 de Julho de 2011 23:03
To: [email-masked]; IETF-Announce
Cc: [email-masked]
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.

[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: [email-masked] [mailto:[email-masked]] On Behalf Of
The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
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

[email-masked] mailing lists by 2011-07-14. Exceptionally, comments may

Abstract