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

[Alexander Vainshtein <[e-mail]>]

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]



From: Alexander Vainshtein
Sent: Wednesday, January 06, 2016 3:35 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,

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



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