Bruno -
I think people have posted to this thread with different intentions.
Everyone agrees (I think...) that when MP-TLVs are sent for a given
TLV and not all routers in the network support MP for that TLV that
bad things will happen.
My posts have been to emphasize that the method of encoding MP-TLVs
requires no protocol extensions. This in no way conflicts with the
previous sentence.
Please see inline.
-----Original Message-----
From: bruno.decra...@orange.com <bruno.decra...@orange.com>
Sent: Monday, October 24, 2022 6:22 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Christian Hopps
<cho...@chopps.org>
Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; Tony Li
<tony...@tony.li>; Robert Raszuk <rob...@raszuk.net>; Henk Smit
<henk.i...@xs4all.nl>; lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-
01.txt
Les, all
Please see inline
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg
(ginsberg)
> Sent: Friday, October 7, 2022 1:35 AM
A bit late in the game. At least I've read all subsequent emails.
> To: Christian Hopps <cho...@chopps.org>
> Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; Tony Li
<tony...@tony.li>; Robert Raszuk <rob...@raszuk.net>; Henk Smit
<henk.i...@xs4all.nl>; 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
protocol extensions. We did not require a new sub-TLV, a new flag,
a
sequence number...we simply send additional information encoded
according to existing standards. This isn't "luck" - it is
following existing
standards.
>
> For implementations which do not process MP-TLVs correctly - why
does
this happen?
> On the receive side, they do not have the intelligence in their
implementation to do a merge.
> On the transmit side they do not have the intelligence to
generate multiple
TLVs.
- That protocol does not disallow the sending of multi-part (sub)
-TLVs is one
(good) thing.
- The encoding of MP-TLVs is another thing. (encoding detail IMHO,
although
I understand and agree that this is not one for existing
implementations)
- Another aspect is the behavior expected on the receiving side. If
that
behavior is not specified, that's out of spec/standard in the
general case,
especially as in this case different spec specified different
behaviors.
The following example (for sub-TLVs) show that there is at least
two
behaviors: "undefined", "merge"
"Where a receiving system has two copies of a capabilities TLV from
the same system that have different settings for a given
attribute,
the procedure used to choose which copy shall be used is
undefined."
https://datatracker.ietf.org/doc/html/rfc4971#section-3
"undefined" is different from "merge".
(Also note the terms "to choose which copy shall be used" could
even be
seen as excluding the possibility for a merge, at least in the mind
of the
authors)
[LES:] You have misinterpreted this excerpt from RFC 4971 (now RFC
7981).
Where a receiving system has two copies of an IS-IS Router CAPABILITY
TLV from the same system that have conflicting information for a
given sub-TLV, the procedure used to choose which copy shall be
used
is undefined.
The text is talking about what an implementation should do when the
same sub-TLV is received with two different values.
It is not talking about what should be done when MP is received for a
given TLV.
Then FlexAlgo defined "merge" for its FAD with the spec for it
"In such cases, the
FAD MAY be split into multiple such sub-TLVs and the content of
the
multiple FAD sub-TLVs combined to provide a complete FAD for the
Flex-Algorithm. In such a case, the fixed portion of the FAD
(see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given
Flex-
Algorithm from a given IS."
And also raised the question for sub-sub-TLVs, explicitly allowing
for any
behavior
" Any specification that introduces a new IS-IS FAD sub-sub-TLV
MUST
specify whether the FAD sub-TLV may appear multiple times in the
set
of FAD sub-TLVs for a given Flex-Algorithm from a given IS and
how to
handle them if multiple are allowed."
[LES:] I certainly agree that it is “better” if a specification is
explicit about whether MP is supported for a given TLV or not.
That does not mean, however, that we need to alter the encoding of
existing TLVs to support MP.
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-25#
section-6
Bottom lines:
- if the spec does not define the MP-TLV behavior on the receiving
side by
the spec, then -unless this is obvious and everyone agrees- this is
out of
spec. Let's not blame the receiver.
[LES:] Not sure where “blame” comes into it.
Again, my point is simply that existing encoding is sufficient.
What is needed is for implementations to be enhanced.
I do support more explicit specification – something we should pay
closer attention to as we write new documents.
I really do not see that you and I are disagreeing about anything.
Les
- I think we should distinguish the different aspects: allowed on
the sending
side, the encoding, the behavior on the receiving side, the need to
signal the
MP capability or not, the reaction to this signal (which can simply
be an alarm
message in log, with no IS-IS actions). I suspect that different
persons have
different sensibilities on each of those points and a sensibility
with one does
not equal to a sensibility with all. (let's not make any
disagreement bigger
than it is)
Thanks,
--Bruno
> You can propose protocol extensions (such as you have done) - but
it will
not change the need for implementations to enhance their
receive/generation logic - and it will not make it any easier for
implementations to do so. What it will do is to introduce(sic) an
interoperability problem because you will be requiring
implementations to
understand some new advertisement in order to send/receive MP-TLVs
successfully. This is what Peter's point is about i.e., we MUST NOT
break
existing working MP-TLV implementations by requiring protocol
extensions
in order to send MP-TLVs.
>
> As regards deployment controls, I have no problem with
recommending
that implementations provide ways to control the enablement of the
sending of MP-TLVs.
>
> Les
>
> > -----Original Message-----
> > From: Christian Hopps <cho...@chopps.org>
> > Sent: Thursday, October 6, 2022 3:28 PM
> > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> > Cc: Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak)
> > <ppse...@cisco.com>; Tony Li <tony...@tony.li>; Robert Raszuk
> > <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>;
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
> > standards. I don't want to argue about this, so perhaps we can
agree to
> > disagree.
> >
> > Thanks,
> > Chris.
> > [as wg-member]
> >
> >
> > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
> >
> > > Chris -
> > >
> > >> -----Original Message-----
> > >> From: Christian Hopps <cho...@chopps.org>
> > >> Sent: Thursday, October 6, 2022 1:36 PM
> > >> To: Peter Psenak (ppsenak) <ppse...@cisco.com>
> > >> Cc: Christian Hopps <cho...@chopps.org>; Tony Li <
tony...@tony.li>;
Les
> > >> Ginsberg (ginsberg) <ginsb...@cisco.com>; Robert Raszuk
> > >> <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>;
lsr@ietf.org
> > >> Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-
multi-tlv-
> > >> 01.txt
> > >>
> > >>
> > >> Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> writes:
> > >>
> > >> > Chris,
> > >> >
> > >> > On 06/10/2022 18:34, Christian Hopps wrote:
> > >> >> Peter Psenak <ppse...@cisco.com> 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 not suggest that to be the
case.
> > >> >> Are people not looking at the spreadsheet Tony put
together?
> > >> >> Which implicit multi-part TLVs are these "existing
implementations"
> > >> >> advertising that keep getting referred to? Please let's
work with
real
> > data
> > >> --
> > >> >> the spreadsheet shows a grand total of *0* TLVs that
could fall in
this
> > >> >> category.
> > >> >
> > >> > then the spreadsheet is incorrect.
> > >> >
> > >> > I know of implementation that can send and receive Multi
part TLVs
for
> > >> IPv4/IPv6
> > >> > (MT) IP Reach, (MT) Extended IS reachability and IS-IS
Router
> > CAPABILITY
> > >> TLV to
> > >> > start with.
> > >>
> > >> Do you know all of the implementations, and all of those
that don't? If
we
> > >> could publish that list then we presumably could explore
more simple
> > >> solutions. :)
> > >>
> > >> People keep talking about breaking deployed networks, but
that
assumes
> > >> there are functional networks with implicit MP-TLVs in them.
I am not
> > sure I
> > >> accept the assertion that these networks are truly
functional.
> > >>
> > >> AFAICT these networks are *lucky* to be working. There's no
document
> > to
> > >> point at, there's no bit to look at, there's literally
nothing to help an
> > operator
> > >> or their routers know if all the routers correctly receive
and process
these
> > >> implicit MP-TLVs. These networks are one network change
(even as
small
> > as
> > >> an interface up or down event) away from failing, or may
even be
failing
> > >> already but not yet in a noticeable way. This is the case
regardless of
what
> > >> type of bit or functionality this document provides.
> > >
> > > [LES:] I don't agree at all with your characterization.
> > >
> > > MP-TLVs (explicit or implicit) are not an extension of the
protocol - they
are
> > > completely consistent with the base operation of the
protocol. I have
> > always
> > > viewed lack of support for MP-TLVs as an implementation
limitation -
not a
> > gap
> > > in the protocol.
> > > Until relatively recently, there was no need to send MP-TLVs
for
> > > neighbors/prefixes and since it is far from trivial to
implement MP-TLV
> > support
> > > it is understandable why most(all?) implementations did not
include
such
> > support
> > > initially.
> > > But this does not mean that the protocol itself lacks the
support.
> > >
> > > Would it have been better if all RFCs were explicit about the
possibility
of
> > MP-TLVs? Sure - but hindsight is always easier than foresight.
> > > And even in those cases where MP-TLV support was explicitly
defined,
this
> > did
> > > not guarantee that all implementations had that support.
Vendors
make
> > decisions
> > > based on business as to how they spend their development
budget and
I
> > think we
> > > are both familiar with decisions to defer support for some
aspects of
the
> > > protocol until a stronger business case arises.
> > >
> > > Regarding existing networks, MP-TLVs are an aspect of scale
and
feature
> > support.
> > > If your deployment includes many flex-algos or a large number
of TE
> > attributes
> > > or other features which add to the information needing to be
advertised,
> > then
> > > MP-TLVs are required.
> > > Implementations which do not support MP-TLVs cannot be
deployed in
> > such environments - and it isn’t because of interoperability
issues - it is
> > because they do not support the scale/features required.
> > >
> > > As my employer has implementations which do support MP-TLVs,
I can
say
> > that we
> > > do not depend upon luck - but we do depend upon careful
planning.
We
> > work with
> > > our customers to ensure that the design of the network -
including the
> > > capabilities of the routers deployed - is considered.
> > >
> > >
> > > Les
> > >
> > >>
> > >> So while looking for a solution here, I think less weight
should be
placed
> > on
> > >> these "lucky networks". I'm not saying we should
intentionally break
> > them,
> > >> but they should also not count as "fully-functional" either.
> > >>
> > >> Thanks,
> > >> Chris.
> > >> [as wg-member]
> > >>
> > >>
> > >> >
> > >> > thanks,
> > >> > Peter
> > >> >> Thanks,
> > >> >> Chris.
> > >> >>
> > >> >>> I find the discussion about advertising supported
capabilities for
> > >> management
> > >> >>> purposes in IGPs interesting, but not specific, nor
directly related
to
> > the
> > >> >>> MP-TLV draft. Keeping the two separate would make a lot
of
sense.
> > >> >>>
> > >> >>>
> > >> >>> my 2c,
> > >> >>> Peter
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> On 05/10/2022 22:18, Tony Li wrote:
> > >> >>>> Les,
> > >> >>>>
> > >> >>>>> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg)
> > >> >>>>> <ginsberg=40cisco....@dmarc.ietf.org
> > >> >>>>> <mailto:ginsberg=40cisco....@dmarc.ietf.org>> 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 “feature supported” from the MP-TLV
draft
by
> > >> writing a
> > >> >>>>> separate draft on this proposal./*
> > >> >>>>> */This would allow the two pieces of work to progress
> > independently
> > >> – as they
> > >> >>>>> should./*
> > >> >>>>> *//*
> > >> >>>>> */This makes sense to me since the proposal to
advertise
feature
> > >> support is
> > >> >>>>> clearly not limited to MP-TLV and has no bearing on
how MP-
TLVs
> > are
> > >> >>>>> encoded./*
> > >> >>>>> *//*
> > >> >>>>> */Can we agree on this?/*
> > >> >>>> Sorry, I’m not on board with this. The two functions
would end
up
> > >> >>>> disconnected, all the way to the field.
> > >> >>>> T
> > >> >>>>
> > >> >>
> > >> >
> > >> > _______________________________________________
> > >> > 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
Orange Restricted
__________________________________________________________
__________________________________________________________
_____
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous
avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or
privileged
information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the sender
and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been
modified, changed or falsified.
Thank you.
