Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

From: Job Snijders <[email-masked]>
Date: Thu, 2 Dec 2021 16:10:43 +0100

Hi Folks,

Please take 15 minutes out of your day to review this *really short!*
internet-draft. The authors were kind enough to make it only 3 pages of
actual content :-)

We'll extend this WGLC with another week (December 9th, 2021)

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:33:39PM +0000, [email-masked] wrote:
> Dear GROW WG, dear authors
> 
> I have reviewed the draft. I think it is straight forward and ready for IESG. 
> 
> It is the next logical step to make the different BMP message types to be equal by supporting TLV's for BMP route-monitoring and peer_down messages as well.
> 
> Best wishes
> Thomas
> 
> -----Original Message-----
> From: GROW <[email-masked]> On Behalf Of Job Snijders
> Sent: Tuesday, November 16, 2021 5:16 PM
> To: Paolo Lucente <[email-masked]>
> Cc: [email-masked] [email-masked] <[email-masked]>
> Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)
> 
> Dear all,
> 
> This starts the formal WGLC period which will run from November 16th until December 1st 2021.
> 
> Please review https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjlhrhaE%3D&amp;reserved=0
> and provide comments or feedback on the [email-masked] mailing list!
> 
> Kind regards,
> 
> Job
> 
> On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> > Dear Colleagues, Dear Chairs,
> > 
> > A brief email to follow-up the presentation of draft-ietf-grow-bmp-tlv 
> > last week at the WG meeting. We authors believe there are no more 
> > items to work on for this draft, received inputs were processed and 
> > any questions / concerns were addressed. I'd hence like to ask to LC this work.
> > 
> > You may read motivation for this work in the draft itself, let me 
> > supplement it saying that this is a key piece of work that would make 
> > extensible every BMP message defined so far; this, in turn, would 
> > bring BMP on par with other modern monitoring (/ telemetry) protocols (/ stacks / solutions).
> > 
> > Paolo
> > 
> > _______________________________________________
> > GROW mailing list
> > [email-masked]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CThomas.Graf%40
> > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3D&amp;reserve
> > d=0
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Mon, 6 Dec 2021 06:53:40 +0000

Hallo GROW WG

I've read the draft. 
TLV on BMP monitoring- and peerdown-messages complete BMP and make it uniform.
I am looking very forward to collect ADD-PATH on our collectors as a standard 
to bring more visability (a.e. backup-path) to our BGP monitoring.
I think the draft is ready to forward to IESG.

Have a good week
Matthias

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Job Snijders
Sent: Dienstag, 16. November 2021 17:16
To: Paolo Lucente <[email-masked]>
Cc: [email-masked] [email-masked] <[email-masked]>
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Dear all,

Please review https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06&amp;data=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1FAQOy3X%2FtjxztaFoNEwcOT4bZGliXRcnTHZbFPc%2FRQ%3D&amp;reserved=0
and provide comments or feedback on the [email-masked] mailing list!

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CMatthias.Arnol
> d%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d
> 9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000&amp;sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3D&amp;r
> eserved=0

_______________________________________________
GROW mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3D&amp;reserved=0

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 6 Dec 2021 09:49:41 +0000

Hi GROW WG,

I have read this draft. I think It is very useful to provide a unified TLV mechanism for various BMP messages. I support publication of this draft.

Thanks,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Thursday, December 2, 2021 11:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hi Folks,

Please take 15 minutes out of your day to review this *really short!* internet-draft. The authors were kind enough to make it only 3 pages of actual content :-)

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:33:39PM +0000, [email-masked] wrote:
> Please review 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06&amp;data=04
> %7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%
> 7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000&amp;sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjl
> hrhaE%3D&amp;reserved=0 and provide comments or feedback on the 
> [email-masked] mailing list!
> 
> Kind regards,
> 
> Job
> 
> > A brief email to follow-up the presentation of 
> > draft-ietf-grow-bmp-tlv last week at the WG meeting. We authors 
> > believe there are no more items to work on for this draft, received 
> > inputs were processed and any questions / concerns were addressed. I'd hence like to ask to LC this work.
> > 
> > supplement it saying that this is a key piece of work that would 
> > make extensible every BMP message defined so far; this, in turn, 
> > would bring BMP on par with other modern monitoring (/ telemetry) protocols (/ stacks / solutions).
> > 
> > Paolo
> > 
> c35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJW
> amp;sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3D&amp;reser
> ved=0

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 6 Dec 2021 10:04:15 +0000

