Hi Alia,
Thank you for your comments. I certainly don’t agree with all of them but will
allow the authors to respond. For example, I believe the concept of an SRMS to
be well-undestood and defined in the SPRING WG. Perhaps we just need the right
references. The one comment I will respond to is the one regarding the author
limit. Note that this is covered in the Shepherd’s Write-Up. I’ve excerpted it
here:
The document does have seven authors. All the authors have
played in active role in the development of the standard including
periodic segment routing design team meetings. All of the authors
have responded promptly to IPR polls. At least three of the
authors represented independent implementations. There is
absolutely no reason to relegate any of them to contributor status.
I’ll be on vacation the remainder of this week but will touch base with the
authors on Monday.
Thanks,
Acee
From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Tuesday, May 30, 2017 at 10:35 PM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>,
"draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>"
<draft-ietf-ospf-segment-routing-extensi...@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensi...@ietf.org>>,
"Alvaro Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>,
Deborah Brungard <db3...@att.com<mailto:db3...@att.com>>
Cc: "spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>"
<spring-cha...@tools.ietf.org<mailto:spring-cha...@tools.ietf.org>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-16
I forgot to point out that the Security Considerations sections is not close to
sufficient.
At a minimum, it needs to refer to the existing security work for OSPF,
indicate what new
information is being advertised, and discuss if there are any privacy or
security concerns
around them. I don't personally see any - except for, perhaps, the increased
ability to fingerprint
the type and version of routers with these advertisements.
Regards,
Alia
On Tue, May 30, 2017 at 10:05 PM, Alia Atlas
<akat...@gmail.com<mailto:akat...@gmail.com>> wrote:
As is customary, I have done my AD review of
draft-ietf-ospf-segment-routing-extensions-16 once publication has been
requested. First, I would like to thank the editors & many authors, Peter,
Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the work that they have put in
so far and the remaining work that is greatly needed.
While there are a great many issues to be handled, they fall primarily into
three categories. The first is simply not going through and tightening up the
details; for example, stating that the length of a TLV is variable provides no
meaning. The second is that the technical documents from SPRING that this
draft depends on do not adequately describe the use of the advertised
information (SID/Label Binding TLV) or some of the concepts (e.g. SR Mapping
Server). The third is a more common set of handling error cases and adding
clarity to the intended behavior. I do not see issues with the encodings but I
do see fragility with the unstated assumptions and behaviors. The draft
describes encodings, but very little of the handling, behaviors, or meaning -
and the references do not provide adequate detail.
I have spent all day (and evening) doing this review and I am quite
disappointed and concerned about the document. I would strongly recommend
having sharing the next WGLC with the SPRING working group; perhaps more eyes
will help with the discrepancies.
I have not yet decided what to do about the "early" IANA allocation - which has
now existed for this draft for 3 years. I do know that there are
implementations,
but I am currently seeing the failure of this work to successfully complete as
an example of an issue with providing early allocations.
MAJOR ISSUES:
1) This draft has 7 authors. The limit for authors & editors is 5, as is
clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well over a
decade, unless there are extraordinary circumstances. Is there a reason to not
simply list the active editor and move the others to contributors? One of the
authors is already listed there. I regret that failure to deal earlier with
this long-standing IETF policy will be delaying progressing the draft.
2) This expired individual
draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as Informative
- but IS ACTUALLY NORMATIVE since it DEFINES the
"M-bit - When the bit is set, the binding represents a mirroring context as
defined in [I-D.minto-rsvp-lsp-egress-fast-protection]." Unfortunately, when I
look there for the definition of a mirroring context, it doesn't exists.
3) The following Informative references expired several years ago and - being
individual drafts - do not appear to convey the SPRING or TEAS WG consensus.
a) draft-filsfils-spring-segment-routing-ldp-interop-03 was replaced with
draft-ietf-spring-segment-routing-ldp-interop-07 and there are considerable
differences.
b) It is unclear what happened to
draft-filsfils-spring-segment-routing-use-cases-01, but I do not see any
successor - or reason for this individual draft to explain the OSPFv2
extensions more than work from the SPRING WG.
4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the
SR-Algorithm TLV? What is the expected behavior and assumptions by the
receiver?
5) Sec 3.4: What happens if an SRMS Preference TLV is advertised without an
SR-Algorithm TLV in the same scope? I see that it says "For the purpose of the
SRMS Preference Sub-TLV advertisement, AS scope flooding is required." but also
provides for area scope flooding. Some words clarifying the expected behavior
would be useful.
6) Sec 5: "In such case, MPLS EXP bits of the Prefix-SID are not preserved for
the final destination (the Prefix-SID being removed)." I am quite startled to
see an assumption that MPLS Pipe mode is being forced as part of specifying PHP
mode! This will also break any ECN or 3-color marking that has affected the
MPLS EXP bits. I would like to see and understand a clear justification for
why short-pipe mode is being required instead of Uniform (or up to
implementation/configuration.). Basically, this sentence means that transport
considerations are a necessary section - which is completely inappropriate in
an IGP draft.
7) Sec 6: This section defines the SID/Label Binding sub-TLV - which appears to
be a way to advertise an explicit path - and has a SID/Label by which the path
can be entered. How and what state is set up by the sending router to create
the indicated segment is completely unclear. I have hunted through
draft-ietf-spring-segment-routing, draft-ietf-spring-segment-routing-mpls, and
draft-ietf-spring-segment-routing-ldp-interop, RFC7855, and
draft-ietf-isis-segment-routing-extensions. As far as I can tell, NONE of
them clearly describe the details of where and why this advertising is needed.
Obviously, this mechanism does allow the potential shortening of the MPLS label
stack at the cost of advertising multi-hop explicit path segments across the
entire area or AS. There MUST be a normative description of what the sending
router will do when a packet is received with the specified label.
8) Sec 4: "The Segment Routing Mapping Server, which is described in
[I-D.filsfils-spring-segment-routing-ldp-interop]" Where precisely is an SRMS
and its behavior/role actually defined?
draft-ietf-spring-segment-routing-ldp-interop-07 claims:"SR to LDP interworking
requires a SRMS as defined in [I-D.ietf-isis-segment-routing-extensions]." but
that wouldn't be appropriate, of course, and it isn't there either!
draft-ietf-spring-conflict-resolution-04 talks about SRMS, but doesn't define
it. draft-ietf-spring-segment-routing-11 mentions in Sec 3.5.1 that "A
Remote-Binding SID S advertised by the mapping server M" and refers to the
ldp-interop draft for further details - but obviously not about an SRMS.
Minor Issues:
1) In Sec 3.1, it says: "The SR-Algorithm TLV is optional. It MUST only be
advertised once in the Router Information Opaque LSA. If the SID/Label Range
TLV, as defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST
also be advertised." Please provide a pointer in the text to the behavior for
a receiving router if one or both of these are violated? For the requirement
to advertise the SR-Algorithm TLV, please clarify that this is in the same RI
LSA as the SID/Label Range TLV was advertised & with the same scope. What does
it mean, in terms of the receiving router, to determine that the sending router
supports SR or not - given the possibility of receiving other SR-related TLVS
in an RI LSA without getting an SR-Algorithm TLV?
2) Sec 3.1: The SR-Algorithm TLV simply defines "Length: Variable". Given that
advertising Algorithm 0 is required, I'm fairly sure that the Length has to be
a minimum of 1 - and, to prevent overrun & weird issues, let's have a
reasonable maximum (for instance, 24) too. It wouldn't hurt to remind readers
that the length is just that of the value field - though experienced OSPF
implementers will know that.
3) Sec 3.1 & Sec 3.2 & Sec 3.3: "For the purpose of SR-Algorithm TLV
advertisement, area scope flooding is required." and "For the purpose of
SID/Label Range TLV advertisement, area scope flooding is required." and "For
the purpose of SR Local Block Sub-TLV TLV advertisement, area scope flooding is
required." Please capitalize REQUIRED as per RFC 2119. Otherwise, please
explain behavior when area scope isn't used.
4) Sec 3.2: The SID/Label Range TLV doesn't indicate that include a SID/Label
sub-TLV is required - but I don't understand how it could be interpreted
otherwise; nor does it indicate what to do if there are multiple SID/Label
sub-TLVs included in a single SID/Label Range TLV. Again "Length" is just
defined as variable. In this case, it clearly can't be less than 11 (probably
12, assuming padding to the 32-bit boundary). It would be useful to have an
upper-bound on length, but at least here I can see the argument that meaningful
flexibility is provided for.
5) SID index is used without introduction in Sec 3.2. It isn't defined in the
terminology of draft-ietf-spring-segment-routing-11 and the other uses of it in
this document aren't enough to clearly define it. Please add at least a
description of its meaning before use - in a terminology section, if necessary.
6) Sec 3.2: "The originating router advertises the following ranges:
Range 1: [100, 199]
Range 2: [1000, 1099]
Range 3: [500, 599]"
Please turn this into the information actually advertised - i.e.
Range 1: Range Size: 100 SID/Label sub-TLV: 100 => meaning [100, 199]
etc.
7) 3.2. SID/Label Range TLV: Please specify that the sender MUST NOT advertise
overlapping ranges & how to handle the case when it does. This is required by
draft-ietf-spring-conflict-resolution.
8) Sec 3.3 SR Local Block (SRLB) Sub-TLV: The document doesn't specify that
the SR Local Block TLV MUST include a SID/Label sub-TLV nor indicate what to do
if multiple are included. The Length, again, isn't specified at all and
clearly has at least a minimum. I don't see a reference to an SR Local Block
or the need to advertise it in draft-ietf-spring-segment-routing-11; perhaps I
missed where the requirement and usage are defined?
9) Sec 3.3: "Each time a SID from the SRLB is allocated, it SHOULD also be
reported to all components..." Presumably, this is subjected to the normal
OSPF dampening - it'd be nice to note that somewhere - since rapid sequential
allocation may not provide the reporting speed anticipated.
10) Sec 4: "AF: Address family for the prefix. Currently, the only supported
value is 0 for IPv4 unicast. The inclusion of address family in
this TLV allows for future extension." Could you please clarify if this
is to reuse the same TLV for OSPFv3 so IPv6 can be supported, are you thinking
of extending OSPFv2 for IPv6 prefixes for some cases or something else? I think
the current phrasing is likely to raise questions. Similarly, please define
"Prefix length: Length of the prefix" clearly. I really don't understand what
the benefit of having a TLV that pretends to support multiple AFs but can't is
versus the clarity of specifying the prefix lengths.
11) Sec 4: Again "Length: Variable" - It should have a minimum and preferable
describe a function for how it is computed. A maximum is probably unlikely
with sub-TLVs.
12) Sec 4: OSPF Extended Prefix Range TLV: Does this TLV has any meaning or
action associated with it without including sub-TLVs? Are there mandatory
sub-TLVs? What is a receiving router to do with it?
13) Sec 5: "If multiple Prefix-SIDs are advertised for the same prefix, the
receiving router MUST use the first encoded SID and MAY use
subsequent SIDs." What does this even mean? A receiving router when making
the decision to use a subsequent SID is making a decision to not use the first
encoded SID; it's not like the router is going to stick both SID/Labels onto
the stack. Please describe this in meaningful normative terms.
14) Sec 5:" When calculating the outgoing label for the prefix, the router MUST
take into account the E and P flags advertised by the next-hop router
if that router advertised the SID for the prefix. This MUST be done
regardless of whether the next-hop router contributes to the best
path to the prefix." First, I assume this is "NP flag" because there is no
P flag.
Second - please clarify to "take into account, as described below, the E and
NP flags...". Third, the M flag must also be taken into account - given the
text later in the section.
15) Sec 5: "When a Prefix-SID is advertised in an Extended Prefix Range TLV,
then the value advertised in the Prefix SID Sub-TLV is interpreted as a
starting SID value." This appears to contradict "SID/Index/Label:
According to the V and L flags, it contains either:
A 32-bit index defining the offset in the SID/Label space
advertised by this router.
A 24-bit label where the 20 rightmost bits are used for
encoding the label value."
I assume that what is meant by the first quote is "...is interpreted, if the
V flag is clear, as a starting SID value, and if the V flag is set, as a
starting Label value." Otherwise, it looks like the Prefix-SID sub-TLV
couldn't be included in the Extended Prefix Range TLV if a label value would be
used.
It would be helpful for Example 2 to show the label case.
16) Sec 6.1: "aggregate IGP or TE path cost." Given that this is an OSPF
draft, it'd be helpful to indicate whether there are challenges with
non-comparable OSPF metrics (I'm thinking about AS-external type 2 costs) or if
the path will never include such costs.
17) Sec 6.2: "a domain and hence need to be disambiguated using a domain-unique
Router-ID." Given that the Prefix-SIDs and sub-TLVs can be distributed between
areas and even redistributed between protocols, please clearly define what is
meant by a "domain" or point to the appropriate definition.
18) Sec 4, 5, 6: Is it possible to have an OSPF Extended Prefix Range TLV that
includes both a Prefix SID Sub-TLV and a SID/Label Binding Sub-TLV? What does
that mean?
What does it mean if there are multiple prefixes described in the OSPF Extended
Prefix Range TLV that includes a SID/Label Binding Sub-TLV? Does the SID/Label
sub-sub-TLV indicate a single SID Index or Label that is used for the single
path to all those prefixes? Is it the start of a list of SID Indices or Labels?
I see that the SID/Label Binding sub-TLV can be in both the OSPF Extended Prefx
Range TLV as well as the OSPF Extended Prefix TLV - but there is no text on
differences in interpretation.
19) Sec 7.1 & 7.2: Another couple "Length: Variable." Please actually specify
the value. I think that, given the padding to 32-bit alignment, there is a
single correct value.
20) Sec 7.1 and 7.2: Given that the Flag bits have exactly the same meaning -
it'd be clearer to have them defined once.
21) Sec 8.1: "An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV
when advertising SIDs for prefixes. Prefixes of different route-types can be
combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping
Server." So - I can't find a normative definition of an SRMS to determine
why it is always necessary to use an OSPF Extended Prefix Range TLV instead of
an OSPF Extended Prefix TLV. I don't see how advertising prefixes from
different route-types can work unless the prefixes are adjacent, which seems
likely to be uncommon. Perhaps what is meant is "Because the OSPF Extended
Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended
Prefix TLV, it is possible to include adjacent prefixes from different
Route-Types in the OSPF Extended Prefix Range TLV."
22) Sec 8.1: "If multiple routers advertise a Prefix-SID for the same prefix,
then
the Prefix-SID MUST be the same. This is required in order to allow traffic
load-balancing when multiple equal cost paths to the destination exist in the
OSPFv2 routing domain." How is this enforced? What are the consequences of it
not being conformed to? This is NOT a protocol implementation requirement.
This should really be called out in a Manageability Considerations with
warnings.
23) Sec 8.2:"If no Prefix-SID was advertised for the prefix in the source area
by the router that contributes to the best path to the prefix, the
originating ABR will use the Prefix-SID advertised by any other
router when propagating the Prefix-SID for the prefix to other
areas." I believe that this depends on the assumption that if a
Prefix-SID is advertised by any router, the Prefix-SID will be the same.
Please be explicit in this assumption, since the requirement on the network
operator should be clear as well as the consequences of not conforming.
24) Sec 10: The Implementation Status section should indicate that it is to be
removed before publication as an RFC. Also, the complete implementation part
seems a bit dated - given the draft's technical changes in the last 2 years.
NITS:
1) Sec 2.1: s/"SID/Label TLV"/"SID/Label sub-TLV"
2) Sec 3.2:"Initially, the only supported Sub-TLV is the SID/Label TLV as
defined
in Section 2.1. The SID/Label advertised in the SID/Label TLV
represents the first SID/Label in the advertised range."
replace SID/Label TLV with SID/Label sub-TLV.
3) Sec 3.3 & Sec 3.4: " The SR Local Block (SRLB) Sub-TLV is a top-level TLV of
the Router Information Opaque LSA (defined in [RFC7770])." Please correct the
descriptions (many) to SR Local Block (SRLB) Sub-TLV to SR Local Block SRLB
TLV. The same issue exists for "SRMS Preference Sub-TLV".
Regards,
Alia
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
