Aijun –
In my first post on this thread I indicated that I thought RFC 5316 is
sufficient for the use cases described in this draft. The subsequent lengthy
discussions on this thread has convinced me that RFC 5316 is indeed sufficient
and there is no need for this draft.
Along the way some issues discussed were:
The requirement of RFC 5316 that AS # be advertised. It is true that in some of
the use cases you won’t have an AS #, but this can be addressed by using one of
the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has
been resolved.
You continue to promote the need to use a new sub-TLV to advertise a link type
– but there is no demonstrated need for this nor any description of how such
information would be used. (I say this even after reading your responses below.)
You also continue to promote the need to use an RFC 5316 like TLV to advertise
the address of loopbacks – but again there is no need. The prefix associated
with a loopback is advertised in Prefix Reachability TLVs. That the prefix is
associated with a loopback is identified by the presence of the N flag in the
associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback
is identified by the RFC 7794 defined Router-ID sub-TLV(s).
As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft
only needs to advertise a new type of prefix metric – which is to be advertised
in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link
TLV defined in this draft should be removed. It suggests that a Link TLV is the
correct container for Prefix information – it is not.
There is no need for this draft – therefore it should not be adopted.
Les
From: Aijun Wang <[email protected]>
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Tony Li <[email protected]>; Christian Hopps <[email protected]>; Peter
Psenak <[email protected]>; [email protected]; lsr
<[email protected]>; [email protected]; [email protected]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi, Les:
Aijun Wang
China Telecom
On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>> wrote:
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.
[WAJ] I think most of them have gotten the key points of this draft along the
discussion and the reading of the related drafts. If they have still some
questions, we can discuss and explain on the list.
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.
[WAJ]This is the WG adoption call, not the WGLC. We certainly will update the
draft according to the comments from the WG. For adoption call, I think enough
interests is the main criteria for its adoption.
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.
[WAJ] I think Gyan has given the good summary for the use cases, or motivation
of this draft at
https://mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/.
I think if you read
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10,
you can get the key points of inter-AS use case.
Additional comments:
I tend to agree with Tony (and others) that the draft is aimed at advertising
some form of TE information –
[WAJ] Yes. The proposed TLV is one container and aim to convey the attributes
of the Stub-Link, also as stated in the draft name.
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.)
[WAJ]Reuse the existing TLVs need to update RFC5316, RFC5392 or other
potential RFC document , to relax the “MUST” rules that defined in these
documents. It will also influence the existing implementation and deployment.
Won’t it encounter more resistances?
And, as mentioned in your proposal, there still need some unproved bypass
methods to solve the situations that not the original scenarios of RFC5316 and
RFC5392.
Start from the clean state is the most efficient way. Isn’t it?
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.
[WAJ] Change it to “loopback interface” maybe more accurate. It is also one
kind of “Stub Link”, which there is no IGP neighbor on the other end(and
certainly no Remote AS, remote IPv4/IPv6 ASBR Router ID” that the RFC5316 and
RFC5392 required.)
We should extract such stub link from other types of stub link.
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.
[WAJ] VLAN interface is the logical interfaces that connected to servers that
are out side of the IGP domain. It is also different from the inter-AS link
that described in RFC5316 and RFC5392.
Some information that related to the attached severs or some policy to these
server can be applied to these kind stub link.
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.
[WAJ]No. It gives two kinds of proposals for the new metric. Please see
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7.
You may ignore it.
Actually, I prefer to advertising the edge server related information via the
Stub-Link TLV. The advantage of such approaches is that it can contain more
granular information, not only the aggregated cost.
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 <[email protected]<mailto:[email protected]>> On Behalf Of Tony
Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps <[email protected]<mailto:[email protected]>>
Cc: Peter Psenak
<[email protected]<mailto:[email protected]>>;
Aijun Wang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; lsr
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
