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?

Regards,
Greg

On Tue, Jan 31, 2017 at 10:22 AM, Uma Chunduri <[email protected]>
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:[email protected]] *On Behalf Of *Les Ginsberg
> (ginsberg)
> *Sent:* Tuesday, January 31, 2017 8:22 AM
> *To:* Greg Mirsky <[email protected]>
> *Cc:* [email protected]; [email protected]; Isis-wg <
> [email protected]>; [email protected];
> TEAS WG Chairs <[email protected]>; [email protected]; TEAS WG <
> [email protected]>; [email protected]; [email protected]
> *Subject:* Re: [mpls] [OSPF] Working group last call on
> draft-ietf-mpls-residence-time
>
>
>
> Greg –
>
>
>
> Looks good.
>
>
>
>    Les
>
>
>
> *From:* Greg Mirsky [mailto:[email protected] <[email protected]>]
>
> *Sent:* Tuesday, January 31, 2017 8:06 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; [email protected]; TEAS WG; [email protected]; Isis-wg;
> [email protected]; [email protected]; TEAS
> WG Chairs; [email protected]; [email protected]
> *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) <
> [email protected]> 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:[email protected]]
> *Sent:* Monday, January 30, 2017 11:43 PM
>
>
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; [email protected]; TEAS WG; [email protected]; Isis-wg;
> [email protected]; [email protected]; TEAS
> WG Chairs; [email protected]; [email protected]
> *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) <
> [email protected]> 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:[email protected]]
> *Sent:* Monday, January 30, 2017 10:36 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; [email protected]; TEAS WG; [email protected]; Isis-wg;
> [email protected]; [email protected]; TEAS
> WG Chairs; [email protected]; [email protected]
> *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) <
> [email protected]> 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:[email protected]] On Behalf Of Loa Andersson
>
> > Sent: Monday, January 30, 2017 8:02 AM
>
> > To: [email protected]; TEAS WG; [email protected]; Isis-wg
>
> > Cc: [email protected]; [email protected];
> TEAS
>
> > WG Chairs; [email protected]; [email protected]
>
> > 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 ([email protected]),
> 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: [email protected]
>
> > Senior MPLS Expert                          [email protected]
>
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
> >
>
> > _______________________________________________
>
> > OSPF mailing list
>
> > [email protected]
>
> > https://www.ietf.org/mailman/listinfo/ospf
>
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>
>
>
>
>
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to