Hi authors,
Please find below WGLC comments on this document.
Major:
-----
"the provisioned MSD
of the router originating the Router Capability TLV. Node MSD is the
lowest MSD supported by the node of any interface and can be
provisioned in IS-IS instance."
I don't see the MSD as a provisioned value, but as a hardware capability. (Note
that as a network operator, I'd be happy to be able to provision this
capability without changing the hardware/software, but that has not been my
experience so far.)
Let's not put the burden on the network operator to configure this, while the
node should know the value better. (as a priori, in the absence this extension,
the node would report an error if instructed to push more labels than it is
capable of). Especially for WAN routers, when Line Card may be changed (e.g.
upgraded), so this would requires the network operator to keep track of all
Line card change and update the MSD capability accordingly.(in which case, it
may be just simpler to configure it directly on the controler, rather than
requiring IS-IS, OSPF, BGP-LS protocol extensions, plus new features on all
(involded) nodes)
-----
"the provisioned MSD of the interface associated with the link."
Please explicit whether the controller/reader need to use the MSD of the
incoming link or of the outgoing link.
If you believe this may be hardware dependent, this need to be signaled.
==============
Minor:
"MSD of type 1 (IANA Registry), called Base MSD, is used to signal the total
number of SIDs a node is capable of imposing,"
I think that this is limited to MPLS-SID. It would be good to state this
somewhere. e.g. :s/SIDs/MPLS SIDs
----
"MSD: Maximum SID Depth"
IMHO, I'm not a big fan of the term "depth".
I find that it can be mislead with RLD (Readable Label Depth Capability). I
don't feel that pushing N SID requires looking/going deep into the packet.
Looking at the surface of the incoming label looks enough.
Obviously, the comment is late.
Related comment: I don't find the definition to be explicit enough. e.g. You
now need to define what "SID depth" is or provide or reference.
-----
1.1.1. Terminology
Given that the term are very very briefly explained, may be adding a reference
to the RFC defining/explaining them.
---
"In order, for BGP-LS to signal MSD for
the all nodes and links in the network MSD is relevant, MSD
capabilites SHOULD be distributed to every IS-IS router in the
network."
I don't think that the "SHOULD" is related to interoperability. Hence a
"should" is probably enough.
-----
"Value field consists of a 1 octet sub-type (IANA Registry) and 1 octet
value."
I don't see the value (sic) to hard code the legnth of the "sub-value":
- this restrict the use of future MSD Sub-type Codepoints
- if we hard code it, there is no use of the "length" field. (and "Length is
variable " becomes not true)
-----
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type and Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Value field consists of a 1 octet sub-type (IANA Registry) and 1
octet value."
Text and figure do not match: the value field is either 'Sub-Type and value" as
per the text, or just "value without the Sub-type" as per the figure.
*2 (link and node MSD)
---
§ MSD Advertisement
" Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
of the router originating the corresponding TLV's 22, 23, 141, 222,
and 223. Link MSD is a number in the range of 0-254. 0 represents
lack of the ability to impose MSD stack of any depth; any other value
represents that of the particular link MSD value."
It's not clear whether the text related to the MSD value is specific to the
Sub-type 1 or to the whole Link MSD Advertisment. (i.e. would restrict the
usage of future sub-Types). May be using two sections would help: one defining
the Link MSD, one defining Sub-type 1. In which case the last paragraph of the
introduction may be move to this new sub-type 1 section.
*2 (link and node MSD)
-----
" Other Sub-types other than defined above are reserved for future extensions.
This sub-TLV is optional."
It's not clear whether you mean this sub-TLV 1, or any sub-TLV n, or the
presence of a sub-TLV.
----
"the ability to impose MSD stack of any depth"
Were are not imposing an "MSD stack", but SID stack. Actually the SR
architecture tends to use the term "list of segments" (or "ordered list of
segments")
----
" This document describes a mechanism to signal Segment Routing MSD
supported at node and/or link granularity through IS-IS LSPs and does
not introduce any new security issues."
Improved fingerprinting capability would be one. Which may help target the
right vulnerability of the advertising router.
==============
Nits:
"supported by a node at node and/or link granularity"
May be NEW: supported by a node or link
"In order, for BGP-LS to signal MSD for
the all nodes and links in the network MSD is relevant, MSD
capabilites SHOULD be distributed to every IS-IS router in the
network."
In my understandind:
:s/the all nodes/all the nodes
:s/distributed to every IS-IS router/advertised by every IS-IS router
---
"A new sub-TLV within the body of IS-IS Router Capability TLV
[RFC7981], Node MSD sub-TLV is defined to carry the provisioned MSD
of the router originating the Router Capability TLV. ""
May be the following would be easier to read
A new sub-TLV "Node MSD sub-TLV" is defined within the body of IS-IS Router
Capability TLV
[RFC7981], to carry the provisioned MSD
of the router originating the Router Capability TLV.
-----
"Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD
of the router originating the corresponding TLV's 22, 23, 141, 222,
and 223. Link MSD is a number in the range of 0-254."
Please use two paragraphs. One for "Sub-type" field, one for "MSD value" field.
-----
"0 represents lack of the ability to impose MSD stack of any depth "
May be NEW: "0 represents lack of the ability to impose any SID"
----
"Maximum MSD"
NEW: MSD
("M" already stands for Maximum)
Multiple times in the doc, with "Maximum" or "maximum"
----
The document has 2 "Terminology" sections. You should probably merge them.
Thanks
Regards,
--Bruno
> -----Original Message-----
> From: Isis-wg [mailto:[email protected]] On Behalf Of Christian Hopps
> Sent: Wednesday, December 20, 2017 9:33 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: [Isis-wg] WG Last Call for draft-ietf-isis-segment-routing-msd-07
>
>
> The authors have asked for and we are starting a WG Last Call on
>
> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
>
> which will last an extended 4 weeks to allow for year-end PTO patterns.
>
> An IPR statement exists:
>
>
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-isis-segment-routing-msd
>
> Authors please reply to the list indicating whether you are aware of any
> *new* IPR.
>
> Thanks,
> Chris.
>
> _______________________________________________
> Isis-wg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/isis-wg
_________________________________________________________________________________________________________________________
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.
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
