Subject: [mpls] R: R: 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: "[email-masked]" <[email-masked]>
Date: Wed, 13 Jul 2011 22:51:32 +0200 (CEST)

It looks like this draft does not define a "single" solution for CC, CV and RDI 
function

>----Messaggio originale----
>Da: [email-masked]
>Data: 13-lug-2011 15.02
>A: "IETF-Announce"<[email-masked]>
>Cc: "[email-masked]"<[email-masked]>, "[email-masked]"<[email-masked]>
>Ogg: [mpls] R: Last Call:	&lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txt&gt;	
(Proactive Connectivity	Verification, Continuity Check and Remote Defect 
indication for	MPLS	Transport	Profile) to Proposed Standard
>
>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
>
>      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:
>> 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
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>--
>
>
>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 
_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>
>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.
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>