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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Oct 2015 11:48:36 +0100

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 the
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 specification)
as described in RFC5226, and to verify the permanent and publically readily
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 that
any specification produced in the IETF that requests one of these code points
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 is
active or already published within the IETF.

> "Note to RFC Editor: this section may be removed on publication as an RFC."
The IANA 
> considerations section should remain because there are in fact considerations
there.

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 that
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 second."
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
routing!).  
> In fact, in 6.1.5 (Impact on Network Operation) you wrote:  "Frequency of
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 NLRIs."  
> Why not use SHOULD?  If there may be significant operational impact I think
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 reasonable
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 problem
and given that IDR has done quite a bit of implementation and interop without
anyone screaming, I assume this is OK.
https://www.ietf.org/id/draft-ietf-idr-ls-distribution-impl-04.txt doesn't
mention any problems. Are you aware of implementations where this is a problem?

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 the
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 not
caused by implementation choices, yet we are required (by the IESG) to supply
defaults for configurable parameters.

Why "MAY" use a dedicated RR rather than "SHOULD"? Because there really doesn't
appear to be any indication that this is a problem in all networks with all BGP
implementations. 

> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a malformed
attribute, then
> it SHOULD use the 'Attribute Discard' action.."  Doesn't this mean that the
information may be
> useless, completely missing, or in the best case incomplete?  Aren't we better
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 whole
session.

> Minor:
>
> 3.1 (TLV Format): "Unrecognized types are preserved and propagated."  This
statement sounds necessary 
> for interoperability and the correct propagation of the information.  Should
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 receipt."
That said, 5512 section 4 also says "When the TLV is being processed by a BGP
speaker that will be performing encapsulation, any unknown sub-TLVs MUST be
ignored and skipped."
Since the behavior described here is new in as much as it describes processing
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 TLVs MUST
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 others
don't.

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 defined
later in 3.2.1.4. 
> Please add a reference so that it is not mistaken for the "Identifier" (in the
NLRIs
> 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 3.2.1.4) to disambiguate the Router-IDs, as described in
  Section 3.2.1.1.

