[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




hi stefaan

thanks for your detailed reply - see in-line for some additional clarifications

stefaan.de_cnodder@alcatel.be wrote:

Hi Dimitri,

Thanks for these useful comments. Replies inline...

dimitri papadimitriou wrote:

hi adrian,

some comments here below on the exclude route i-d

technical
---------

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 subobjects do


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

"         node

             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
               exclusions)"

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 4.3.4.1. 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 exact processing

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
   explicit route."

... "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.

ok -

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 type/length) subobjects


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 duplicate things.


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.

indeed

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


editorial
---------

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
   this document."

would suggest replace this sentence with "This document does not assume or preclude any other usage for this subobject."

ok

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 context ?

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.

yes

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 above sentence.

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 its Subobjects".

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
   Route"."

you mean EXRS ? instead EXRO ?

yes

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

yes

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.

regards,

Stefaan



.