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

[Greg Mirsky <[e-mail]>]

Hi Uma,
below is the update to address your suggestion:
OLD TEXT

   o  Length value equals number of octets of the Value field.

   o  Value contains variable number of bit-map fields so that overall
      number of bits in the fields equals Length * 8.

   o  Bits are defined/sent starting with Bit 0.  Additional bit-map
      field definitions that may be defined in the future SHOULD be
      assigned in ascending bit order so as to minimize the number of
      bits that will need to be transmitted.

   o  Undefined bits MUST be transmitted as 0 and MUST be ignored on
      receipt.

   o  Bits that are NOT transmitted MUST be treated as if they are set
      to 0 on receipt.

NEW TEXT

   o  Definitions, rules of handling, and values for fields Length and
      Value are as defined in Section 4.3

-----

I think that text regarding RTM Capability field can stay even though,
effectively, it duplicates the definition of the field and points to
4.3.

What do you think?


Regards,

Greg


On Wed, Feb 1, 2017 at 9:34 AM, Uma Chunduri <[e-mail]>
wrote:

> Dear Greg,
>
>
>
> Your changes look good to me.
>
>
>
> Nit:  Now, you would have noticed the text duplicated (couple of bullet
> points), which could have been avoided by just reference.
>
>
>
> Best Regards,
>
> --
>
> Uma C.
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Tuesday, January 31, 2017 7:19 PM
> *To:* Uma Chunduri <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; [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
>
>
>
> 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] <[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
>
>
>
>
>
>
>
>
>