Hi Matthias,

Indeed, adding an ADD-PATH capability TLV to the Route Monitoring message will be a good use case.
In this way, when the BMP server parses the BGP Update message containing the ADD-PATH ID, it does not need to check the related Peer Up notification message again.

BR,
Shunwan

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 6, 2021 2:54 PM
To: job=[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hallo GROW WG

I've read the draft. 
TLV on BMP monitoring- and peerdown-messages complete BMP and make it uniform.
I am looking very forward to collect ADD-PATH on our collectors as a standard to bring more visability (a.e. backup-path) to our BGP monitoring.
I think the draft is ready to forward to IESG.

Have a good week
Matthias

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Job Snijders
Sent: Dienstag, 16. November 2021 17:16
To: Paolo Lucente <[email-masked]>
Cc: [email-masked] [email-masked] <[email-masked]>
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Dear all,

Kind regards,

Job

---

From: Jared Mauch <[email-masked]>
Date: Mon, 6 Dec 2021 10:13:50 -0500

Similar, I have read this and it seems straightforward.

	My only question  is around the BMP versioning, do we expect
that to extend past 255 at some point?

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Chenshuanglong <[email-masked]>
Date: Tue, 7 Dec 2021 02:14:41 +0000

Dear all

      I have reviewed the draft.   It is very useful to provide a uniform TLV mechanism for various BMP messages.

Best Regards
Shuanglong

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Thursday, December 2, 2021 11:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hi Folks,

Kind regards,

Job

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 7 Dec 2021 11:31:52 +0800

Hi, All:

I have read the draft and think it is ready for the IESG review. There are
scenarios that additional information encoded in the potential TLVs for the
two BMP messages are expected, as also that discussed in the mail list.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Job
Snijders
Sent: Thursday, December 2, 2021 11:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st
2021)

Hi Folks,

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:33:39PM +0000, [email-masked] wrote:
> It is the next logical step to make the different BMP message types to be
equal by supporting TLV's for BMP route-monitoring and peer_down messages as
well.

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Wed, 8 Dec 2021 10:09:47 +0000

Dear Chairs & WG,

	I have read the draft. The mechanism proposed in the draft was useful. As I know, some vendors have implemented it.
    I think it is ready to move forward. 

Best Regards
Haibo

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Thursday, December 2, 2021 11:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hi Folks,

Kind regards,

Job

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 8 Dec 2021 10:12:41 +0000

Hi Job,

I've read this document and support to move it forward. It provides useful mechanisms to make the BMP messages extensible. 

Best regards,
Jie

> equal by supporting TLV's for BMP route-monitoring and peer_down
> messages as well.
> >
> > Best wishes
> > Thomas
> >
> ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CThomas.G
> raf%
> > > 40
> > >
> swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c
> 7420d9b
> > > ee
> > >
> c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWF
> pbGZsb3d8ey
> > > JW
> > >
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 300
> > > 0&
> > >
> amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3D&amp;
> reser
> > > ve
> > > d=0
> >

---

From: Ben Maddison <[email-masked]>
Date: Wed, 8 Dec 2021 15:40:21 +0200

Hi all,

> internet-draft. The authors were kind enough to make it only 3 pages of
I have read the draft, and agree with others that it is a straight
forward solution to a genuine problem.

I have a couple of questions/comments:

1.  I don't understand the purpose of the SHOULD in:
    
        TLVs SHOULD be sorted by their code point. Multiple TLVs of the
        same type can be repeated as part of the same message, and it is
        left to the specific use-cases whether all, any, the first or
        the last TLV should be considered. 

    A receiver clearly cannot optimise for receiving the TLVs sorted,
    since it isn't a MUST. Beyond this, why is it useful?

2.  In the types defined in section 4.2, I read "value MUST be boolean"
    as meaning "length MUST be 1 and value MUST be either 0x00 or 0x01".

    Is that correct? If so, perhaps it is better to be explicit?