> 3.3.2 (Link Attribute TLVs):  The attributes used are defined for ISIS, some
are easily 
> derived from OSPF, but other don't map to anything.  For example,
"administrative
> group (color)".  How are these types of undefined parameters in OSPF figured
out?
> I suspect the easy answer is to just say that it is out of scope, but the fact
remains
> 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 3.3.2.5 (Shared
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 be 
> available.  Again, please clarify if there may be procedures outside the scope
of
> the document that could apply.

I'm not sure the missing attributes should be "figured out". The job of BGP-LS
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.

> 3.3.2.2 (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.

Why?
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 link
NLRI"

> In 3.3.1.1 (Node Flag Bits TLV) you included the ISIS Overload Bit, but didn't
> say anything about OSPFv3's R-bit or v6-bit; and in 3.3.3.1 (IGP Flags TLV)
you
> included the IS-IS Up/Down Bit in this TLV, but I didn't see the OSPF DN-bit
> anywhere.  Are these opportunities to reuse the same bit with a more generic
> definition while covering a similar option in OSPF?  I know you can't cover
all
> 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...

3.3.1.1.  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
3.3.3.1. 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.

> 6.2.5.  (Performance Management)  It might be nice to include updates/second
as 
> 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 session
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 simultaneously."
Isn't this
> an attack that any other node can try?  Why limit the discussion only to
consumers?

I think you have to be a recognised peer for this attack to have any significant
value that is specific to *this* document.

> Looking at the references, it seems to me that the following changes could
> be made: 
> Make Informative: RFC1918
Sure
> 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
the
> 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
in 3.3.2.2.
> 3.2.1 and 6.2.3 : What does "Paragraph 2" refer to?
> 3.2.1.2: "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.
> 3.2.1.4: "IGP Router ID.mandatory TLV"  Should be sub-TLV.
> 3.2.3.1: "The Route Type TLV allows to discrimination of these
advertisements./The 
> Route Type TLV allows the discrimination of these advertisements.
> 3.3.2.2: Please be consistent in the name.  Is it "MPLS Protocol Mask TLV" or
just
> "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 migration
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".

Thanks,
Adrian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 3 Oct 2015 16:05:57 +0000

Hi Adrian, Alvaro, 

See one inline below…

>   represents a node capability.

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 3.3.3.1 (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. 

Thanks,
Acee

>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 4 Oct 2015 13:55:24 +0000

On 10/3/15, 6:48 AM, "Adrian Farrel" <[email-masked]> wrote:

Adrian:

Hi!  Thanks for helping move this document forward.

I¹m replying only to the points I don¹t agree with, or just have some
additional comments about.  Please take a look below.

Thanks!

Alvaro.

. . .
>available of the document. The DE is also expected to check the clarity of

s/available/availability

>active or already published within the IETF.
. . .
>I think the absence of an answer speaks for itself.

:-(

Given the potential for extensions, I¹ll be back knocking soon..

>mention any problems. Are you aware of implementations where this is a

No, but implementation and interop (most likely in a controlled
environment) is very different than operation in the wild.  But I am sure
that you (and everyone else listed as an author) obviously knows that.

>defaults for configurable parameters.

Section 6 is the ³Operational Considerations² section, where I expect you
to provide operational considerations.  It sounds like you¹re saying we
need deployment (not just testing) experience so that clear guidance can
be given and that you¹re otherwise putting numbers in there just because
you have to, am I interpreting this correctly?

>the result of an implementation difference or a bug at the sender.

That would still result in the receiver not having the information.  The
cause doesn¹t seem to matter in this case, the end result does.

>Requesting a

Of course.

I was trying (and didn¹t do a good job) to suggest that if we had
isolation (as in carrying the BGP-LS in a separate session/RR
infrastructure), then a better job could be done at not only isolating
from failure but also at recovering information so that both application
could work better.

. . .
>I don't object to this change, but struggle to see the value.

Why?  Potential future IDs..

I think that just listing IDs that are now in Table 2 (as in the original
text, which is the same as saying ³other..in Table 2²), doesn¹t cover
future IDs that don¹t have ³local link insight².  Table 2 already contains
IDs for protocols that have that insight and others that don¹t..and we (at
least I) don¹t know what other things will be put in there.  In short, I
think we should just leave it open and not list specifics as those could
change.

Now that I revisit this point, I think that the new text should be
something like this:

   The ŒMPLS Protocol Mask¹ TLV SHOULD only be used with
   originators that have local link insight, like for example
   Protocol-IDs 'Static' or 'Direct' as per Table 2.

That way, if others come up in the future we¹re covered and not dependent
on a Table.

. . .
>value that is specific to *this* document.

I meant that a BGP Speaker could also start multiple sessions with a
consumer, for example.

. . .
>I'll leave this as an exercise for the reader.

Thanks! :-(

I was mostly wondering if the information is anywhere close to 4k or not.
The implementation report doesn¹t say anything either. :-(

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Oct 2015 18:39:29 +0100

Thanks Acee,

That's helpful.

Adrian

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Oct 2015 19:08:54 +0100

Thanks for this Alvaro,

I made some further changes and just posted a revised I-D.

I'll spell out the changes for the WG and answer your email shortly.

Adrian

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:[email-masked]]
> Sent: 04 October 2015 14:55
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Alvaro's AD Comments on draft-ietf-idr-ls-distribution
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Oct 2015 21:57:17 +0100

Hi Alvaro,

Here is a better reply snipped still further.

> >> Major:
> >> I would like to have Designated Experts in place soon.  It seems to me
> >> that having 2 of the authors volunteer (primary and backup) would be
> >> ideal.  Please let me know if you want to do it.
> >

I'm not close enough to running code. I'm sure the WG can find stuckees.

> >> Link-State NLRIs will be advertised/withdrawn from neighbors is set to
> >> 200 updates per second."
> >>Where did the number come from?  It does look very big.  Are you
> >> assuming just changes or startup as well?
> >>routing!).  In fact, in 6.1.5 (Impact on Network Operation) you wrote:
> >> "Frequency of 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 NLRIs."
> >> Why not use SHOULD?  If there may be significant operational impact I
> >>think you should be more direct with the guidance.
> >
> >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
> > reasonable 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 problem and given that IDR has done quite a bit of implementation
> > and interop without anyone screaming, I assume this is OK.

I think it is tremendously difficult to work out / predict what a reasonable
default value is for operation in  real network. I'd be happy to not give any
guidance because of that, but history says that if we don't suggest a default we
will be caned by the IESG. You can't win :-)

We have picked a value we believe will not be a problem. But it is art not
science.

> > 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 the 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 not caused by
> > implementation choices, yet we are required (by the IESG) to supply

I think so.
We can only start to guess at this stage.
Certainly there are things you can do to be "safe". But they might not be
optimal.

This remains one of the problems with an Operational Considerations section for
a protocol extension where it is unclear what the impact will be.

> > Why "MAY" use a dedicated RR rather than "SHOULD"? Because there really
> > doesn't appear to be any indication that this is a problem in all networks
with
> > all BGP implementations.

So the bottom line is that I haven't made any changes for this.
If you want to suggest some weasel words about how to monitor your deployment
and what to look for that might be a symptom of stuff going wrong, and then what
to do about it, we can surely cut and paste your text.

> >> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
> >> malformed attribute, then it SHOULD use the 'Attribute Discard' action.."
> >> Doesn't this mean that the information may be useless, completely missing,
> >> or in the best case incomplete?  Aren't we better 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.
> 

Absolutely.
So you have to choose between having most of the info from the network minus
some pieces that you couldn't parse, or resetting the session and having no
information about the network.
Perhaps we should be "raising an alert to the operator" when this happens? (rate
limits may apply)

> > 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 whole session.
> 
> Of course.
> 

So I maintain that you can't recover. All you can do is start again, which is
worse than helpful.

Certainly, if you choose to reset the session then using a separate session for
different things would be a wise idea. But if you do as we suggest then I don'
think it matters because you don't perturb the "normal" BGP work.

> >> 3.3.2.2 (MPLS Protocol Mask TLV)
[snip]
> That way, if others come up in the future we¹re covered and not dependent

OK. I reworked this text.

> >> Section 8 (Security Considerations) "The principal attack a consumer
> >> may apply is to attempt to start multiple sessions either sequentially or
> >> simultaneously."
> >> Isn't this an attack that any other node can try?  Why limit the 
> >> discussion only to consumers?
> >
> > I think you have to be a recognised peer for this attack to have any
> > significant value that is specific to *this* document.
> 

Hmmm. OK.
I suspect that if a core router is compromised to the extent that it attacks the
BGP-LS consumers, we have *are* worse problems to contemplate.

> >> Curious question:  When encoding a "normal" size node using BGP-LS,
> >> what is the resulting size of the UPDATE?
> >

OK. I see your point. The problem presumably exists for the IGPs as well (maybe
more for OSPF than for ISIS).

Anyone in the DR WG want to do the math?

Thanks,
Adrian

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 5 Oct 2015 12:19:59 +0000

On 10/4/15, 4:57 PM, "Adrian Farrel" <[email-masked]> wrote:

>Here is a better reply snipped still further.

Thanks again for pushing this along..  I¹m putting the draft on the next
Telechat.

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 15:34:45 -0400

Adrian,

> We have picked a value we believe will not be a problem. But it is art not

It is very much art rather than science.  The properties we are looking for
include:
- Distribute LS changes "fast enough"
- Don't propagate thrash; i.e. don't be too fast for some stuff.
- Remember that the cost in BGP is often borne by the receiver rather than
  the sender.

Constants will almost always be wrong at some point in time, so best we can
suggest is an initial value that will eventually be ignored by posterity.

> Perhaps we should be "raising an alert to the operator" when this happens? (rate

Resetting the session is almost always the wrong thing to do.  Thankfully
the desired behaviors, including operational, are already covered in RFC 7606:

:   Because of these potential issues, a BGP speaker must provide
:   debugging facilities to permit issues caused by a malformed attribute
:   to be diagnosed.  At a minimum, such facilities must include logging
:   an error listing the NLRI involved and containing the entire
:   malformed UPDATE message when such an attribute is detected.  The
:   malformed UPDATE message should be analyzed, and the root cause
:   should be investigated.

> Anyone in the DR WG want to do the math?

Not particularly.  I think this is a case where we'd really want the IGP
experts to give us ideas of max message sizes and then we'd double-check
BGP-LS.

That said, draft-ietf-idr-bgp-extended-messages is intended to help with
these sorts of situations.  (Although that's not broadly implemented yet.)

-- Jeff

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 5 Oct 2015 19:52:48 +0000

On 10/5/15, 3:34 PM, "Jeffrey Haas" <[email-masked]> wrote:

. . .
>these sorts of situations.  (Although that's not broadly implemented yet.)

Exactly!  If we're anywhere close (I don't think so) then we might need
the extended-messages faster..

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 6 Oct 2015 15:01:43 -0400

Jeff, Alvaro, and Adrian: 

I will check with the 2nd implementer of
draft-ietf-idr-bgp-extended-messages to see if he has implemented the draft.
The implementation was contingent on the early allocation. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Monday, October 05, 2015 3:53 PM
To: Jeffrey Haas; Adrian Farrel
Cc: [email-masked]
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

. . .
>>OK. I see your point. The problem presumably exists for the IGPs as 
>>well (maybe more for OSPF than for ISIS).
>Not particularly.  I think this is a case where we'd really want the 
>IGP experts to give us ideas of max message sizes and then we'd 
>double-check BGP-LS.
>
>That said, draft-ietf-idr-bgp-extended-messages is intended to help 
>with these sorts of situations.  (Although that's not broadly 
>implemented yet.)

Exactly!  If we're anywhere close (I don't think so) then we might need the
extended-messages faster..

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 6 Oct 2015 15:02:51 -0400

Adrian :

The next time you edit draft-ietf-idr-ls-distribution in section 3.3.2.2.

Typo: 
/>Generation of the MPLS Protocol Mask/Generation of MPLS Protocol Mask/

Sue Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Monday, October 05, 2015 3:53 PM
To: Jeffrey Haas; Adrian Farrel
Cc: [email-masked]
Subject: Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

. . .

Alvaro.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Oct 2015 11:23:17 +0100

Ack