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

[Gregory Mirsky <[e-mail]>]

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:[e-mail]]
Sent: Sunday, August 23, 2015 8:36 AM
To: Gregory Mirsky; 'Ross Callon'; [e-mail]
Cc: [e-mail]; [e-mail]
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