3.  I had a variety of grammatical/editorial suggestions. Rather than
    gum-up the list with these, I have opened a pull-request at:
    https://github.com/paololucente/draft-ietf-grow-bmp-tlv/pull/2

    I hope that makes review more convenient for the authors.

Cheers,

Ben

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 8 Dec 2021 11:43:52 -0400

Hi Ben,

Thank you for your review, very much appreciated. I will merge your PR 
on GitHub asap. With regards to the other two points:

1) This came through a suggestion back then from Jeff Haas that i 
support as it made sense to me, see here his comment on this list:

==
While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
code point.".

Many implementations that deal with TLV based protocols will 
canonicalize data structures based on the TLVs using sorted structures. 
  Having them sorted on the wire means the canonicalization step is cheaper.

Note that this is a general justification for the procedure and it's not
critical for something like BMP.
==

2) That is right & suggestion accapted. I will make it further explicit.

Paolo

---

From: Ben Maddison <[email-masked]>
Date: Wed, 8 Dec 2021 18:00:44 +0200

Hi Paolo,

On 12/08, Paolo Lucente wrote:
> 
> Hi Ben,
> 
> Thank you for your review, very much appreciated. I will merge your PR on
> GitHub asap. With regards to the other two points:
> 
> 1) This came through a suggestion back then from Jeff Haas that i support as
> it made sense to me, see here his comment on this list:
> 
> ==
> Many implementations that deal with TLV based protocols will canonicalize
> data structures based on the TLVs using sorted structures.  Having them
> sorted on the wire means the canonicalization step is cheaper.
> 
That makes sense, thanks.
Having never written a routine that does this, I am slightly surprised
that it is still cheaper, even if the implementation cannot *require* that
it will arrive sorted - but I am more than happy to take yours and Jeff's
word for it!

> 2) That is right & suggestion accapted. I will make it further explicit.
Ack. Thanks.

Cheers,

Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Dec 2021 11:44:08 -0500

Ben,

> > While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
[...]
> it will arrive sorted - but I am more than happy to take yours and Jeff's

Since it's not a state secret and a very common strategy for building
canonicalized collections:

1. Syntactically and semantically verify the contents of the received
TLV set.
2. Presuming step 1 passes, determine if for those rules whether there are
places in the data that should be cleaned/stripped.  As an example, an NLRI
MAY be encoded with trailing bits after the prefix length. (This causes fun
bugs elsewhere in the code in many cases!)  Step 2 might be done in tandem
with step 1 depending on whether the buffer in question is yours to do with
as you please or whether you're dealing with a shared buffer.
3. Presuming step 2 is done and is sorted in a canonical order[1], you can
simply take the memory in question and use it as a long key in a collection
to find an object with the same contents.  The collection in question is
usually some nice bit of work appropriate to the key properties, but
anything that's efficient will work.  Some implementations are partial to
height balanced trees, others to radix tables or similar like PATRICIA.

There is significant room for optimizations in step 3.

Why does sorted matter?  Because if it's not, you need to insert a step
between 2 and 3 to canonicalize the data prior to the lookup step.
Otherwise you'll happily find an object (or not) in your collection that
matches the bit pattern but duplicates the semantics of the object.

E.g. {1,2,3} and {1,3,2} may be the same state, but you now have two objects
representing it.  Having a common object means you can now link state
together from that canonicalized object and use it to find related things as
another key.

-- Jeff

[1] The BMP TLV draft somewhat frustratingly permits multiple instances of
the same type in a TLV set.  Repetitions breed ambiguityin canonicalization.
A result of this is that when "pick one" is an answer, sometimes you get
behavior that depends on the implementation's sorting choice in this
instance.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Dec 2021 11:57:08 -0500

> We'll extend this WGLC with another week (December 9th, 2021)

A few comments:

4.2: "value MUST be boolean" really isn't precise enough  I suspect the
intent is "0 is false, 1 is true".  Spell that out.  Some protocols the
existence of a zero-length TLV as a presence node is sufficient to say
"true".  And perhaps some people's code says

#define FALSE 0
#define TRUE !FALSE

You may even want to be more limiting and require that the length of the TLV
is one.

7 IANA Considerations:
You're effectively defining a registry for route monitoring messages.  That
should likely be a new registry - see examples in RFC 7854 section 10.

