Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 25 August 2015 00:00 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C091A89BB for <mpls@ietfa.amsl.com>; Mon, 24 Aug 2015 17:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnObgF3tVepU for <mpls@ietfa.amsl.com>; Mon, 24 Aug 2015 17:00:22 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0E31A8828 for <mpls@ietf.org>; Mon, 24 Aug 2015 17:00:20 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t7P00H7I003965; Tue, 25 Aug 2015 01:00:17 +0100
Received: from 950129200 (host86-142-14-51.range86-142.btcentralplus.com [86.142.14.51]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t7P00ECO003914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2015 01:00:15 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Gregory Mirsky'" <gregory.mirsky@ericsson.com>, "'Ross Callon'" <rcallon@juniper.net>, <mpls@ietf.org>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB1430CED3726DFB4949F67074A5770@BY1PR0501MB1430.namprd05.prod.outlook.com> <095e01d0d699$da786cd0$8f694670$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF112218A8B04@eusaamb103.ericsson.se> <003301d0ddb9$733c8a20$59b59e60$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF112218AD64F@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF112218AD64F@eusaamb103.ericsson.se>
Date: Tue, 25 Aug 2015 01:00:11 +0100
Message-ID: <01dd01d0dec9$045386c0$0cfa9440$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DE_01D0DED1.661F1AB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugIO0pVoAmv6aBIA/qh/aAIKoyQTAK1VlNmdkaDWgA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21768.003
X-TM-AS-Result: No--26.875-10.0-31-10
X-imss-scan-details: No--26.875-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wlu4M/xm4KZeKOUfwPQyeFe1eX0jEQ9c6pKQ lsyF4c0BmmO/f40DENbYeIrlmS56JkBg+A33cHr9p9ciXoJ/pWvWSrKtwxqWpWBc5muBTx0IhEs PoifR3f1X9/EkrSinjzu6+TpA78AjnCb1wLqfl+0D2WXLXdz+AdB43gDaHridZ5yuplze9ptm2e 55IVZ1oPVcFRiTp0Mn/xZXUXqvPAGbJcqlz0azZ1mW6+4cR52EVX7TxgU0dK74sp4xDuD8bFYWw xB9tw0TLSSHVRNJsIsdDT3plSLzUKQ4hjf3OSHYz5r5y9mouSBG/JUd7BvSQqXJ9vMysD/Czc3F e3ViO46uZ0IQ3OVGYlDdFCcD6ncfDtZgR42ZNmdc/msUC5wFQQksok7nRe3Vr5aAJxq+KobdF+y RKEmWavZxWphNsMu+Ju6v9wN0CtjsqWCLAey1FhHRbGr1ECgHNACnndLvXwe2F4a+vI22PsHvjl W1+MPbFJZOysu842LOfLTwfi9NXL8YrnwsV9qCQpxiLlDD9FVx9T7TIgq5hUw6MpTEJnCvReED7 AuhGA/ZycvdbZ4EWNZKqph79yqWZkv0I0IUU/PzkvkkcY4BcIUGhajERJYJauHKE5Laxl/V4rnp z51XAWV6FC9BN2Hr9r8gyKf+VS4VpaVcO0xUA8+ayFtEW0uYnnKgxNDiH/XUo2nrJEiElRnigGu Vqcg71/ZZwJvBg6nYqgvYAUe0yRhzK7qAlTSL/Sl5cYQQGW+DddlymG7iS1cbfIj2Ta9sgC46py JTSnTV4yn6Kf1r098KgvULLt4X/fqypUX9VmieAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GNgbF0oRDZ0uCkWLfFZIJ7gAtim7FCsqFCBQZLmIdja98miE9fmE2fNfJ8mXW5RKA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/ugAxCisw1Kuhi-4VFVeNyUSi1WA>
Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 00:00:28 -0000

Perfect, Greg.
 
Thanks for all the hard work.
 
Adrian
 
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] 
Sent: 24 August 2015 19:22
To: adrian@olddog.co.uk; 'Ross Callon'; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org;
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: RE: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
 
Hi Adrian,
apologies for missed comments. I've used green to colour my responses with the
same tag GIM>>.
 
        Regards,
                Greg
 
-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Sunday, August 23, 2015 8:36 AM
To: Gregory Mirsky; 'Ross Callon'; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.org;
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: RE: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
 
Hi Greg,
 
I've not checked that you implemented the changes you said you would in your
email. No reason not to trust you.
 
[Major snipping]
 
>> Are there any ordering implications for the sub-TLVs in section 2.2?
> 
> GIM>> No, should be order independent.
 
OK. Maybe...
OLD
   Sub-TLVs corresponding to the different flags are as follows:
