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

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

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

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 processing

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

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

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"

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

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

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

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

thanks,
- dimitri.