No TLVs are being defined for peer down.  I still suggest creating a
registry.

The registry policies in section 10 probably aren't what you want.  E.g.:
:   Information type values 0 through 32767 MUST be assigned using the
:   "Standards Action" policy, and values 32768 through 65530 using the
:   "Specification Required" policy, defined in [RFC5226].  Values 65531
:   through 65534 are Experimental, and value 65535 is Reserved.

I don't recall the status of changing of the policies.  Wasn't there a draft
on that circulating or am I remembering incorrectly?

A final meta comment that probably belongs in an Error Handling section:
For a route monitoring message, the new TLVs follow an encoded BGP Update
message.  BGP isn't a rigorous TLV protocol, as we know.  And certainly, a
BMP implementation MUST know how to decode a BGP PDU in order to do its
work.

That said, an implicit property for route monitoring optional TLVs is that
the encapsulated BGP Update is well-formed!  If it is not, then you can't
seek into the optional TLV section and parse it appropriately.

Related indirect property: If you want to have BMP as a channel for bad BGP
PDUs, it probably needs to be via route mirroring.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Dec 2021 12:22:10 -0500

> BMP implementation MUST know how to decode a BGP PDU in order to do its

This also knocked loose an interesting issue that we don't have to worry
about for the short term but is applicable here:

RFC 8654 provides for an extended message length for BGP.

In pathological circumstances, an implementation with extended message
support being encapsulated in a BMP PDU might not be able to fit.  This is
already a theoretical problem without the optional TLVs, but might become
more of one with the TLVs.

It might be worth one sentence of mention in Error Handling if such a
section is created.  "RFC 8654 permits BGP Updates and other messages to
grow to a length of 65535 octets.  This may cause a BMP PDU that attempts to
encapsulate such long messages to overflow."

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Mon, 13 Dec 2021 20:21:09 -0300

Hi Jeff,

Thanks very much as always for your comments.

Ack about the boolean part. That adds up very well to a similar comment 
Ben's made in his email. Will fix that.

Ack also about the creation of Route Monitoring and Peer Down 
registries. There is another in-flight draft from John Scudder about 
splitting Init and Peer Up registries - is it the one you were thinking 
to? Upon reviewing LC feedback, we determined an interference between 
that draft and the Loc-Rib one; we decided, with the agreement of John, 
to let Loc-Rib draft go ahead first then work on the other one (and i 
did volunteer myself to help John with that).

Agree & ack your final remarks about properties of introducing optional 
TLVs in Route Monitoring messages. Would you like to see them mentioned 
in the draft?

Paolo

---

From: Paolo Lucente <[email-masked]>
Date: Mon, 13 Dec 2021 20:21:51 -0300

Hi Jeff,

Ack & yet again all agreed. I will add such a section to the draft.

Paolo

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Dec 2021 08:49:54 -0500

Paolo,

> On Dec 13, 2021, at 6:21 PM, Paolo Lucente <[email-masked]> wrote:
> 
> Agree & ack your final remarks about properties of introducing optional TLVs in Route Monitoring messages. Would you like to see them mentioned in the draft?

It's worth a sentence or two at most.  While it's one of those things that theoretically is obvious to the implementor, I've grown cynical over the years as to how "obvious" shows up in software. :-)

-- Jeff

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 15 Dec 2021 09:21:31 -0300

Hi Jeff,

Perfect, will do!

Paolo

On 14/12/21 10:49, Jeffrey Haas wrote:
> Paolo,
> 
>> On Dec 13, 2021, at 6:21 PM, Paolo Lucente <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Agree & ack your final remarks about properties of introducing 
>> optional TLVs in Route Monitoring messages. Would you like to see them 
>> mentioned in the draft?
> 
> It's worth a sentence or two at most.  While it's one of those things 
> that theoretically is obvious to the implementor, I've grown cynical 
> over the years as to how "obvious" shows up in software. :-)
> 
> -- Jeff
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 17 Dec 2021 16:35:15 +0100

Dear all,

WGLC now has been closed.

The chairs observed productive and fruitful discussion and convergence
towards a consensus, many thanks for all the input.

We will wait for the next version of the draft to be uploaded by the
authors, and then proceed with the sheperd write-up, and sending it to
IESG territory.

Kind regards,

Job & Chris