Yakov,

 Thanks for the follow up.
 See below, pls.

>> It might be a good idea to explicitly mention that only
>> intra-area issues are covered here.

> That is not exactly correct, as the extensions defined in this
> document could certainly be used for establishing LSPs that span
> multiple area. An example of how this could be accomplished can
> be found in Section 4.1 of draft-kompella-mpls-multiarea-te-02.txt.

OK, I see what you mean. What I meant is that the document
does not described any sort of aggregation and distribution
of introduced parameters between areas.

>> [OSPF-TE] says:
>>
>> The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
>> exactly once. All other sub-TLVs defined here may occur at most
>> once. These restrictions need not apply to future sub-TLVs.
>> Unrecognized sub-TLVs are ignored.
>>
>> Considering the last two sentences, it would be really nice if
>> this document said something about this.
>>
>> You might also say something about processing of sub-TLVs
>> with unexpected length.

> Could you please suggest the text.

If I may, I would leave the exact wording to the authors, please.
I would, however, be willing to review proposed text.

>> > 5.1. Link Local Identifier
>> >
>> > A Link Local Identifier is a sub-TLV of the Link TLV with type 11,
>> > and length 4.
>>
>> What do I put in it?

> Link Local Identifier. For more information consult Section 6.1
> of draft-ietf-ccamp-gmpls-routing-03.txt.

Please specify in the draft (though the names happen to be the same).

>> > 5.2. Link Remote Identifier
>> >
>> > A Link Remote Identifier is a sub-TLV of the Link TLV with type 12,
>> > and length 4.
>> >
>>
>> Ditto

> Link Remote Identifier. For more information consult Section 6.1
> of draft-ietf-ccamp-gmpls-routing-03.txt.

Ditto

>> > 5.3. Link Protection Type
>> >
>> > The Link Protection Type is a sub-TLV of the Link TLV, with type 14,
>> > and length of four octets, the first of which is a bit vector
>> > describing the protection capabilities of the link. They are:
>>
>> Something should also be said about other octets.

> Ditto.

>> Are they reserved and ignored on receipt?

> Should be set to zero by the sender and should be ignored on receipt.

Please specify as well.

Thanks a lot!

Alex

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]