1)I see you have now defined a TLV for hellos to advertise the capability to
support ASH
>From Section 5.1:
" The ASH Capability TLV is a zero-length TLV (type TBD) included in IIH PDUs."
I ask that you consider defining something more generic/extensible so that we
can use the same TLV codepoint to advertise other per link capabilities in the
future (yes - I have some in mind...)
The TLV would be formatted analogous to the IPv4/IPv6 Extended Reachability
Attribute Flags sub-TLV defined in RFC 7794 - but would be a TLV (not a
sub-TLV) only to be sent in hellos.
Link Capability TLV
Type - TBD
Length - Number of octets in the Value field
Value - Extensible bit string
We create a registry to define the bit assignments. You get the first bit (or
perhaps two bits if you want to advertise ASH support per level).
This is more flexible and forward looking.
2)The context for this draft is high scale. Section 9 states:
" we focus on realistic scenarios on the order of 50,000 nodes and 1 million
fragments. "
Given that, I think it likely that you will encounter a case where some nodes
need to advertise more than 256 LSPs at a given level.
The defined solution for that is RFC 7356 - which defines flooding scoped PDUs
- including FS-LSPs and FS-CSNPs and FS-PSNPs.
Given that your current choice is to define new PDU types, you will then need
to define new FS-CSNP/FS-PSNP PDUs to support such deployments.
NOTE: The same TLV format for advertising Node Range Hash Entries will still
work.
I think this should be discussed in the draft.
Which brings me to my next comment...
3)You currently choose to define new PDU types for CSNPs/PSNPs to advertise ASH
information - but this is not necessary.
The existing CSNP/PSNP formats are fully compatible and can support the
existing LSP entry TLVs and the new Hash Entry TLVs in the same PDU so long as
order is preserved in CSNPs.
Given that the finest granularity of ASH TLVs is all the LSPs from a single
node, it is obvious that the use of LSP entry TLVs is still needed to
synchronize LSPDBs.
As one of the primary goals of the extensions of this draft is to reduce the
number of PDUs, being able to combine LSP Entry TLVs and ASH TLVs in the same
PDU has the potential to reduce the number of PDUs required even further.
In addition, using existing PDUs would eliminate the need to define additional
PDU types to address the RFC 7356 cases.
I ask that you give this idea some thought.
Thanx.
Les
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
