Ron - Interesting proposal.
A few mundane - but I think still important - comments. New IS-IS TLVs -------------------- There is no need to have two TLVs for each address-family - one for MTID #0 and one for all non-zero MTIDs. One TLV/AF will suffice. The reason we have separate TLVs today is because MT (RFC 5120) came along after TLV 135/236 had been defined/deployed. Since you have a greenfield here you can simply have one TLV/AF and allow all MTIDs (including 0). MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value. (I believe someone else pointed this out as well.) See RFC 5120. You should specify that the new TLVs inherit the sub-TLV space defined in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237 The U-bit ------------- I appreciate that there is precedence for calling this the U-bit based on RFC 5308 - but I would prefer that you call it the D-bit. Regardless of name, it MUST be consistent with existing usage - meaning it is set when the prefix is leaked downwards. Currently your text says: "U (1 bit): Set indicates up. Clear indicates down." This needs to be reversed. Constraints --------------- I think you need to speak to various constraints including (but not limited to): 1)Algorithm is limited to flex-algo values (128-255) I don't understand why Section 6 (main part - not the sub-sections) is there. What relevance do non-flex-algos have to this draft?? I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm Sub-TLV". Unless you are proposing to use this sub-TLV in ways not related to flex-algo - in which case I think you need to provide some explanation of the use case for this. 2)How to handle advertisement of same algo both in the new Algorithm sub-TLV and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy routers may understand SR Algorithm Sub-TLV but not the new one. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 6:38 AM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo- > 00.txt > > > Please review and comment > > Ron > > > > Juniper Business Use Only > > > -----Original Message----- > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya <pkane...@juniper.net>; Shraddha Hegde > > <shrad...@juniper.net>; Ron Bonica <rbon...@juniper.net>; Rajesh M > > <mraj...@juniper.net>; William Britto A J <bwill...@juniper.net> > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > > An IGP Flexible Algorithm computes a constraint-based path and maps > > that path to an identifier. As currently defined, Flexalgo can only > > map the paths that it computes to Segment Routing (SR) identifiers. > > Therefore, Flexalgo cannot be deployed in the absence of SR. > > > > This document extends Flexalgo, so that it can map the paths that it > > computes to IP addresses. This allows Flexalgo to be deployed in any > > IP network, even in the absence of SR. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
