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

["Adrian Farrel" <[e-mail]>]

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

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

You have a spelling mistake: "extenssions"

Ciao,
Adrian