[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
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
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)."
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) -
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 ?
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
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 ?
7. section 4.2 - condition 1. what does happen when the L flag is not
set and the condition is not verified ?
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 exact
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
10. section 4.2 - concerning the operations i would suggesting adding a
rule suggesting that no contradicting exclusions get inserted
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"
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)
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
note that section 5. would probably require a revision after completion
of the technical details
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
15. there is nothing said concerning usage of EXRS when using XRO ?
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"
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)
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
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,
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 ?
8. section 5.1
"Both subobjects are as described earlier in this document." both (to
which subobject do you refer here) ?
9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 Processing
Rules for the EXR Subobject and its Subobjects"
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
hope these comments will help you