[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
see below for responses...
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
Correct. We use ERO subobjects with these modifications. There has been
discussion in the past whether we reuse ERO subobjects and modify to
make them useful for XRO, or whether we define for the XRO new
subobjects. So far, the decision was to do the former but this is of
course open for discussion. The consequence is that when we want to
exclude something in the XRO, we also need the corresponding to include
it in the ERO. For SRLGs this means that we need an SRLG ERO subobject
which is not defined previously. It does not make much sense to have an
SRLG ERO subobject (that is why you would not find a document describing
the processing rules of such an object in the ERO), but it is needed for
the corresponding subobject in the 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."
Sounds better. I will do that. I will also remove the word "IP address"
because unnumbered (type 4) is not really an IP address.
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"
??? Is it OK if I change it into "For instance, the attribute node
allows a whole node to be excluded from the path, in contrast to the
attribute interface, which allows a specific interface or set of
interfaces to be excluded from the path."
Note that the interfaces in the set of interfaces does not have to be on
the same node.
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 ?
to make it more exact, I will change it into "*information* from RRO
subobjects, in speficying the exclusions." toghether with a reference to
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)
Ok, I see, it should indeed be mentioned somewhere that nodes MUST NOT
generate ERO and XRO/EXRS with conflicting information. Nevertheless it
remains needed to be said what has to be done when conflicting ERO and
XRO/EXRS are received by a node.
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
Ok, I will add 2 padding bytes.
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 ?
see beginning of this email.
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
Ok, will change it into "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 ?
"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)
ok, will use "may"
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
It depends on how the content of this section evolves. It is similar to
section 4.2, with similar title. Removign Semantic in both sections
looks good to me.