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

[Jeff Tantsura <[e-mail]>]

Greg,

 

Looks good!

 

Cheers,

Jeff

 

 

From: mpls <[e-mail]> on behalf of Greg Mirsky <[e-mail]>
Date: Tuesday, January 31, 2017 at 19:18
To: Uma Chunduri <[e-mail]>
Cc: "Les Ginsberg (ginsberg)" <[e-mail]>, "[e-mail]" <[e-mail]>, Isis-wg <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, TEAS WG Chairs <[e-mail]>, "[e-mail]" <[e-mail]>, TEAS WG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mpls] [OSPF] Working group last call on draft-ietf-mpls-residence-time

 

Hi Uma, Acee, Les, et. al,

attached please find diff and the updated version. I think I've got it right by now.

Greatly appreciate your comments.

 

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

> 

> This working group last call ends February 13, 2017.

> 

> 

> /Loa

> MPLS wg co-chairs

> --

> 

> 

> Loa Andersson                        email: [e-mail]

> Senior MPLS Expert                          [e-mail]

> Huawei Technologies (consultant)     phone: [phone]

> 

> _______________________________________________

> OSPF mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf

 

 

 

 

_______________________________________________ mpls mailing list [e-mail] https://www.ietf.org/mailman/listinfo/mpls