NEW
   Sub-TLVs corresponding to the different flags are as follows. No 
   meaning should be attached to the order of sub-TLVs.
END
GIM>> Done.
 
>> 2.2.3
>> 
>> Acceptable Min. Asynchronous intervals: Are the values zero disallowed?
> 
> GIM>> Theoretically it is not disallowed and may be used to have uni-
> directional BFD session. But I agree, it is unlikely to be set to 0.
 
Well, yes, "unlikely".
I suppose there is no reason to prevent setting zero unless you would find
reserved value useful.
GIM>> yes, the RFC 5880 states that the value zero is reserved but does not
elaborate on interpretation of it nor prohibits its use.
 
>> 2.2.4
>> 
>>  If BFD Authentication sub-TLV used for a BFD session in Up state 
>>then
>>  the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
>>  new modes of authentication, i.e. combination of Auth.Type and Auth.
>>  Key ID, used to send and receive BFD control packets until the 
>>Sender
>>  can confirm that its peer had switched to the new authentication.
>> 
>> Under what circumstances would an implementation vary this SHOULD and 
>> what would be the effect?
> 
> GIM>> For example,  AdminDown MAY be used to perform transition from
> old to new mode of authentication and verify that new is operational.
 
Silly me. I should have said, "Please explain in the document..." :-)
 
You really need to add and complete the following sentence...
 
An implementation MAY change the mode of authentication mode sooner if...
GIM>> Would the following do:
"An implementation MAY change mode of authentication if an operator re-evaluates
security situation in and around the administrative domain."
 
>> 2.2.5
>> 
>>  If TC sub-TLV is present, then the value of the TC field MUST be 
>>used
>>  as the value of the TC field of an MPLS label stack entry.
>> 
>> Maybe I am missing something, but I couldn't work out which LSE on 
>> which packet you are referring to. And it isn't even clear whether 
>> you mean to copy the value from the packet to this field, or from 
>> this field to the packet.
>> 
>> Ditto the end of 2.2.9 which is a bit clearer but still not clear as 
>> to which LSE is being talked about.
> 
> GIM>> We're trying to control TC for E-LSP so that state of the single 
> GIM>> BFD
> session be used to infer state of all CoS. Would the following 
> improves the
> clarity:
> 
>   If TC sub-TLV is present, then value of the TC field MUST be used
>   as the value of the TC field of the MPLS label stack that corresponds
>   to the FEC for which fault detection is being performed.
 
Nearly there...
 
If the TC sub-TLV is present, then the sender of any data packets on the LSP
with a FEC that corresponds to the FEC for which fault detection is being
performed MUST use the value contained in the TC field of the sub-TLV as the
value of the TC field in the top label stack entry of the MPLS label stack.
GIM>> Adrian, the proposed text, as I interpret it, requires that TC value been
applied to all data packets, not only OAM. How about the following wording:
"If the TC sub-TLV is present, then the sender of any periodic continuity
monitoring messages or packets with fault management  information on the LSP
with a FEC that corresponds to the FEC for which fault detection is being
performed MUST use the value contained in the TC field of the sub-TLV as the
value of the TC field in the top label stack entry of the MPLS label stack."
 
 
>> 2.2.9
>> 
>>   When both working and protection
>>   paths are configured, both LSPs SHOULD be configured with identical
>>   settings of the E flag, T flag, and the refresh timer.
>> 
>> This implies there are reasons (and mechanisms) to vary the 
>> configuration. You should explain them.
 
Missing an answer?
Change SHOULD to MUST or add: "An implementation MAY configure the working and
protection LSPs with different settings of these fields if..."
GIM>> I've missed it. "An implementation MAY configure the working and
protection LSPs with different settings of these fields in case of 1:N
protection."
 
>> Section 6
>> 
>> Additionally, shouldn't you talk about the configuration of security 
>> mechanisms that exist for the OAM tools you are configuring?
> 
> GIM>> Would references to respective sections in RFC 5880, 5884,
> 6374, 6375, 6427 and 6428 be sufficient?
 
The para with these simple references that you've added is OK, but I think you
are missing discussion of how these security aspects are configured. If we are
dealing with the configuration of OAM then we should deal with the configuration
of OAM security.
 
However, you may be wanting to say...
 
In order that the configuration of OAM function can be achieved securely through
the techniques described in this document, security mechanisms must already be
in place and operational for LSP Ping. Thus the exchange of security parameters
(such as keys) for use in securing OAM is outside the scope of this document and
is assumed to use an off-line mechanism or an established secure key-exchange
protocol.
 
You have a spelling mistake: "extenssions"
GIM>> Thank you, Adrian. Done.
Ciao,
Adrian