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

"Adrian Farrel" <> Sun, 23 August 2015 15:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2D311ACEB4 for <>; Sun, 23 Aug 2015 08:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.9
X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DP3dwkhOyzrP for <>; Sun, 23 Aug 2015 08:36:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BABA1ACEB3 for <>; Sun, 23 Aug 2015 08:36:21 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t7NFaHfq028683; Sun, 23 Aug 2015 16:36:17 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t7NFaGWF028667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 23 Aug 2015 16:36:16 +0100
From: "Adrian Farrel" <>
To: "'Gregory Mirsky'" <>, "'Ross Callon'" <>, <>
References: <> <> <095e01d0d699$da786cd0$8f694670$> <>
In-Reply-To: <>
Date: Sun, 23 Aug 2015 16:36:15 +0100
Message-ID: <003301d0ddb9$733c8a20$59b59e60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugIO0pVoAmv6aBIA/qh/aJ2lOYIQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--18.048-10.0-31-10
X-imss-scan-details: No--18.048-10.0-31-10
X-TMASE-MatchedRID: Kx0w2sAofbto+8iifPYj/qfXIl6Cf6Vr1kqyrcMalqVgXOZrgU8dCIRL D6In0d39V/fxJK0op487uvk6QO/AI5wm9cC6n5ftA9lly13c/gHQeN4A2h64nWecrqZc3vabTBx hJ5k86mNlZM7oQslCV3RQ9NdKlibnf5rYlyxv4qvCz1ymGcrCUSzjhVPXPQf4MM2Zth6TUhHbpn y160FQwF1LlkOuDhCDxhDogSzbdpDxGlsLvo3Lje5xcghYf69zWjWsWQUWzVofEmsQEltHx0n0v jeeb/bZ3FAeMcQT06LdXe2hdwlQb0tpsv6KDmpvbMGKOuLn5FWS14R5VqLtN+OxOq7LQlGLyyVo fv+j6w98fn8MklL3RvtARcFzeoO5W2gveZu2y4RCnGIuUMP0VXH1PtMiCrmFTDoylMQmcK9F4QP sC6EYD9nJy91tngRY1kqqmHv3KpaelO46D9bZjvOS+SRxjgFwhQaFqMRElglq4coTktrGX9Xiue nPnVcBZXoUL0E3Yev2vyDIp/5VLhWlpVw7TFQDz5rIW0RbS5iecqDE0OIf9dSjaeskSISVGeKAa 5WpyDvCdvOYYvgys6BVvEjzNBpCaDAi8sBNMoFWdFebWIc3VsRB0bsfrpPI6T/LTDsmJmg=
Archived-At: <>
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Aug 2015 15:36:25 -0000

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...
   Sub-TLVs corresponding to the different flags are as follows:
   Sub-TLVs corresponding to the different flags are as follows. No 
   meaning should be attached to the order of sub-TLVs.

>> 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.

>> 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...

>> 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 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.

>> 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..."

>> 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

You have a spelling mistake: "extenssions"