Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

"Acee Lindem (acee)" <> Sat, 03 October 2015 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 074A31B2B29; Sat, 3 Oct 2015 09:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vSVbTwVL7mLX; Sat, 3 Oct 2015 09:06:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92D2E1B2B24; Sat, 3 Oct 2015 09:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20232; q=dns/txt; s=iport; t=1443888360; x=1445097960; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mWeiVP6RG7d0DuhUIzkqaEbXm4kgku0vQEXxd+53WoY=; b=QRrt5OfAQdxoJK3fqPIAaumIGELQESS2mHTTqwjFHpdVe6v/Y9ctTu8T S8GSF8NHLlMo4kZIIjb4KKArkhvIsQxQC7DcUes+MN/q3NW6p6SROY8YF tmQiwcYkIpKbDKa8W9SS2LWRdFK3fSRzDZ2pSWNEzfCyUp24jQBSCvAHO I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,628,1437436800"; d="scan'208";a="194300792"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2015 16:05:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t93G5x2n017714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 3 Oct 2015 16:05:59 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 3 Oct 2015 11:05:58 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sat, 3 Oct 2015 11:05:58 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Sat, 3 Oct 2015 11:05:58 -0500
From: "Acee Lindem (acee)" <>
To: "" <>, "Alvaro Retana (aretana)" <>
Thread-Topic: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution
Thread-Index: AdD9yQO60fpcSwLyRE2qgwPvotAKewANMDUA
Date: Sat, 3 Oct 2015 16:05:57 +0000
Message-ID: <>
References: <022901d0fdc9$0ea4ce80$2bee6b80$>
In-Reply-To: <022901d0fdc9$0ea4ce80$2bee6b80$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Oct 2015 16:06:04 -0000

Hi Adrian, Alvaro, 

See one inline below…

On 10/3/15, 6:48 AM, "Idr on behalf of Adrian Farrel"
< on behalf of> wrote:

