erg (ginsberg) ; Christian Hopps
>
>>
>
>> Cc: Peter Psenak (ppsenak) ; Tony Li
>
>> ; Robert Raszuk ; Henk Smit
>
>> ; lsr@ietf.org
>
>> Subject: RE: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-
>
>> 01.txt
>
Hopps ;
> Peter Psenak (ppsenak) ; Tony Li ;
> Robert Raszuk ; Henk Smit ;
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
> [as wg-member]
>
> Hi Les,
>
> I want to highlight a particular thing your saying
sage-
From: bruno.decra...@orange.com
Sent: Monday, October 24, 2022 6:22 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps
Cc: Peter Psenak (ppsenak) ; Tony Li
; Robert Raszuk ; Henk Smit
; lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi
;
> Cc: Peter Psenak (ppsenak) ; Tony Li
> ; Robert Raszuk ; Henk Smit
> ; lsr@ietf.org
> Subject: RE: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
> Les, all
>
> Please see inline
>
> > From: Lsr mailto:lsr-boun...@
it ;
> lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
> Chris -
>
> Not sure what SE means but...one more significant point.
>
> Multiple implementations have successfully deployed MP-TLV without any
> protoc
Li ; Peter
Psenak (ppsenak) ; Robert Raszuk ;
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Christian Hopps writes:
>>> I simply turned your question around and asked: should conforming
>>
>>> implementations be
Christian Hopps writes:
I simply turned your question around and asked: should conforming
implementations be penalized?
[LES:] Are you claiming that the absence of an explicit statement
regarding support of MP for a given TLV is equivalent to a
prohibition against sending them (which fai
tian Hopps
Sent: Saturday, October 8, 2022 2:48 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Tony Li ;
Peter
Psenak (ppsenak) ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-
01.txt
I simply t
2 2:48 PM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; Tony Li ; Peter
> Psenak (ppsenak) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
>
> I simply turned yo
Psenak (ppsenak) ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt
"Les Ginsberg (ginsberg)" writes:
> Tony -
>
>
>>
>> Your summarization is incorrect.
>>
>> The proposal is t
advertised.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Friday, October 7, 2022 4:17 PM
> To: Les Ginsberg (ginsberg)
> Cc: Tony Li ; Christian Hopps ; Peter
> Psenak (ppsenak) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr]
"Les Ginsberg (ginsberg)" writes:
Tony -
Your summarization is incorrect.
The proposal is to advertise a advisory message that indicates that a node is
ready to receive MP-TLVs. It prohibits nothing.
[LES:] That is what you are proposing - but others in the thread have proposed
other i
Hi Acee,
> You realize the latest version still has the statement:
>
>If all routers in an area advertise the Multi-part TLV Capability a
>node MAY advertise multi-part TLVs to increase space for payload
>values, unless otherwise specified by the TLV.
>
> At a minimum, the draft s
Hi Tony,
From: Lsr on behalf of Tony Li
Date: Friday, October 7, 2022 at 11:21 AM
To: "Les Ginsberg (ginsberg)"
Cc: Christian Hopps , "Peter Psenak (ppsenak)"
, Robert Raszuk , Henk Smit
, "lsr@ietf.org"
Subject: Re: [Lsr] New Version Notification for
draft
Les,
> On Oct 7, 2022, at 8:16 AM, Les Ginsberg (ginsberg)
> wrote:
>
> What I am trying to highlight is that the existing implementations of MP-TLVs
> for the "implicit" cases should not be penalized for sending MP-TLVs that are
> encoded consistent with how MP-TLVs for the "explicit" cases
Tony -
>
> Your summarization is incorrect.
>
> The proposal is to advertise a advisory message that indicates that a node is
> ready to receive MP-TLVs. It prohibits nothing.
[LES:] That is what you are proposing - but others in the thread have proposed
other ideas. For example, in an earlie
> On Oct 6, 2022, at 1:56 PM, Christian Hopps wrote:
>
> Tony I think you may have interpreted these differently?
Ayup. As stated, I am human. I blew it. Mea culpa.
I will rename the current columns and start over. Contributors still welcome.
T
_
Les,
> On Oct 6, 2022, at 7:22 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Chris -
>
> Not trying to convince you of anything - just want to step back and summarize
> where we are.
>
> MP-TLV support has been explicitly allowed in multiple cases - and in these
> cases no additional signalin
Sent: Thursday, October 6, 2022 4:59 PM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
>
> Se
:28 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Peter Psenak (ppsenak)
; Tony Li ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt
It sounds like you're talking about networks defined to work by SE not by
st
22 3:28 PM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
>
> It sounds like you're talki
gt; > From: Christian Hopps
> > Sent: Thursday, October 6, 2022 1:36 PM
> > To: Peter Psenak (ppsenak)
> > Cc: Christian Hopps ; Tony Li ; Les
> > Ginsberg (ginsberg) ; Robert Raszuk
> > ; Henk Smit ; lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification f
hristian Hopps
Sent: Thursday, October 6, 2022 1:36 PM
To: Peter Psenak (ppsenak)
Cc: Christian Hopps ; Tony Li ; Les
Ginsberg (ginsberg) ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt
Peter Psenak writes:
> Chri
Chris -
> -Original Message-
> From: Christian Hopps
> Sent: Thursday, October 6, 2022 1:36 PM
> To: Peter Psenak (ppsenak)
> Cc: Christian Hopps ; Tony Li ; Les
> Ginsberg (ginsberg) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Versio
nsberg)
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
>
> "Les Ginsberg (ginsberg)" writes:
>
> >
> >
aszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-
01.txt
Peter Psenak writes:
> Tony, Les,
>
> I believe we can all agree that we do not want to change the
behavior of
> existing im
Peter Psenak writes:
Chris,
On 06/10/2022 18:34, Christian Hopps wrote:
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other route
gt; Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
>
>
> Peter Psenak mailto:ppse...@cisco.com>> writes:
>
> > Tony, Les,
> >
> > I believe we can all agree that we do not want to change the behavior of
> > exis
Gentlebeings,
The spreadsheet is NOT documenting implementations. It’s documenting what I
could find in the relevant specifications.
Tony
> On Oct 6, 2022, at 9:51 AM, Peter Psenak
> wrote:
>
> Chris,
>
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak writes:
>>> Tony, Les,
Chris,
On 06/10/2022 18:34, Christian Hopps wrote:
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other routers - it would break exis
Peter Psenak writes:
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the advertisements of the
MP-capability from other routers - it would break existing networks. Even the
text in the MP-TLV draft does
Hi Chris,
> On Oct 5, 2022, at 1:26 PM, Christian Hopps wrote:
>
> That is great news b/c it means we can fix those 3 unpublished TLV to be
> explicit multi-part. After fixing those 3 we are in a much friendly place of
> defining only future behavior/standard requirements without concern of
Tony, Les,
I believe we can all agree that we do not want to change the behavior of
existing implementations that support MP-TLVs based on the
advertisements of the MP-capability from other routers - it would break
existing networks. Even the text in the MP-TLV draft does not suggest
that to
runo.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> > where implementations decide when to apply configuration that has been
> accept
...@tony.li>>; Christian Hopps
mailto:cho...@chopps.org>>; Henk Smit
mailto:henk.i...@xs4all.nl>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
Yes you have correctly understood my last point.
So
mentation.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk
> *Sent:* Wednesday, October 5, 2022 1:41 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Noti
.
Les
From: Robert Raszuk
Sent: Wednesday, October 5, 2022 1:41 PM
To: Les Ginsberg (ginsberg)
Cc: bruno.decra...@orange.com; Tony Li ; Christian Hopps
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
Yes you have correctly
"Les Ginsberg (ginsberg)" writes:
RFC3787 which was published 1 month prior to RFC3784 which RFC5305
replaced.
"5. Migration from Narrow Metrics to Wide . . ."
[LES:] Indeed - RFC 3787 - quite a useful document.
Note this section was based on input from actual implementations. So folks i
>
> RFC3787 which was published 1 month prior to RFC3784 which RFC5305
> replaced.
>
> "5. Migration from Narrow Metrics to Wide . . ."
[LES:] Indeed - RFC 3787 - quite a useful document.
Note this section was based on input from actual implementations. So folks
implemented migration strategi
Tony Li writes:
Hi all,
On Oct 3, 2022, at 8:37 AM, Christian Hopps wrote:
[As wg-member]
I think the draft should include a table of all top level TLVS as rows and for
columns we have
- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
- "Explicit Single TLV O
Raszuk
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [L
@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Just to add and expand to your point Les ...
The concept of "forward referencing" used in some OSes explicitly permit
configuration of elements not even present on the box or in the system ahea
"Les Ginsberg (ginsberg)" writes:
Chris -
Please see inline.
[...]
> MP-TLVs are not sent just because an implementation supports them.
> They are sent because the current configuration requires them.
The SW also has the option to alert the operator that their configuration is
not suppo
Les,
> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg)
> wrote:
>
> [LES:] It is clear that we have different opinions on this – and there are
> multiple folks on both sides of this discussion.
> What I would hope we can agree on is to separate the discussion of adding
> advertisement of
Tony -
From: Tony Li On Behalf Of Tony Li
Sent: Wednesday, October 5, 2022 7:57 AM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Robert Raszuk ;
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
Using the protocol to
> "Les Ginsberg (ginsberg)" writes:
>
> > Chris -
> >
> >
> >
> > Inline.
> >
> >
> >
> >> -----Original Message-----
> >
> >> From: Christian Hopps
> >
> >> Sent: Monday, October 3, 2022 5:5
Hi Les,
> In this thread we talk about MP-TLV support – but this is less than precise.
> What we are really talking about is MP-TLV support for specific TLVs. So this
> now requires per/TLV advertisement.
No, it does not. As you yourself verbally agreed, we are referring to the
class of TL
k functional.
>
>
>
> I am quite concerned that this is something that “sounds good” but in
> practice adds little value – yet places significant demands on
> implementations.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr *On Behalf Of *
> bruno.dec
rations.
Thank you,
Regards,
--Bruno
Orange Restricted
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les
Ginsberg (ginsberg)
Sent: Tuesday, October 4, 2022 7:35 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; Robert
Raszuk mailto:rob
Hi Les,
> Using the protocol to send what is best described as some subset of a PICS
> means that we propose to use the IGP flooding mechanism to send static
> information which the protocol itself cannot (and should not) use in its
> operation. This consumes space, bandwidth, gets periodical
Hi all,
> On Oct 3, 2022, at 8:37 AM, Christian Hopps wrote:
>
>
> [As wg-member]
>
> I think the draft should include a table of all top level TLVS as rows and
> for columns we have
>
> - "Implicit Single TLV Only" (e.g., no key info)
> - "Implicit Multi-TLV Only"
> - "Explicit Single TLV
berg (ginsberg)" writes:
Chris -
Inline.
-Original Message-
From: Christian Hopps
Sent: Monday, October 3, 2022 5:52 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Robert Raszuk
; Tony Li ; Henk Smit
; lsr@ietf.org
Subject: Re: [Lsr] New Version Notifi
Hi Bruno,
> To clarify, are we talking about:
> - different nodes in the flooding domain having a different understanding of
> the LSDB content
We are trying to prevent that. We are trying to figure out how we can relax
the cases where the specifications imply, but do not clearly state that
be
possible to reduce the number of copies in the network.
Thoughts??
Les
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf
Of Tony Li
Sent: Tuesday, October 4, 2022 9:16 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chop
@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
Folks may well complain that management tools are not as good as they need to
be, but trying to compensate for this by adding management information into the
protocol itself isn’t a good solution
Hi all,
> On Oct 3, 2022, at 8:37 AM, Christian Hopps wrote:
>
>
> [As wg-member]
>
> I think the draft should include a table of all top level TLVS as rows and
> for columns we have
>
> - "Implicit Single TLV Only" (e.g., no key info)
> - "Implicit Multi-TLV Only"
> - "Explicit Single TLV
Tony & Les,
I do think we should be signalling node's enabled/active capabilities
including the ability to process various types of encoded PDUs in band.
I do not believe in live management planes. Sure getting stats, config push
etc ... it is all doable and deployed. But dynamic configuration ba
Hi Les,
> Folks may well complain that management tools are not as good as they need to
> be, but trying to compensate for this by adding management information into
> the protocol itself isn’t a good solution.
It is not a good solution. But it is the only practical solution available. At
sca
Chris -
Inline.
> -Original Message-
> From: Christian Hopps
> Sent: Monday, October 3, 2022 5:52 PM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; Robert Raszuk
> ; Tony Li ; Henk Smit
> ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notific
tification for
draft-pkaneria-lsr-multi-tlv-01.txt
[As wg-member]
I think the draft should include a table of all top level TLVS as rows and for
columns we have
- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
- "Explicit Single TLV Only&qu
Chris -
> -Original Message-
> From: Christian Hopps
> Sent: Monday, October 3, 2022 8:37 AM
> To: Les Ginsberg (ginsberg)
> Cc: Robert Raszuk ; Tony Li ; Henk Smit
> ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr
[As wg-member]
I think the draft should include a table of all top level TLVS as rows and for
columns we have
- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
- "Explicit Single TLV Only"
- "Explicit Multi-TLV-Allowed"
This draft then would *explicitly* cover the e
Henk Smit
mailto:henk.i...@xs4all.nl>>; lsr
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
> 2) Applicability of advertising what features an implementation supports
> extends
> to much more than just multi-tlv s
ulti-tlv - which I think is both useful
> and non-controversial - can proceed.
>
> I hope this is something on which we can easily agree - even if we do not
> agree on whether feature support should/should not be advertised in the
> LSPDB.
>
> A few more comments inli
something very new.
Les
From: Robert Raszuk
Sent: Thursday, September 22, 2022 12:38 PM
To: Les Ginsberg (ginsberg)
Cc: Tony Li ; Henk Smit ; lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les,
> 2) Applicability of advertising what features
r feature support should/should not be advertised in the
> LSPDB.
>
> A few more comments inline.
>
> > -Original Message-
> > From: Lsr On Behalf Of Tony Li
> > Sent: Tuesday, September 13, 2022 1:44 PM
> > To: Henk Smit
> > Cc: lsr
&
support should/should not be advertised in the LSPDB.
A few more comments inline.
> -Original Message-
> From: Lsr On Behalf Of Tony Li
> Sent: Tuesday, September 13, 2022 1:44 PM
> To: Henk Smit
> Cc: lsr
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-l
Hi Henk,
>> Yes, I'm advocate for putting things elsewhere, but that proposal has
>> met with crickets. You don't get it both ways: no capabilities in the
>> protocol and nowhere else does not work.
>
> I'm not sure I know what you are talking about.
> Did you write a draft?
I did. You don’t
Hi Tony,
> Yes, I'm advocate for putting things elsewhere, but that proposal has
> met with crickets. You don't get it both ways: no capabilities in the
> protocol and nowhere else does not work.
I'm not sure I know what you are talking about.
Did you write a draft?
> Because the thought of tr
Hi Henk,
> My point was: multipart TLVs exist today, before the introduction of the
> capability advertisement. So when you look at a LSPDB, you still don't know
> for
> sure which routers support multipart TLVs. Some might, but don't advertise it.
> Because their software was written before the
Hi Tony,
> Some exist today. There are many TLVs where they have never been specified.
My point was: multipart TLVs exist today, before the introduction of the
capability advertisement. So when you look at a LSPDB, you still don't know for
sure which routers support multipart TLVs. Some might, bu
Hi Henk,
> > If we want to introduce MP-TLVs, that change would warrant the existence of
> > the flag.
>
> Multipart TLVs already exist today.
Some exist today. There are many TLVs where they have never been specified.
> As discussed here, after introducing a "software capability TLV", if
Hi Tony,
> If we want to introduce MP-TLVs, that change would warrant the existence of
> the flag.
Multipart TLVs already exist today.
As discussed here, after introducing a "software capability TLV", if a router
doesn't
advertise any of those new capabilities, we still don't know
Date: Thursday, August 25, 2022 at 12:18 PM
To: "Acee Lindem (acee)"
Cc: Gunter Van de Velde , Tony Li
, lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
All,
I am actually finding this capability useful. If for nothing else then to help
th
25, 2022 9:17 AM
To: Acee Lindem (acee)
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ;
Tony Li ; lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
All,
I am actually finding this capability useful. If for nothing else then to help
the operator to see
(Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> Cc: lsr
> Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
> Hi Gunter,
>
> I am having troubles understanding the value of ‘The Multi-part TLV
>
e: GV>
>
> From: Tony Li On Behalf Of Tony Li
> Sent: Wednesday, August 24, 2022 5:26 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_ve...@nokia.com>
> Cc: lsr
> Subject: Re: [Lsr] New Version Notification for
> draft-pkan
okia -
BE/Antwerp)"
wrote:
Inline: GV>
From: Tony Li On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi
Inline: GV>
From: Tony Li On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 5:26 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Gunter,
I am having troubles understanding the value of ‘
: Wednesday, August 24, 2022 1:34 PM
To: Les Ginsberg (ginsberg)
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ;
lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
MP-TLVs are sent by routers not simply because they have the ability to do so,
but because the
> MP-TLVs are sent by routers not simply because they have the ability to do
> so, but because the configuration requires them to send more information
> about an object than will fit in a single TLV. This means that any attempt to
> suppress generation of a MP-TLV based on the current capabilit
24, 2022 8:26 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: lsr
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Gunter,
I am having troubles understanding the value of ‘The Multi-part TLV Capability’
flag.
What would break if ‘Multi-part TLV
Tony
On Wed, Aug 24, 2022 at 11:26 AM Tony Li wrote:
>
> Hi Gunter,
>
> I am having troubles understanding the value of ‘The Multi-part TLV
> Capability’ flag.
>
> What would break if ‘*Multi-part TLV Capability*’ flag would not exist?
>
>
>
> A system that supported MP-TLVs would not be able to
Hi Gunter,
> I am having troubles understanding the value of ‘The Multi-part TLV
> Capability’ flag.
> What would break if ‘Multi-part TLV Capability’ flag would not exist?
A system that supported MP-TLVs would not be able to determine that there were
other systems in the area that did not su
Hi Hannes,
Thank you. Not everyone is yet in agreement with this, so we are discussing
correct wording.
T
> On Jul 5, 2022, at 7:00 AM, Hannes Gredler
> wrote:
>
> Hi Tony, et al,
>
> minor nit:
>
> ---
> As an example, consider the Extended IS Reachability TLV (type 22).
> A neighb
Bruno,
Thank you, the authors are discussing this.
T
> On Jul 5, 2022, at 4:52 AM,
> wrote:
>
> Hi Tony,
>
> Thanks the update.
> 1 clarification question on §5 (new capability)
> « If all routers in an area advertise the Multi-part TLV Capability a node
> MAY advertise multi-part TLVs
86 matches
Mail list logo
