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: Mon, 4 Jul 2011 23:02:31 +0100

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

---

From: David Allan I <[email-masked]>
Date: Tue, 5 Jul 2011 11:52:37 -0400

Rui:

Ignored is a strong word....and does not bear scrutiny if you comapre the current document with the comments recevied. Attached is a spreadsheet of comment disposition for comments received during LC which included MPLS WG, BFD WG and those comments received from Q10.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: Monday, July 04, 2011 3:03 PM
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

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

---

From: David Allan I <[email-masked]>
Date: Wed, 6 Jul 2011 09:57:57 -0400

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: Monday, July 04, 2011 3:03 PM
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: Loa Andersson <[email-masked]>
Date: Wed, 06 Jul 2011 17:44:08 +0200

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

On 2011-07-05 00:02, Rui Costa wrote:
> 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
>
>

-- 

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

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 13 Jul 2011 15:02:25 +0200

Dear all,
I regret to say I have the same concerns expressed by Rui and Erminio about the procedure adopted for this document that has brought so many discussions. Anyway, probably because of the lack of a reasonable time (in my opinion) for discussions about the previous document version (-04) I have the following comments on this version:

1. it is not clear the BFD's scope
        Sect. 1: PW, LSP, SPME
        Sect. 1: LSP
        Sect 3: LSP
        Sect 3.1:LSP, PW
        Sect 3.3: PW, LSP, SPME, Section
        Sect 3.7: LSP

2. encapsulation
        Sect 1: supported encapsulation GAL/GACh, VCCV, UDP/IP: can be expressed a preference (MUST/MAY) for Transport Profile applications for interoperability issues? I would avoid single vendor networks coming from too many options.

3. diagnostic code 5
        Could you clarify what is the BFD state machine behavior receiving/transmitting a Diagn Code=5

4. detection time
        Sect 3.2: I expect it is that one defined in RFC5884 i.e. detect Mult x greater (bfd.requiredminrxinterval, last received desired min tx interval). What "interval" means is not clear

5. session periodicity
        Sec 3.3 Should be clarified being not defined in RFC5880

6. detection of loss of continuity
        Sect 3.3 can CV packet  sent on the wire replace CC packet (for LOC purpose on the far end)?

7. CV vs CC packets
        Sect 3.6 Generally speaking, how should the received CV packet's fields be managed with respect of the BFD state machine/BFD states? (beyond what is specified in such paragraph limited to P/F and Sta).

8. encoding
        Sect 3.5: could you clarify what " A BFD session will only use one encoding of the Source ID TLV" means?

9. editorial
        Source ID TLV, MEP source ID TLV, Source MEP TLV should be aligned

10. terminology
        Wrt sect 3.6 I would ask a clarification about the terminology where I found
        a- "A BFD session corresponds to a CC and proactive CV OAM instance"
        b- " A BFD session is enabled when the CC and proactive CV functionality is enabled"
        c- " When the CC and proactive CV functionality is disabled ..., the BFD session transitions to the ADMIN DOWN State and the BFD session ends"
                In the ADMIN DOWN state I understood I can have BFD control packet exchange between the end points. Is it consistent with CC/CV functionality disabled?
11. code points
        Code points are not specified in section 3.1 as stated

12. BFD fixed rate
        Sect 3.7 " This rate is a fixed value common for both directions of MEG for the lifetime of the MEG". Is this statement implying that MEG must be destroyed to be able to change the BFD rate? Should not be limited to the BFD session lifetime (to be clarified what it means... because moving to ADMIN DOWN state both ends could not be enough)

13. two BFD modes
        Sect 3.7 " Two independent BFD sessions are used for independent operation". In my opinion, this approach still remain a big limitation in BFD usage.
        Is it implementation specific the way the two ends distinguish between the two BFD modes?

14. bfd.RemoteDiscr
        Sect 3.7 " In coordinated mode, an implementation SHOULD NOT reset bfd.RemoteDiscr until it is exiting the DOWN state"
        Is it a deviation from BFD as specified in RFC 5880? If it is, could you clarified the reason for that?

