Re: [mpls] [OSPF] Working group last call on draft-ietf-mpls-residence-time

["Acee Lindem (acee)" <[e-mail]>]

Hi Greg, 

On 1/31/17, 12:51 PM, "Greg Mirsky" <[e-mail]> wrote:

>Hi Uma,
>great catch and astute observation, thank you!
>I think that making RTM Capabilities space in IS-IS extendable beyond
>remaining 13 bit-long space is prudent. But now, as you've pointed out,
>need to reconcile formats. I'd prefer to take option 1, i.e. use variable
>length Value field in RTM Capabilities sub-TLV for OSPFv2. Acee, would
>that
>be acceptable?

Sure - although I agree that a variable length bit field seems like
overkill. But by all means, let¹s keep one encoding across all the
protocols. 

Thanks,
Acee

>
>Regards,
>Greg
>
>On Tue, Jan 31, 2017 at 10:22 AM, Uma Chunduri <[e-mail]>
>wrote:
>
>> Had a quick look at this diff.
>>
>>
>>
>> This is about unifying the encoding parts in IGP to have a consistent
>>view
>> for BGP-LS encoding or keeping these separate and yet having a correct
>> representation in BGP-LS for both IGPs.
>>
>>
>>
>> ==
>>
>> With variable length bit field for Section 4.5 and fixed 4 byte value
>>(as
>> indicated as MUST  for length) in section 4.3  - I saw a discrepancy  in
>> section 4.6 (BGP-LS) which is referencing section 4.3.
>>
>>
>>
>> You have multiple options to fix this:
>>
>>
>>
>> 1.       Change section 4.3 to match section 4.5 (I am not sure why we
>> have to have variable length for this bit field to start with in this
>>case
>> like rfc 7794Šbut I won¹t say much now)
>>
>> 2.       Change Section 4.6 to represent differences in encoding section
>> 4.5 and 4.3 correctly.
>>
>> ³Length, RTM, and Reserved fields as defined in Section 4.3.²
>>
>>    3. Lastly unify section 4.5 to 4.3  i.e., 4 byte value with 3 bits
>> defined and 29 bits reserved.
>>
>> --
>>
>> Uma C.
>>
>>
>>
>> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Les Ginsberg
>> (ginsberg)
>> *Sent:* Tuesday, January 31, 2017 8:22 AM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* [e-mail]; [e-mail]; Isis-wg <
>> [e-mail]>;
>>[e-mail];
>> TEAS WG Chairs <[e-mail]>; [e-mail]; TEAS WG <
>> [e-mail]>; [e-mail]; [e-mail]
>> *Subject:* Re: [mpls] [OSPF] Working group last call on
>> draft-ietf-mpls-residence-time
>>
>>
>>
>> Greg ­
>>
>>
>>
>> Looks good.
>>
>>
>>
>>    Les
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[e-mail]
>><[e-mail]>]
>>
>> *Sent:* Tuesday, January 31, 2017 8:06 AM
>> *To:* Les Ginsberg (ginsberg)
>> *Cc:* Loa Andersson; [e-mail]; TEAS WG; [e-mail]; Isis-wg;
>> [e-mail]; [e-mail];
>>TEAS
>> WG Chairs; [e-mail]; [e-mail]
>> *Subject:* Re: [OSPF] Working group last call on
>> draft-ietf-mpls-residence-time
>>
>>
>>
>> Hi Les,
>>
>> thank you for your patience and apologies for missing it.
>>
>> Diff and the update been attached.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Tue, Jan 31, 2017 at 5:07 AM, Les Ginsberg (ginsberg) <
>> [e-mail]> wrote:
>>
>> Greg ­
>>
>>
>>
>> AlmostŠ
>>
>>
>>
>> Please change the title of Section 7.5 to ³IS-IS RTM Capability
>>sub-TLV².
>>
>>
>>
>> Please change the title of Table 5 to ³IS-IS RTM Capability sub-TLV
>> Registry Description².
>>
>>
>>
>> The common point being since this is not exclusively for TLV 22 we do
>>not
>> want to say ³for TLV 22².
>>
>> Thanx.
>>
>>
>>
>>     Les
>>
>>
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Monday, January 30, 2017 11:43 PM
>>
>>
>> *To:* Les Ginsberg (ginsberg)
>> *Cc:* Loa Andersson; [e-mail]; TEAS WG; [e-mail]; Isis-wg;
>> [e-mail]; [e-mail];
>>TEAS
>> WG Chairs; [e-mail]; [e-mail]
>> *Subject:* Re: [OSPF] Working group last call on
>> draft-ietf-mpls-residence-time
>>
>>
>>
>> Hi Les,
>>
>> many thanks for your the most detailed suggestions. Hope I've it right.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Mon, Jan 30, 2017 at 11:04 PM, Les Ginsberg (ginsberg) <
>> [e-mail]> wrote:
>>
>> Greg ­
>>
>>
>>
>> Thanx for the quick turnaround.
>>
>>
>>
>> Section 4.5 (revised text)
>>
>>
>>
>>    The capability to support RTM on a particular link (interface) is
>>
>>    advertised in a new sub-TLV which may be included in TLVs advertising
>>
>>    Intemediate System (IS) Reachability on a specific link (TLVs 22, 23,
>> 222, and 223).
>>
>>
>>
>>    The format for the RTM Capabilities sub-TLV is presented in Figure 5
>>
>>
>>
>>      0                   1                   2
>>
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
>>
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>>
>>     |      Type     |     Length    | RTM |              ...
>>
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>>
>>
>>
>>    Figure 5: RTM Capability sub-TLV
>>
>>
>>
>> Š (Remainder unchanged)
>>
>>
>>
>> Section 7.5 (revised text)
>>
>>
>>
>> 7.5.  IS-IS RTM Capability sub-TLV
>>
>>
>>
>>    IANA is requested to assign a new Type for RTM capability sub-TLV
>>
>>    from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
>>
>>    follows:
>>
>>
>>
>>     +------+-------------+----+----+-----+-----+-----+---------------+
>>
>>     | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference     |
>>
>>     +------+-------------+----+----+-----+-----+-----+---------------+
>>
>>     | TBA3 |     RTM      | y  | y  | n   | y   | y   | This document |
>>
>>     |           | Capability |      |     |      |       |
>> |                                |
>>
>>     +------+-------------+----+----+-----+-----+-----+---------------+
>>
>>
>>
>>              Table 5: IS-IS RTM Capability sub-TLV Registry Description
>>
>>
>>
>>
>>
>> Thanx.
>>
>>
>>
>>     Les
>>
>>
>>
>> *From:* Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Monday, January 30, 2017 10:36 PM
>> *To:* Les Ginsberg (ginsberg)
>> *Cc:* Loa Andersson; [e-mail]; TEAS WG; [e-mail]; Isis-wg;
>> [e-mail]; [e-mail];
>>TEAS
>> WG Chairs; [e-mail]; [e-mail]
>> *Subject:* Re: [OSPF] Working group last call on
>> draft-ietf-mpls-residence-time
>>
>>
>>
>> Hi Les,
>>
>> attached are diff and the updated version -14. Would be much obliged to
>> hear from you if the updates are according to your suggestions and
>>address
>> your comments.
>>
>>
>>
>> Kind regards,
>>
>> Greg
>>
>>
>>
>>
>>
>> On Mon, Jan 30, 2017 at 1:11 PM, Les Ginsberg (ginsberg) <
>> [e-mail]> wrote:
>>
>> Loa -
>>
>>
>>
>> The change for IS-IS encoding to utilize a sub-TLV of TLV 22 et al to
>> advertise RTM capability is a better solution than the previous proposal
>> and this has my support.
>>
>> However, there are some details as regards the proposed sub-TLV that
>> should be revised.
>>
>>
>>
>> 1)Rather than use a fixed 16 bit field for the flags I suggest you
>>utilize
>> the encoding style introduced in RFC 7794 (see Section 2.1) which allows
>> for a variable length flags field. This addresses two issues:
>>
>>
>>
>>    o You need never worry that the size of the flags field will be too
>> small for future extensions
>>
>>    o It minimizes the number of bytes required to be sent
>>
>>
>>
>> The latter point is something IS-IS has always been more conservative
>> about than OSPF because of the fixed size of an LSP set which can be
>> advertised by a single router.
>>
>>
>>
>> 2)In the IANA considerations you have limited the sub-TLV to being used
>>in
>> TLV 22 only, but there is no reason to do so. This does not allow MT to
>>be
>> supported and it needlessly prevents use of the sub-TLV by the RFC 5311
>> extensions (however unpopular those may be). I can understand why the
>> sub-TLV may not be useful in TLV 141, therefore I suggest the table in
>> Section 7.5 be revised to be:
>>
>>
>>
>>
>>
>>     | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference
>> |
>>
>>    +------+-------------+----+----+-----+-----+-----+---------------+
>>
>>   | TBA3 |    RTM       | y  | y  | n   | y   | y   | This document
>> |
>>
>>     +------+-------------+----+----+-----+-----+-----+---------------+
>>
>>
>>
>>
>> i.e. "y" for all but TLV 141 (in case the ASCII art doesn't translate
>>well
>> in your mailer).
>>
>>
>>
>> You should also remove the reference to RFC 5305 in Section 4.5 as it is
>> too limiting. Simply referencing the IANA registry http://www.iana.org/
>> assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-
>> codepoints-22-23-141-222-223 should be sufficient. All necessary
>> references can be found there.
>>
>>
>>
>> 3)An editorial correction:
>>
>>
>>
>> Introduction 3rd paragraph:
>>
>>
>>
>> s/ Althugh/ Although
>>
>>
>>
>>    Les
>>
>>
>>
>> > -----Original Message-----
>>
>> > From: OSPF [mailto:[e-mail]] On Behalf Of Loa Andersson
>>
>> > Sent: Monday, January 30, 2017 8:02 AM
>>
>> > To: [e-mail]; TEAS WG; [e-mail]; Isis-wg
>>
>> > Cc: [e-mail];
>>[e-mail];
>> TEAS
>>
>> > WG Chairs; [e-mail]; [e-mail]
>>
>> > Subject: [OSPF] Working group last call on
>>draft-ietf-mpls-residence-time
>>
>> >
>>
>> > Working Groups,
>>
>> >
>>
>> > This is to initiate a two week working group last call in four working
>> groups on
>>
>> > draft-ietf-mpls-residence-time-13.
>>
>> >
>>
>> > The MPLS working group has done an earlier working group last call
>>and a
>>
>> > request for publication has been made.
>>
>> >
>>
>> > The changes to the document were such that we decided to do a new
>>
>> > working group last call and extend it to MPLS, TEAS, OSPF and IS-IS.
>>
>> >
>>
>> > There are three major changes between the version of the document for
>>
>> > which publication was requested are:
>>
>> >
>>
>> > (1) that section 7 " One-step Clock and Two-step Clock Modes" has been
>>
>> >      moved up to become section 2.1.
>>
>> > (2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM
>>
>> >      Capability when IS-IS used advertise RTM capabilities
>>
>> > (3) BGP-LS has been added as a RTM capability advertisement method
>>
>> >
>>
>> > A side-by-side diff between version -12 and -13 is available at:
>>
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-13
>>
>> >
>>
>> > Please send your comments to the mpls wg mailing list ([e-mail]),
>> if
>>
>> > you are not subscribed to the mpls wg list, send to "your own"
>>
>> > working group mailing list, and we'll make sure they are posted to the
>> MPLS
>>
>> > wg list.
>>
>> >
>>
>> > There were one IPR disclosure against this document.
>>
>> >
>>
>> > All the authors and contributors have stated on the working group
>> mailing list
>>
>> > that they are not aware of any other IPRs that relates to this
>>document