Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt

[stefaan.de_cnodder@alcatel.be]

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

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

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


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

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


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


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




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

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

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


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


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

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

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

> 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