[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
thanks for your detailed reply - see in-line for some additional
Thanks for these useful comments. Replies inline...
dimitri papadimitriou wrote:
some comments here below on the exclude route i-d
1. section 2.1
"Constrained Shortest Path First (CSPF) computation at Ingress, so the
ERO and XRO signaled at Ingress could be (A3-strict, A4-strict,
AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively."
AB1 should also be excluded as AB2 does not know the first path
crosses this node so there may be a case (in this example for inst.
imagine there is no link between AB2 and B3) where this could lead to
overlap if AB2 selects an area B link to reach AB1
correct, the same applies for the next area as well.
2. section 4
"The exclude route identifies a list of abstract nodes that MUST NOT
be traversed along the path of the LSP being established."
while section 4.1
" The concept of loose or strict hops has no meaning in route
exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is
reused here to indicate that an abstract node MUST be avoided (value
0) or SHOULD be avoided (value 1)."
correct. I believe it is better to say "... that should not be
traversed..." with "should" in small because the formal specification is
in the subsections.
3. section 4.1
"The subobjects are identical to
those defined in [RFC3209] and [RFC3473] for use in EROs."
looking at the definitions this is not the case (moreover the SRLG
subobject has been added) -
Are you only referring to the SRLG subobject? If yes, then it is best to
change it into "...those defined in [RFC3209] and [RFC3473] for use in
EROs and section 3.1 of this document."
-> yes, but also ERO subobjects do not include an attribute field, XRO
4. section 4.1
" An Attribute octet is introduced in the subobjects that define IP
addresses to indicate the attribute (e.g. interface, node, SRLG)
associated with the IP addresses that can be excluded from the path."
what is a subobject that define IP addresses ?
see following subsections. Is it enough that I change "IP address" into
"IP prefix" to make it more clear?
wouldn't be better to refer to the subobject types instead, something
like (concerning the
"An Attribute field is introduced in the subobjects Type 1, 2 and 4 to
indicate the attribute (e.g. interface, node, SRLG) that is associated
with the IP address included as part of the subobject and that can be
excluded from the path."
also definition of the attribute value should refer better to "IPv4 or
IPv6 address treated as an prefix based on the prefix length value"
last point but this is editorial, currently you have
4.1.1 Subobject 1: IPv4 prefix
4.1.2 Subobject 2: IPv6 Prefix
4.1.3 Subobject 32: Autonomous System Number
4.1.4 Subobject TBD: SRLG
4.1.5 Subobject 4: Unnumbered Interface ID Subobject
wouldn't it be better to list them as
4.1.1 Subobject 1: IPv4 prefix
4.1.2 Subobject 2: IPv6 Prefix
4.1.3 Subobject 4: Unnumbered Interface ID Subobject
4.1.4 Subobject 32: Autonomous System Number
4.1.5 Subobject TBD: SRLG
5. section 4.1
" For instance, the attribute node allows a whole node to be excluded
from the path, in contrast to the attribute interface, which allows
specific interfaces to be excluded from the path. "
but below the definition says "0 indicates that the interface or set
of interfaces associated with the IP prefix should be excluded or
avoided" which makes the term specific ambiguous
Section 4.1 is an example on how to exclude a node or an interface from
a path. Section 4.1.1 contains the full specification and the example
looks to be contained in 4.1.1.
indeed, this is what i understood, my question is more "how can you be
specific if you remove a set of interfaces"
6. section 4.1.5
1 indicates that the node with the Router ID should be
excluded or avoided (this can be achieved using IPv4/v6
subobject as well, but is included here because it may be
convenient to use subobjects from RRO, in specifying the
until "(this can be achieved using IPv4/v6 subobject" i understand
after i would ask you to clarify i guess you mean RRO from another
path ? should you include this as part of the definition ?
Can you give an example on how the exlude/avoid resources from a path
computation while the path is already computed and signaled (otherwise
you do not have an RRO)?
you signal a first LSP, at the ingress you recuperate the (Resv) RRO
that you inject (may be after some transformation) as part of the XRO of
another LSP (load balancing for inst.)
now concerning the initial point (as i do not understand what you mean
by "use RRO subobjects for exclusion" to achieve the same functionality
as an XRO with the Type 4 subobject) would you please provide 1) the
explanation about the context of the usage of the RRO subobjects for
exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then
2) why do you think providing two ways to do the same thing as part of
the same document is useful ?
7. section 4.2 - condition 1. what does happen when the L flag is not
set and the condition is not verified ?
Then the actions mentioned do not have to be done and the next step in
the processing is done. There is no explicit statement saying that in
this case the next step must be taken, neither is there a statement
saying that the processing also stops when the condition is met. See
188.8.131.52. of RFC3209 for similar way of describing processing.
8. section 4.2 - condition 3. "If they do contradict, the subobjects
with the L flag not set, strict or MUST be excluded, respectively, in
the ERO or XRO MUST take precedence." this sentence is cryptic i put
in the technical part because it impacts understanding concerning the
Indeed, the sentence is not understandable and even wrong (the same
applies to a similar sentence in EXRS). Irrespective of whether the ERO
subobject is strict or loose, it takes precedence togheter with exclude
subobjects in the XRO over the avoid subobjects.
9. section 4.2 - condition 4. "The number of introduced SLRGs with the
L flag set to "avoid" should be minimised." i guess you mean wrt to
the number of "exclude" SRLGs (blocking) ? or is there an absolute
limitation due to the message size
The sentence you are referring to is not related to the number of
subobejcts in the XRO. It is related to the number of links belonging to
SRLGs that should be avoided.
please rephrase it - because it is quite difficult to deduce this
meaning (in particular, if a recommendation follows that statement)
For instance, when there is a path that
has a link with 1 SRLG to be avoided, and there is another path with a
link of 2 SRLGs to be avoided, and there are no alternative paths then
take the first path because it minimises the number of SLRGs with the L
flag set to avoid.
To make it clear, I will change the text as follows: "The number of
introduced explicit ndoes or abstract nodes in the computed path with
the L flag set to "avoid" should be minimised.
ok - and indicate a sensible reason would help in understanding why -
this is not difficult to be spelled out anyway
10. section 4.2 - concerning the operations i would suggesting adding
a rule suggesting that no contradicting exclusions get inserted
What is a contradicting exclusion? Do you mean if for instance a node
appears twice in the XRO, as avoid and exclude? In that case it is
exclude. I will add a statement. Contradictions with ERO are possible
but that is mentioned.
the document says "If an XRO was present, the content of the XRO can be
modified." so what i mean is that THIS node does not introduce a
exclusion for an subobject it has itself included as part of the ERO (as
the document explains how to process such contradicting exclusions but
should also have clear rules in terms of generation of XROs)
11. section 5.
"The Explicit Exclude Route defines abstract nodes or resources (such
as links, unnumbered interfaces or labels) that must not be used on
the path between two inclusive abstract nodes or resources in the
... "must" while the L bit means either "avoid" or "exclude"
indeed, should be "...must not or should not be used...".
12. section 5.1
" A new ERO subobject type is defined. The Explicit Exclude Route
Subobject (EXRS) has type [TBD]. The EXRS may not be present in an
RRO or XRO."
would you clarify the meaning of the second sentence in the context of
the first one ? (note: the doc. since far tells the reader that the
EXRS is an ERO subobject)
Better to make it "The EXRS MUST NOT be present in an XRO". The
subobjects of the XRO are the same as the ERO subobject. The EXRS is
also an ERO subobject, but may not be present in XRO. It is rather
obvious that EXRS can not be in the RRO, so that can be removed.
13. section 5.1
" Note: The Most Significant Bit in the Type field could be used to
indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
the need to prepend the subobject with an additional TLV header.
This would reduce the number bytes require for each subobject by 2
bytes. However, this approach would reduce the ERO Type field space
by half. This issue need WG discussion and feedback."
-> i would suggest keeping existing definition (since the EXRS is to
considered as an optimization), this said better formalization of the
EXRS subobjects needs to be provided - as the next section mentions
"Each EXRS may carry multiple exclusions. The exclusion is encoded
exactly as for XRO subobjects and prefixed by an additional Type and
Length." while with the provided alignment it looks like each
exclusion element is encoded with this double Type/Length field
Thanks for your feedback on this question. Concerning the alignment:
there can be multiple subobjects in an EXRS, note the plural form of
"EXRS subobjects" in the first figure of section 5.1.
also "The format of this field is exactly the format of an XRO subobject
and may include an SRLG subobject. Both subobjects are as described
earlier in this document." ... both subobjects refers to ?
Better to make this more explicit in the specification of "EXRS subobjects": One or
more EXRS subobjects. An EXRS subobject indicates....". For a better
alignment it might be better to indeed add 2 padding bytes after the
Type and Length.
ok - i do suggest making use of this padding since we speak about a list
including sub-lists of subobjects and not lists including (double
note that section 5. would probably require a revision after
completion of the technical details
I agree. In fact, I believe the processing can be largely removed by
referring to the XRO processing. The processing is the same except with
the limitation that it only applies to a part of the path. For instance
comment 8 above, also applies here and it makes not much sense to
14. section 6.
" 2. The EXRS SHOULD be supported. If supported, the same
restrictions as for the XRO apply."
-> the EXRS is an optimization it should not be considered as a should
but optional ie MAY
Because it is about *minimal* compliance, I tend to agree.
15. there is nothing said concerning usage of EXRS when using XRO ?
Good point. Since there is basically not much difference in the
processing between EXRS and XRO, it is not a big deal to handle both.
i would suggest carefully analyzing all the potential cases here in
part. for the partial overlaps
1. section 2. and onward why referring to a "Explicit Exclude Route"
and then to a "5.1 Explicit Exclusion Route Subobject (EXRS)" and not
a "Explicit Exclude Route Subobject (EXRS)" ? -> the document would
benefit from using a single term either "exclude" or "exclusion"
ok, lets take "exclusion"
2. section 2.
" This subobject might also be appropriate for use within Explicit
Routes or Record Routes, but that discussion is outside the scope of
would suggest replace this sentence with "This document does not
assume or preclude any other usage for this subobject."
3. section 2. "A new subobject type the Explicit Exclude
Route Subobject (EXRS) is introduced to indicate an exclusion
between a pair of included abstract nodes."
would complete the last part of the sentence (as i guess you mean of
the ERO in the present context)
indeed, sentence should be "A new ERO subobject type ...."
4. why section 3.1 is defined as "SRLG ERO Subobject" i think this
should better be defined as an "SRLG Subobject" as i do not see a
specific reason for having an SRLG subobject outside of the XRO, EXRS
not really, see 2 previous comments. It is really an ERO subobject but
the usage of this in ERO is not part of this document.
would it be possible to know which document makes use of SRLG as part of
an ERO ?
This comes down
to the discussion whether XRO defines new subobjects specific for XRO or
whether XRO simply reuses the ERO subobjects with some modifications
(L-flag and attribute). So far, the latter has been choosen but that
means that it is an SRLG ERO subobject.
ok - but then indicate that there is no description available of the
usage of an SRLG subobjects as part of an ERO
5. Section 4.1.x - adapt IP address to IPv4 address when defining the
IPv4 subobject, etc.
6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,
see rfc3477, section 4, from where we got the object. In fact, a
reference to this RFC is missing.
this rfc refers to the former but i do suggest using the latter as this
has already generated enough issues
7. section 5.1
""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
what do you mean by might ? isn't EXRS instead of EXRO ?
"Might" means that there other methods to do the same. For instance, if
the IP hop is IPv6, it looks different. If unnumbered links are used, it
is also different. Indeed, EXRO should be EXRS.
indeed but might is not really used in a prescptive document (prefer MAY
with alternatives in case)
8. section 5.1
"Both subobjects are as described earlier in this document." both (to
which subobject do you refer here) ?
should be "The format of an EXRS subobject is exactly the same as the
format of a subobject in the XRO. An EXRS may include all subobjects
defined for the XRO in this document.".
In this way it is more clear. Becuase SRLG has been defined for XRO in
this document it may also be in the EXRS but that is implicit in the
9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2
Processing Rules for the EXR Subobject and its Subobjects"
indeed. should be "5.2 Semantics and Processing Rules for the EXRS and
suggest to remove the term semantic since it should be clear from its
definition in section 5.1
10. section 5.2
"If the presence of EXRO Subobjects precludes further forwarding of
the Path message, the node should return a PathErr with the error
code "Routing Problem" and error value of "Route blocked by Exclude
you mean EXRS ? instead EXRO ?
11. section 5.2
"If a node is called upon to process an EXRS and does not support
handling of exclusions it will return a PathErr with a "Bad
EXPLICIT_ROUTE object" error."
... Routing Problem/Bad EXPLICIT_ROUTE object
note that in general definition of the subobject field could be made a
bit more explicit
I agree with that.
hope these comments will help you
Sure. Thanks for the comments.