Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config

[Stewart Bryant <[e-mail]>]

Mach

The document has expired.

Please can you refresh with your current version and let the WG know if 
you still have outstanding comments to address.

I have received some comments direct to me. I have asked if the reviewer 
will post direct to the list. If not, I will include them in my review 
of the next version.

- Stewart



On 25/01/2016 02:02, Mach Chen wrote:
>
> Hi Sasha,
>
> Many thanks for your detailed review and comment!
>
> We’ll address them in the next revision.
>
> Best regards,
>
> Mach
>
> *From:*Pals [mailto:[e-mail]] *On Behalf Of *Alexander 
> Vainshtein
> *Sent:* Friday, January 22, 2016 11:08 PM
> *To:* Stewart Bryant
> *Cc:* [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> *Subject:* Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config
>
> Stewart (and all),
>
> Following your call for volunteers I have read the draft (or, at least 
> most of it – I did not go into detail regarding the part that 
> discusses PM functions), and I have multiple concerns regarding it. I 
> have sent most of these concerns to the authors off-list, and received 
> some feedback from Mach. My concerns are listed below:
>
> 1._References to some basic documents are missing and/or incomplete_:
>
> a.RFC 4447:
>
> i.From my POV, the draft is about some extensions to RFC 4447, but 
> this document is only mentions this document in Section 6 “Security 
> Considerations”
>
> ii.The draft silently ignores the differences between FEC-128 and 
> FEC-129. If (as the authors have claimed during our off-list 
> discussions) it is equally applicable to both, this should be 
> explicitly stated in the document IMO.
>
> b.RFC 5085:
>
> i.To the best of my understanding, all PW OAM messages run in VCCV, 
> but neither RFC 5085 nor RFC 7708 are referenced in the document. 
> Actually, even the term “VCCV” is not mentioned in the document.
>
> ii.In particular, the draft silently ignores the situation when /the 
> PW endpoints could not agree on any VCCV Type/ so that any attempts to 
> run OAM on the PW would fail – even if the PW endpoints agree about 
> all specific OAM functions and their parameters. From my POV if the PW 
> endpoints could not agree on the VCCV type, all OAM-related parameters 
> should be simply silently ignored
>
> c.RFC 5885 and RFC 6428 and:
>
> i.The draft discusses setup of BFD  as pro-active OAM mechanism for PWs
>
> ii.Neither RFC 5885 (that defines BFD in VCCV) nor RFC 6428 (that 
> defines Pro-Active CC, CV and RDI for MPLS-TP based on BFD)  are 
> mentioned in the draft.
>
> 2._Excessively strict behavior_:
>
> a.The draft defines that any difference in the OAM capabilities of the 
> PW endpoints would result in failure to set it up. One example of this 
> behavior can be found in the following fragment copied from Section 
> 3.1.1 “*Establishment of OAM Entities and Functions*”:
>
> To achieve this, a Label Mapping message with the "OAM Alarms Enabled" 
> flag cleared is sent.  In the message, the "OAM MEP Entities Desired" 
> flag is set...  In addition, to configure and enable particular OAM 
> functions, the PW OAM Functions TLV and relevant sub-TLVs MUST be 
> included.
>
> When the Label Mapping message is received by PE2, PE2 needs to check 
> whether it supports the requested OAM configuration.  If it does not 
> support the requested OAM configuration, a Label Release message MUST 
> be returned to PE1, with a Status Code set to "PW OAM Parameters 
> Rejected".  The PW signaling is complete and the PW will not be 
> established.
>
> b.From my POV the behavior defined in the txt above is too harsh for 
> PWs. I have suggested to the authors to consider a more liberal 
> behavior model when the PW endpoints succeed setting up a PW 
> regardless of whether there is a 100% match between their supported 
> OAM functionality, and just agree on a commonly supported set of OAM 
> functions which could be empty. Such a model, if accepted, would be 
> also consistent with the model for adjustment of OAM parameters as 
> defined in Section 3.1.2 “Adjustment of OAM Parameters”.
>
> 3._Internal inconsistencies_:
>
> a.BFD Identifiers sub-TLV:
>
> i.Mentioned twice as “MUST be included” in Section 4.2.1
>
> ii.Is not defined anywhere in the draft
>
> iii.This looks like a “copy and paste” notion from RFC 7487 – but the 
> definition of the namesake TLV in this document is not applicable as 
> it deals with MPLS-TP LSP identifiers only.
>
> b.Usage of the “OAM Alarms Enabled” flag:
>
> i.The text in at the end of Section 4.1 states that “The"OAM Alarms 
> Enabled" flag is used to request the received PEs to enable (when set) 
> or disable (when cleared) OAM alarms function”.
>
> ii.In almost all the cases considered in the draft, the “OAM Alarms 
> Enabled” flag is used in accordance with the definition quoted above.
>
> iii.However, the text in Section 3.1.2 says that “Consequently, the 
> ingress PE needs to keep its OAM sink and source functions running 
> without any changes until the OAM parameters are updated.  However, in 
> order to suppress spurious alarms, it also need to disable the alarm 
> functions before the Label Mapping message, with the "OAM Alarms 
> Enabled" flag cleared and the updated PW OAM Function TLV, is sent.  
> The OAM alarm function needs to be disabled until the corresponding 
> response message is received”. To me this reads as the Label Mapping 
> message to be sent to the “egress PE” in order to adjust the OAM 
> parameters must have the “OAM Alarms Enabled” flag cleared in order to 
> disable spurious OAM alarms there
>
> iv.Some of the use case of the “OAM Alarms Enabled” flag look 
> unnecessary to me. E.g., when the PW is  being set up, I would expect 
> it to suppress all alarms (OAM alarms included) until the PW setup is 
> complete – and that without the need of any additional synchronization.
>
> 4._Poor alignment with the standard PW setup process_:
>
> a.RFC 4447 defines the SS-PW setup process as symmetric:
>
> i.Each PW endpoint sends its own Label Mapping message for one of the 
> PW FECs to the peer and waits for receiving a matching (with the match 
> condition defined by the FEC-specific rules) from the peer
>
> ii.The PW setup is successfully completed when /both these events are 
> encountered/. Their order does not matter, and consequently there is 
> no such thing as a “response Label Mapping message”
>
> b.However, the draft refers (in 3 different places) to a “response 
> Label Mapping message”:
>
> i.In Section 3.1.2 when it says that “The OAM alarm function needs to 
> be disabled until the corresponding response message is received”
>
> ii.In Section 3.2.2 (the same  text is used)
>
> iii.In Section 4.2.1 when it says that “The BFD Configuration Sub-TLV 
> MUST include the following sub-TLVs in the "response" Label Mapping 
> message”.
>
> c.This looks to me like a probable “copy and paste” error from RFC 
> 7487. But this document uses RSVP-TE with its Path and Resv messages. 
> PW setup is different, of course.
>
> 5._Problematic use of sink/source terminology_:
>
> a.The draft assumes some kind of separation between Sink and Source 
> OAM functions, e.g., when it says in Section 3.1.1 that:
>
> i.The OAM sink functions must be enabled before the Label Mapping 
> message (exposing the required OAM functionality to the remote PW 
> endpoint) are enabled
>
> ii.The OAM source functions must be enabled only after a “response” 
> Label Mapping message has been received
>
> b.In addition, to referring (explicitly or implicitly) to the 
> non-existing “response” OAM Label Mapping message, this logic cannot, 
> from my POV,  be applied to such an OAM function as BFD.
>
> 6._Problematic reference to MIP function_: To the best of my 
> understanding:
>
> a.From my POV S-PEs always support MIP because:
>
> i.In order to reach a MIP the transmitter must set  the TTL in the PW 
> label to a corresponding value
>
> ii.Once the TTL in the PW label expires in some S-PE, the relevant 
> packet is always trapped
>
> b.It is not clear how MIP functionality can be used for pro-active OAM 
> operations
>
> 7._Multiple inconsistencies pertaining to use of BFD_:
>
> a.Timer Negotiation:
>
> i.The draft defines (in section 4.2.1) an N flag that indicates 
> whether negotiation of timer parameters using BFD control packets is 
> or is not supported. If it is not supported, a Timer negotiation 
> parameters sub-TLV must be used
>
> ii.According to Section 3.7.1 of RFC 6428 (which, AFAIK, equally 
> applies to BFD in MPLS-TP Sections, LSPs and PWs), BFD sessions always 
> start with 1 second transmission intervals until they reach their UP 
> state, and then modify the timers to mutually agreed values using 
> Poll/Final. Further, RFC 6428 specifies that the timer parameters may 
> be used at any time, and that non-supporting implementations MUST set 
> the BFD session on which such a change is required to Admin Down in 
> response to an attempt of the remote endpoint of the session to change 
> these parameters.
>
> iii.The bottom line, as I see it, that the draft is not compatible 
> with RFC 6428
>
> b.Authentication:
>
> i.The draft defines an I flag that indicates that BFD authentication 
> is required, and a BFD Authentication sub-TLV for synchronizing the 
> authentication parameters.
>
> ii.I am not a security expert, and do not pretend to be one. But I 
> think that the default authentication mechanism defined in the draft 
> (SHA1 cryptographic authentication using a hard-coded – all zeroes – 
> “pre-shared” secret”) would not pass any serious review by the 
> security experts
>
> iii.I also do not understand why the BFD Authentication sub-TLV as 
> defined in Section 4.2.1.3 carries the Authentication Key ID. As per 
> RFC 5880, this key ID is carried as part of the Authentication Data in 
> the Authentication Section of the all authenticated BFD Control 
> Packets (and can be changed randomly and independently by each 
> endpoint of the session).
>
> c.Local Discriminator sub-TLV:
>
> i.To the best of my understanding, the draft suggests (in Section 
> 4.2.1.1) to exchange the values of the local discriminators between 
> the endpoints of the BFD session
>
> ii.I do not really understand why this is needed, because RFC 5880 
> defines the mechanism for announcing My Discriminator value in the 
> first packet of the session, and RFC 6428 only adds that this value 
> MUST NOT be changed for an already established session.
>
> *Note*: It is possible that these inconsistencies are copy-pasted from 
> RFC 7487, but I did not review this document in detail.
>
> 8._Packet Delay Measurement Issues_: I did not review this part of the 
> draft in detail, but several points look problematic to me:
>
> a.Inferred vs. Direct measurement
>
> i.According to RFC 6374 “inferred packet loss measurement” is the 
> method that measures loss of synthetic probe packets while “direct 
> packet loss measurement” counts actually transmitted and received packets.
>
> ii.As per the same RFC, packet delay measurements are always done 
> based on synthetic probe packets (carrying timestamps)
>
> iii.The draft, however, mentions “inferred/direct packet delay 
> measurement” while, AFAIK, direct delay measurement simply does not exist
>
> b.Delay Variation Measurement:
>
> i.The draft supports signaling of delay variation management function 
> between the PW endpoints(Active/Inactive)
>
> ii.AFAIK, delay variation measurement is a purely local function, and 
> there is no need to synchronize its activation between the two PW 
> endpoints
>
> *Note*: It is possible that these inconsistencies are also copy-pasted 
> from RFC 7487.
>
> **
>
> Hopefully these comments will be useful for the authors and for the WG.
>
> Regards,
>
> Sasha
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email: [e-mail] 
> <mailto:[e-mail]>
>
> *From:*Alexander Vainshtein
> *Sent:* Wednesday, January 06, 2016 3:35 PM
> *To:* 'Stewart Bryant'
> *Cc:* [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* RE: [Pals] WG Last call draft-ietf-pals-tp-oam-config
>
> Stewart,
>
> I will try to read the draft and provide some feedback by January 22nd.
>
> Meanwhile, while looking for the total number of pages in order to 
> understand whether I can handle this, I have found a reference to a 
> "/Dyadic mode of an egress LSR/". I have to admit that I do not know 
> what this means, and a short look-up in the Internet did not return 
> anything useful (unless somebody is going to use 2nd order tensors 
> <https://en.wikipedia.org/wiki/Dyadics> in MPLSJ).
>
> If the authors could explain in advance what they mean, it would 
> simplify the review.
>
> Regards,
>
> Sasha
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email: [e-mail] 
> <mailto:[e-mail]>
>
> -----Original Message-----
> From: Pals [mailto:[e-mail]] On Behalf Of Stewart Bryant
> Sent: Wednesday, January 06, 2016 12:34 PM
> To: [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config
>
> Hi Folks
>
> I guess that everyone has been busy over the holiday period.
>
> I really need some indication on the list that the WG wants to publish 
> this draft, otherwise I cannot take it forward to the IESG.
>
> I also need some volunteers to read the draft and check it over for 
> errors.
>
> So please can  have reviews and confirmation that we should go forward 
> with publication by 22nd January 2016.
>
> Thanks
>
> Stewart
>
> On 23/12/2015 13:00, Stewart Bryant wrote:
>
> >
>
> >
>
> > On 09/12/2015 14:13, Stewart Bryant wrote:
>
> >> This message starts the WG Last Call on draft-ietf-pals-tp-oam-config.
>
> >>
>
> >> This draft can be found at
>
> >>
>
> >> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/
>
> >>
>
> >> Please respond to this thread with substantive comments and an
>
> >> indication of whether you have read the text and whether or not you
>
> >> think it is ready for publication.
>
> >>
>
> >> I will close WGLC on 23rd December.
>
> >>
>
> >> Regards
>
> >>
>
> >> - Stewart
>
> >
>
> > PALS WG
>
> >
>
> > I should close this LC today, but I have no evidence in terms of list
>
> > traffic in response to this LC that I can present to the IESG  that
>
> > anyone has read it or cares whether we  publish it of not.
>
> >
>
> > Has anyone besides the chairs and authors read it?
>
> >
>
> > Should we publish it, and why?
>
> >
>
> > - Stewart
>
> >
>
> _______________________________________________
>
> Pals mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/pals
>