>Thanks, Alvaro, for your review of (I think) version -10 of the draft.
>Here are some answers to your questions.
>> Major:
>> Section 5 (IANA Considerations)
>> I didn't see this comment as part of IANA's review, but the text about
>Designated Experts
>>  should be clarified.  There is some guidance in RFC5226.
>You're right.
>I think we should add a new subsection 5.1...
>5.1  Guidance for Designated Experts
>In all cases of review by Designated Expert (DE) described here, the DE is
>expected to ascertain the existence of suitable documentation (a
>as described in RFC5226, and to verify the permanent and publically
>available of the document. The DE is also expected to check the clarity of
>purpose and use of the requested code points. Lastly, the DE must verify
>any specification produced in the IETF that requests one of these code
>has been made available for review by the IDR working group, and that any
>specification produced outside the IETF does not conflict with work that
>active or already published within the IETF.
>> "Note to RFC Editor: this section may be removed on publication as an
>The IANA 
>> considerations section should remain because there are in fact
>Yes, this text is a hang-over from the document template.
>> I would like to have Designated Experts in place soon.  It seems to me
>having 2 of the
>> authors volunteer (primary and backup) would be ideal.  Please let me
>>know if
>you want to do it.
>I think the absence of an answer speaks for itself.
>> 6.1.2 (Installation and Initial Setup): [default] "maximum rate at which
>Link-State NLRIs will
>> be advertised/withdrawn from neighbors is set to 200 updates per
>Where did the
>> number come from?  It does look very big.  Are you assuming just
>>changes or
>startup as well?
>> One of my concerns is the interaction with other BGP stuff (like regular
>> In fact, in 6.1.5 (Impact on Network Operation) you wrote:  "Frequency
>Link-State NLRI
>> updates could interfere with regular BGP prefix distribution.  A network
>operator MAY use
>> a dedicated Route-Reflector infrastructure to distribute Link-State
>> Why not use SHOULD?  If there may be significant operational impact I
>you should be
>> more direct with the guidance.
>There are several questions folded in here.
>Firstly, understand that the maximum rate described here is the default
>rate if
>not overridden by an operator or by an implementation that knows better.
>So we
>shouldn't get too hung up on it. Although, obviously, there is a
>expectation that if an implementation uses this default value the function
>should work.
>Why 200? Not sure where that came from. I have no evidence that 200 is a
>and given that IDR has done quite a bit of implementation and interop
>anyone screaming, I assume this is OK.
> doesn't
>mention any problems. Are you aware of implementations where this is a
>Could BGP-LS advertisements impact on "other BGP stuff"? Well, that
>really is an
>implementation and deployment issues? Will the BGP-LS speaker doing the
>advertisements also advertise "other BGP stuff" on the same session? Is
>advertisement higher cost than the consolidation of IGP-TE information
>and the
>application of policy to determine what LS information to advertise.
>Could the
>advertisements be prioritised? This has been something of a recent thread
>on the
>IDR list and, although you are raising interesting questions, I don't
>believe we
>have any way to draw a line unless someone reports real problems that are
>caused by implementation choices, yet we are required (by the IESG) to
>defaults for configurable parameters.
>Why "MAY" use a dedicated RR rather than "SHOULD"? Because there really
>appear to be any indication that this is a problem in all networks with
>all BGP
>> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
>attribute, then
>> it SHOULD use the 'Attribute Discard' action.."  Doesn't this mean that
>information may be
>> useless, completely missing, or in the best case incomplete?  Aren't we
>off just resetting
>> the session or at least requesting a route refresh?
>I don't think we are assuming corruption. So the malformed attribute
>comes as
>the result of an implementation difference or a bug at the sender.
>Requesting a
>refresh runs a significant risk of simply thrashing the advertisement
>since each
>time it is sent it will contain the same malformed attribute. This
>problem is
>considerably worsened if the session is reset because then we thrash the
>> Minor:
>> 3.1 (TLV Format): "Unrecognized types are preserved and propagated."
>statement sounds necessary
>> for interoperability and the correct propagation of the information.
>it have a "MUST" in it?
>Isn't this standard behavior for unknown TLVs in BGP?
>E.g., 5512 section 4 "Unknown types are to be ignored and skipped upon
>That said, 5512 section 4 also says "When the TLV is being processed by a
>speaker that will be performing encapsulation, any unknown sub-TLVs MUST
>ignored and skipped."
>Since the behavior described here is new in as much as it describes
>of a new NLRI, I think using "MUST" would be OK.
>> 3.1 (TLV Format): "If there are more TLVs of the same type, then the
>be ordered
>> in ascending order of the TLV value within the TLVs with the same type."
>Ordered by value?
>>  How is that done?  Some TLVs contain sub-TLVs in the value field, but
>We could say "treating the entire value field an opaque hexadecimal
>string and
>comparing leftmost octets first regardless of the length of the string."
>> 3.2.1 (Node Descriptors):  The BGP-LS Identifier is used, but it is
>later in 
>> Please add a reference so that it is not mistaken for the "Identifier"
>>(in the
>> themselves in Section 3.2).
>Per Alia's comment replacement text is...
>  BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier
>  (see Section to disambiguate the Router-IDs, as described in
>  Section
>> 3.3.2 (Link Attribute TLVs):  The attributes used are defined for ISIS,
>are easily 
>> derived from OSPF, but other don't map to anything.  For example,
>> group (color)".  How are these types of undefined parameters in OSPF
>> I suspect the easy answer is to just say that it is out of scope, but
>>the fact
>> that there can be information there that doesn't exist in the original
>protocol.  It
>> should at least be clarified what is expected.  Note that in
>Risk Link
>> Group TLV) a different case of this shows up: the text seems to
>>indicate that
>> because there is no SRLG TLV in OSPD-TE, then this information wouldn't
>> available.  Again, please clarify if there may be procedures outside
>>the scope
>> the document that could apply.
>I'm not sure the missing attributes should be "figured out". The job of
>is to collect and distribute information from the IGP. If the information
>is not
>there, it would not be invented by the
>BGP-LS speaker.
>The SRLG case has been fixed in -11: it was an error.
>> (MPLS Protocol Mask TLV)
>> OLD>  
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-
>>   IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2.
>> NEW>
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with other protocol-Ids.
>Certainly your proposal appears right: there are only four protocols
>listed in
>Table 2, but there is the question of future IDs. So we could write...
>   Generation of the MPLS Protocol Mask TLV is only valid for
>   originators which have local link insight, like for example Protocol-
>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>   TLV MUST NOT be included in NLRIs with the other Protocol-IDs
>   listed in Table 2.
>I don't object to this change, but struggle to see the value.
>>  "LINK_STATE attribute" shows up in 3.3.2 and 3.3.3.  What is it?
>Thanks for this catch. Old text. Should now read "BGP-LS attribute with a
>> In (Node Flag Bits TLV) you included the ISIS Overload Bit, but
>> say anything about OSPFv3's R-bit or v6-bit; and in (IGP Flags
>> included the IS-IS Up/Down Bit in this TLV, but I didn't see the OSPF
>> anywhere.  Are these opportunities to reuse the same bit with a more
>> definition while covering a similar option in OSPF?  I know you can't
>> the options, but these two are well-known and seem low hanging fruit.
>Although no-one was asking for this and no-one will have implemented it,
>I can
>see no reason not to change to read...
>  Node Flag Bits TLV
>   The Node Flag Bits TLV carries a bit mask describing node attributes.
>   The value is a variable length bit array of flags, where each bit
>   represents a node capability.
>      0                   1                   2                   3
>      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 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              Type             |             Length            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |O|T|E|B|R|V| Rsvd|
>     +-+-+-+-+-+-+-+-+-+
>                   Figure 15: Node Flag Bits TLV format
>   The bits are defined as follows:
>            +----------+-------------------------+-----------+
>            |   Bit    | Description             | Reference |
>            +----------+-------------------------+-----------+
>            |   'O'    | Overload Bit            | [RFC1195] |
>            |   'T'    | Attached Bit            | [RFC1195] |
>            |   'E'    | External Bit            | [RFC2328] |
>            |   'B'    | ABR Bit                 | [RFC2328] |
>            |   'R'    | Router Bit              | [RFC5340] |
>            |   'V'    | V6 Bit                  | [RFC5340] |
>            | Reserved | Reserved for future use |           |
>            +----------+-------------------------+-----------+
>                    Table 8: Node Flag Bits Definitions
>And similarly no-one has asked for the DN-bit from 2328 or 5340 in section
> I am less sanguine about adding this as I am not quite sure that
>it is
>useful in BGP-LS, but it would certainly be easy to add. With this bit,
>and with
>other potential additions to both bit fields, I suggest we wait for the
>need/desire and folk can write new drafts.

The DN-bit is not really applicable to at the Node level in OSPF and
IS-IS. It is applicable to prefixes and is included in the flags in
section (See the D-bit). For extra credit, you could add a
reference to OSPF and RFC 4576. This document started out with very few
references to the applicable OSPF RFCs but quite a few have been added by
Alia and me. 


>> 6.2.5.  (Performance Management)  It might be nice to include
>> one of the performance indicators.
>I think that we add to the bottom of 6.2.5 as follows:
>"These statistics should be recorded as absolute counts since system or
>start time. An implementation MAY also enhance this information by also
>recording peak per-second counts in each case."
>> Section 8 (Security Considerations) "The principal attack a consumer
>>may apply
>is to 
>> attempt to start multiple sessions either sequentially or
>Isn't this
>> an attack that any other node can try?  Why limit the discussion only to
>I think you have to be a recognised peer for this attack to have any
>value that is specific to *this* document.
>> Looking at the references, it seems to me that the following changes
>> be made: 
>> Make Informative: RFC1918
>> Make Normative: I-D.ietf-idr-error-handling
>Yes, and this is now RFC7606
>> Curious question:  When encoding a "normal" size node using BGP-LS,
>>what is
>> resulting size of the UPDATE?
>I'll leave this as an exercise for the reader.
>> Nits:
>> 3.2: s/'Static' protocol types/'Static configuration' protocol types
>> Again
>> 3.2.1 and 6.2.3 : What does "Paragraph 2" refer to?
>> "mandatory TLV in all three types of NLRIs"  I assume you're
>referring to Node,
>> Link and Prefix NLRIs, right?  However, it is confusing because there
>>are in
>fact 4 types
>> defined.  Please correct.
>> "IGP Router ID.mandatory TLV"  Should be sub-TLV.
>> "The Route Type TLV allows to discrimination of these
>> Route Type TLV allows the discrimination of these advertisements.
>> Please be consistent in the name.  Is it "MPLS Protocol Mask
>>TLV" or
>> "MPLS Protocol TLV"?
>> The description of the example in 3.7 is easier to read (because of the
>formatting) than
>> the one in 3.6.  It would be nice to be consistent.
>> 3.8 seems to be a better example of simply ships in the night than
>as the
>> emphasis is put on identifying the common links of the two processes.
>> 4.1 s/"see" the full topology of AS/"see" the full topology of AS2
>I'll work through the nits as well.
>New revision "soon".
>Idr mailing list