15. bfd.RemoteDiscr
        Sect 3.7 Could you clarify the reasons behind different treatments for bfd.RemoteDiscr in coordinated mode and independent mode?

16. overall operation
        Sect 3.7 "Overall operation is as specified in [4] and augmented for MPLS in[8]"
        Are you sure that it can be generalized in that way? Should not be the case to specify more in details what applies and what do not apply?

17. IP-based BFD
        Sect 3.1  IP-based BFD can carry out CV functionality only if IP SA is public

18. CV during transient states
        Sect 3.2 for clarification: at start-up, CC are sent one per second. CV are sent in addition to CC (so we have two BFD packets per second)?

19. misconnections
        Sect 3.7.3 sect 3.7.3 states a misconnection bring BFD session to DOWN whilst it is not clear if sect 3.7.5 state that misconnection do not impact on BFD state transition

20. encapsulation modes
        Sect 4: if I understood well, there are 4 encapusulations and modes for BFD: UDP/IP/LSP; CC mode in G-ACh; UPD/IP in G-ACh e CC/CV mode in G-ACh.
        Do all of them satisfy transport requirements?
        I understand they are not interoperable (as well as the two BFD mode for the same CC/CV in G-Ach encapsulation). Is it correct?

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: mercoledì 6 luglio 2011 17:44
A: Rui Costa
Cc: [email-masked]; [email-masked]; IETF-Announce
Oggetto: 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

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:

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

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

  Loa

On 2011-07-05 00:02, Rui Costa wrote:
> 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
>
>
> [email-masked] mailing lists by 2011-07-14. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the

--

                                              +46 767 72 92 13 _______________________________________________

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 20:36:51 +0900

Sorry for resending.

The changes in this version have massive impact for CC/CV/RDI implementation.
We, venders, have kept making efforts on interoperability test again and again.
These changes spoil this effort.

Especially, revival of Poll/Final sequence doesn't make sense.
Originally, in my understanding, Poll/Final sequence was excluded from this draft
to avoid making HW implementation difficult. 

Even though it was difficult to change CC interval arbitrary, 
the problem should be solved by defining how to transit DOWN/INIT state to UP state.

The direction which reached consensus once should NOT be changed easily
in order to respond to the market requirements.

IMO, such major changes should NOT be added right before becoming RFC.

I found at least four major/minor changes as follows;
1)Revival of Poll/Final sequence
2)Change of MEP ID formats
3)Change of Diag. Code
4)Change of CV interleaved definition

BR,
Hideki

---

From: <[email-masked]>
Date: Fri, 15 Jul 2011 21:17:10 +0900

Hi Robert,

Thank you very much for your reply, 
and I am sorry for my late response.

See inline, marked with [HE];

>
>________________________________________
>From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
>Sent: Thursday, July 14, 2011 7:22 AM
>To: [email-masked]; [email-masked]
>Subject: Re: [mpls] Last Call:  <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivit
>
>[RR] preventing a peer from modifying the rate once the initial target rate was achieved  i.e arbitrary re-negotiation was  and is excluded, that was the "problem"  the group consensus was  to solve. 
>
>
>However P/F is needed to get from the initial 1 per second default rate to the desired rate. This and the rational for an initial P/F were discussed in detail back in March /April.
[HE]My understanding is far from yours.
The cc-cv-rdi-03 said 
"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.".
In my understanding, this meant that Poll/Final Sequence MUST NOT be used for GAL/G-ACh.
In other words, GAL/G-ACh MUST work well without Poll/Final Sequence
in the case of getting from initial state.
I think this was the group consensus.
If the consensus was only for re-negotiation, why was P/F excluded from GAL/G-ACh? 

>[RR] There is no problem in defining how to transit from Down/Init to UP state, it's covered in the existing state machine and is not changed. 
[HE]Sorry for lack of explanation.
I meant the interval change timing should be defined in the case of transition DOWN/INIT to UP state
without P/F sequence for GAL/G-ACh.

BR,
Hideki

>Cheers
>Rob
>This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>
>