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>
In-Reply-To: <7347100B5761DC41A166AC17F22DF112218A8B04@eusaamb103.ericsson.se>
Date: Sun, 23 Aug 2015 16:36:15 +0100
Message-ID: <003301d0ddb9$733c8a20$59b59e60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugIO0pVoAmv6aBIA/qh/aJ2lOYIQ
Content-Language: en-gb
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/OTxwWd0otw0gn5wykD6PoaxygGc>
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
Precedence: list
Reply-To: adrian@olddog.co.uk

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=20
   meaning should be attached to the order of sub-TLVs.
END

>> 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
>>
>>=A0 If BFD Authentication sub-TLV used for a BFD session in Up state =
then
>>=A0 the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
>>=A0 new modes of authentication, i.e. combination of Auth.Type and =
Auth.
>>=A0 Key ID, used to send and receive BFD control packets until the =
Sender
>>=A0 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, =A0AdminDown 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
>>=A0 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=92re 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
>>
>>=A0=A0 When both working and protection
>>=A0=A0 paths are configured, both LSPs SHOULD be configured with =
identical
>>=A0=A0 settings of the E flag, T flag, and the refresh timer.
>>
>> This implies there are reasons (and mechanisms) to vary the=20
>> 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
protocol.

You have a spelling mistake: "extenssions"

Ciao,
Adrian