Return-Path: 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 60FF81A8F4E for ; Mon, 24 Aug 2015 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 BKI-3wj-VDwl for ; Mon, 24 Aug 2015 11:22:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481321A008A for ; Mon, 24 Aug 2015 11:22:17 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-63-55db0339a46d Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 10.3D.32596.A330BD55; Mon, 24 Aug 2015 13:42:50 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 24 Aug 2015 14:22:15 -0400 From: Gregory Mirsky To: "adrian@olddog.co.uk" , 'Ross Callon' , "mpls@ietf.org" Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10 Thread-Index: AQHQzgNUa/dgnD786kKbZmnl5u/dLp4L2qqAgATTkqCACWuwgIABZJZg Date: Mon, 24 Aug 2015 18:22:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112218AD64F@eusaamb103.ericsson.se> References: <095e01d0d699$da786cd0$8f694670$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF112218A8B04@eusaamb103.ericsson.se> <003301d0ddb9$733c8a20$59b59e60$@olddog.co.uk> In-Reply-To: <003301d0ddb9$733c8a20$59b59e60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF112218AD64Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPlK4V8+1Qg9dnRCx+9Nxgtphw6gGT xfdLS1gsbi1dyWrxd8UVFgdWjyVLfjJ5XG+6yu6xYvNKRo8vlz+zBbBEcdmkpOZklqUW6dsl cGV8ODSFueBmdcWhnhVsDYwn07oYOTkkBEwkjjV8YYKwxSQu3FvP1sXIxSEkcJRR4vKOJ1DO ckaJ7sO32ECq2ASMJF5s7GEHsUUEyiVebF7HDFLELLCDUeL24dmsIAlhgTiJ+2c7GCGK4iXm f1kN1eAmsXz6QrB1LAKqEjdedgHVcHDwCvhK3NscBbHsLpPEtt9NYPWcAtYSU9qngNUzAp33 /dQaMJtZQFzi1pP5UGcLSCzZc54ZwhaVePn4HyuErSQxaek5Voj6fIlzfS1gNbwCghInZz5h mcAoOgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYx AmPxmASb7g7GPS8tDzEKcDAq8fAqcN0KFWJNLCuuzD3EKM3BoiTO6xiVFyokkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBcSPnjqvHy3e0l3YIhvh5JH58fZ9t0aVj9176cNr+0dT1+h9ZaCAu yVHwan3SVXnRqMNG7Eq7aw/t3V1R4iF99od7k40r5/0bdovMz8XN2jM5qDRZJT+NuXX1h5bA ex1SjEJnmhwvzmloEn7ENXVqzwQRdqHzjPJZir2PTqb41ry122Gv3fVAiaU4I9FQi7moOBEA sqnW6qYCAAA= Archived-At: 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 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 18:22:22 -0000 --_000_7347100B5761DC41A166AC17F22DF112218AD64Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@t= ools.ietf.org Subject: RE: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf-10 Hi Greg, I've not checked that you implemented the changes you said you would in you= r 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-eval= uates 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 LS= P 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 t= he value of the TC field in the top label stack entry of the MPLS label sta= ck. 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 wor= ding: "If the TC sub-TLV is present, then the sender of any periodic continuity m= onitoring 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 th= e value of the TC field in the top label stack entry of the MPLS label stac= k." >> 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 prot= ection LSPs with different settings of these fields in case of 1:N protecti= on." >> 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 th= rough the techniques described in this document, security mechanisms must a= lready be in place and operational for LSP Ping. Thus the exchange of secur= ity 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 establis= hed secure key-exchange protocol. You have a spelling mistake: "extenssions" GIM>> Thank you, Adrian. Done. Ciao, Adrian --_000_7347100B5761DC41A166AC17F22DF112218AD64Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
apologies for missed comments. I've used green to colour my responses = with the same tag GIM>>.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Adrian Farrel [mailto:adrian@o= lddog.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@t= ools.ietf.org
Subject: RE: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mp= ls-tp-oam-conf-10
 
Hi Greg,
 
I've not checked that you implemented the changes you said you would i= n your email. No reason not to trust you.
 
[Major snipping]
 
>> Are there any ordering implications for the sub-TLVs in secti= on 2.2?
>
> GIM>> No, should be order independent.
 
OK. Maybe...
OLD
   Sub-TLVs corresponding to the different flags are as foll= ows:
NEW
   Sub-TLVs corresponding to the different flags are as foll= ows. 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 d= isallowed?
>
> 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 p= rohibits 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 t= hat old and
>>  new modes of authentication, i.e. combination of Auth.T= ype and Auth.
>>  Key ID, used to send and receive BFD control packets un= til the
>>Sender
>>  can confirm that its peer had switched to the new authe= ntication.
>>
>> Under what circumstances would an implementation vary this SH= OULD and
>> what would be the effect?
>
> GIM>> For example,  AdminDown MAY be used to perform t= ransition from
> old to new mode of authentication and verify that new is operatio= nal.
 
Silly me. I should have said, "Please explain in the document...&= quot; :-)
 
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 au= thentication if an operator re-evaluates security situation in and around t= he administrative domain.”
 
>> 2.2.5
>>
>>  If TC sub-TLV is present, then the value of the TC fiel= d MUST be
>>used
>>  as the value of the TC field of an MPLS label stack ent= ry.
>>
>> Maybe I am missing something, but I couldn't work out which L= SE on
>> which packet you are referring to. And it isn't even clear wh= ether
>> 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 c= lear as
>> to which LSE is being talked about.
>
> GIM>> We’re trying to control TC for E-LSP so that st= ate 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 perform= ed.
 
Nearly there...
 
If the TC sub-TLV is present, then the sender of any data packets on t= he 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 in= terpret it, requires that TC value been applied to all data packets, not on= ly 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.”<= /font>
 
 
>> 2.2.9
>>
>>   When both working and protection
>>   paths are configured, both LSPs SHOULD be configu= red with identical
>>   settings of the E flag, T flag, and the refresh t= imer.
>>
>> This implies there are reasons (and mechanisms) to vary the <= /div>
>> configuration. You should explain them.
 
Missing an answer?
Change SHOULD to MUST or add: "An implementation MAY configure th= e working and protection LSPs with different settings of these fields if...= "
GIM>> I’ve missed it. “An im= plementation MAY configure the working and protection LSPs with different s= ettings of these fields in case of 1:N protection.”
 
>> Section 6
>>
>> Additionally, shouldn't you talk about the configuration of s= ecurity
>> mechanisms that exist for the OAM tools you are configuring?<= /div>
>
> 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 t= hink you are missing discussion of how these security aspects are configure= d. 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 secure= ly through the techniques described in this document, security mechanisms m= ust 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 assume= d to use an off-line mechanism or an established secure key-exchange protoc= ol.
 
You have a spelling mistake: "extenssions"
GIM>> Thank you, Adrian. Done.
Ciao,
Adrian
 
 
 --_000_7347100B5761DC41A166AC17F22DF112218AD64Feusaamb103erics_--