Here is my takeaway from this back-and-forth.
Several highly experienced routing folks have been looking at this draft in
detail and they are unable to come to a common understanding on what the draft
is trying to do. This alone indicates that the draft needs more work. Maybe the
authors have a clear idea on what they are trying to do but if expert readers
cannot determine what it is then clearly the draft needs further revision.
It also indicates to me that it is premature to determine whether the WG should
adopt this or not. If experienced folks reading the draft can’t easily
determine what the draft is trying to do, then it does not seem possible to
make a judgment as to whether the WG should adopt it.
Additional comments:
I tend to agree with Tony (and others) that the draft is aimed at advertising
some form of TE information – which is why I suggested even in my first post on
this thread that RFC 5316 seemed like it was enough. The problem that has been
exposed during the discussion is that RFC 5316 requires an AS number and in
this deployment case we may not have one. But perhaps this limitation can be
addressed by using the reserved AS #0 – a la RFC 7607. (BGP experts please
comment – I do not claim to be a BGP expert.)
There is then the additional sub-TLV defined in the document:
<snip>
Link Type: Define the type of the stub-link.
o 1: Numbered AS boundary link
o 2: Unnumbered AS boundary link
o 3: Loopback link
o 4: Vlan interface link
<end snip>
Ignoring the first two which were only added recently to try to address the
lack of an AS #:
What is a “loopback link”? I have no idea.
And while I know what a VLAN is, I have no idea why advertising that a link is
a VLAN is useful.
The draft provides no definition or clue as to the use case for this
information.
Finally, there is the relationship between this draft and
draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that
the latest version of the 5G draft only defines a new metric to be advertised
in Prefix Reachability advertisements, I have no idea what the relationship
between the two drafts may be.
What makes sense to me is NOT to adopt the draft at this time.
The authors can then spend time revising the draft, addressing the many issues
which have been raised, continue to get feedback from the WG, and at a future
time decide whether the revised version is suitable for WG adoption.
Les
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps <cho...@chopps.org>
Cc: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Aijun Wang
<wangai...@tsinghua.org.cn>; lsr-cha...@ietf.org; lsr <lsr@ietf.org>;
lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Chris,
This isn't the same as TE information which can be/is based dynamic values on
the router.
Are you sure? First, much of the TE information that we have distributed is
static (administrative group, SRLG, etc.). The dynamic part has been bandwidth
reservation. That still seems applicable to inter-AS stub links, even tho
Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I
understand the use case.
I'm pretty sure that it isn't even using the 2-way connectivity check. It's
literally just saying "Router A has a stub link B (i.e., it has the config
'isis passive' on it)".
As the draft has it, you’re correct. However, there’s all that undefined subTLV
space just begging for TE information. The current ‘link type’ information
seems somewhat pointless if it isn’t intended to be a item for TE consideration.
That infomration is already a part of an operators NMS b/c that NMS is what
generated that router's configuration and stuck it on that router in the first
place. That same NMS is going to be configuring the other router that would be
looking for that "stub link" information in the IGP. Unless I've mis-understood
something here, the proposoal is literally just pushing static configuration
details around inside the IGP.
Agreed 100%. But it’s also what we do today with much of the static TE
information. Again, there’s precedent.
T
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
