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

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 05 Apr 2005 10:48:24 +0200

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.

---

From: [email-masked]
Date: Wed, 06 Apr 2005 15:21:15 +0200

Hi Dimitri,

Thanks for these useful comments. Replies inline...

> AB2 selects an area B link to reach AB1

correct, the same applies for the next area as well.

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

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

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

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

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

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

> the technical part because it impacts understanding concerning the exact 

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.

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

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

> ... "must" while the L bit means either "avoid" or "exclude"

indeed, should be "...must not or should not be used...".

> the first one ? (note: the doc. since far tells the reader that the EXRS 

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.

> 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 

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.

> -> the EXRS is an optimization it should not be considered as a should 

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.

> benefit from using a single term either "exclude" or "exclusion"

ok, lets take "exclusion"

> or preclude any other usage for this subobject."

ok

> ERO in the present context)

indeed, sentence should be "A new ERO subobject type ...."

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

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.

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

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

> Rules for the EXR Subobject and its Subobjects"

indeed. should be "5.2 Semantics and Processing Rules for the EXRS and 
its Subobjects".

> you mean EXRS ? instead EXRO ?

yes

> ... Routing Problem/Bad EXPLICIT_ROUTE object

yes

> note that in general definition of the subobject field could be made a 

I agree with that.

> hope these comments will help you

Sure. Thanks for the comments.

regards,

Stefaan

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 07 Apr 2005 09:53:35 +0200

hi stefaan

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

[email-masked] wrote:
>> 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
> 

-> yes, but also ERO subobjects do not include an attribute field, XRO 
subobjects do

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

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

indeed, this is what i understood, my question is more "how can you be 
specific if you remove a set of interfaces"

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

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 ?

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

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
>

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)

>> the first one ? (note: the doc. since far tells the reader that the 
>> EXRS is an ERO subobject)
> 

ok -

>> Length." while with the provided alignment it looks like each 
>> exclusion element is encoded with this double Type/Length field
> 
> "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 

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
> 

indeed

> 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 
>> would suggest replace this sentence with "This document does not 
>> assume or preclude any other usage for this subobject."
> 
> ok
> 
>> would complete the last part of the sentence (as i guess you mean of 
>> the ERO in the present context)
> 
> 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 

ok - but then indicate that there is no description available of the 
usage of an SRLG subobjects as part of an ERO

> 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

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

>> 9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2 
>> Processing Rules for the EXR Subobject and its Subobjects"
> 

suggest to remove the term semantic since it should be clear from its 
definition in section 5.1

> .

---

From: [email-masked]
Date: Thu, 07 Apr 2005 20:37:08 +0200

Hi Dimitri,

see below for responses...

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

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.

>> see following subsections. Is it enough that I change "IP address" 
>> into "IP prefix" to make it more clear?
> 
> 

Sounds better. I will do that. I will also remove the word "IP address" 
because unnumbered (type 4) is not really an IP address.

yes

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

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

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

ok

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

>> 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 will add 2 padding bytes.

> would it be possible to know which document makes use of SRLG as part of 

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

> has already generated enough issues

Ok, will change it into "TE Router ID"

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

ok, will use "may"

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

regards,

Stefaan

---

From: Cheng-Yin Lee <[email-masked]>
Date: Mon, 11 Apr 2005 13:48:50 -0400

Hi Stefaan, Dimitri,

>   the corresponding subobject in the XRO.

Perhaps it is sufficient to say something along the line :
"This specification adapts ERO subobjects for use in route exclusions.
The SRLG ERO subobject and its processing within an ERO have not been defined
before. The SRLG ERO subobject is defined here for use with route exclusion."

SRLG ERO processing for route inclusion, if required, is out of scope but I
think it is better that the Exclude Route spec does not rule out/talk about the
use of SRLG ERO in route inclusion for whatever reasons ...

Thanks
Cheng-Yin

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 13 Apr 2005 19:42:35 -0700 (PDT)

Hi,

Here are a few comments on this ID. Sorry for the delay.
Also, in case some of these comments are a repetition, please ignore
those.

thanks,
-arthi
----------------
1)
Section 2.

To convey these constructs within the signaling protocol, a new
RSVP object and a new ERO subobject are introcuded respectively.
                                       ^^^^^^^^^^^
- Typo

2)
Section 4.2
The number of introduced exlicit nodes or abstract nodes with
                        ^^^^^^^^^^
the L flag set to "avoid" should be minimised.

- Typo

3)
5.2
Each EXRS may carry multiple exclusions.  The exclusion is encoded
---------------------------------------
exactly as for XRO subobjects and prefixed by an additional Type and
Length.

<AA> Did you mean, there can be multiple EXRS per ERO, which I see or
     multiple exclusions per EXRS ?
     From the format of the EXRS it looks like one exclusion per EXRS.
     Did I miss something ?

4)
Thus, an EXRO subobject for an IP hop might look as follows:
     ^^^^^^^^^^^^^^^^^
<AA> EXRS ? Also the S in EXRS already means sub-object, so you could get
rid of sub-object following EXRS.

5)
The subobjects in the ERO and EXRS SHOULD not contradict each other.
If they do contradict, the subobjects with the L bit not set, strict
or MUST be excluded, respectively, in the ERO or XRO MUST take pre-
cedence.  If there is still a conflict, the subobjects in the ERO
MUST take precedence.

<AA> You may want to state explicitly what you mean by contradict for
EXRS. Is the scope of contradiction just the previous and next ERO
sub-objects ?

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

7)
<AA> With respect to EXRS, it might be useful to clarify what does EXRS
provide that cannot be achieved by XRO. Basically give some hints as to
where EXRS may be useful versus XRO. Also, can there be conflicts between
EXRS and XRO ? If yes, then how is that dealt with ?

8) Section 6

The IPv6 Prefix subobject MUST be supported with a prefix
          length of 128, and an attriubute value of "interface" and
                              ^^^^^^^^^^^^
          "node".
- Typo

-----------------

---

From: Cheng-Yin Lee <[email-masked]>
Date: Thu, 14 Apr 2005 00:55:26 -0400

Hi Arthi,
Thanks for your comments.

> Also, in case some of these comments are a repetition, please ignore

Ok, we should run spell check.

> Each EXRS may carry multiple exclusions.  The exclusion is encoded

there can be multiple EXRS per ERO
multiple subobjects can  be specified in an EXRS

> <AA> EXRS ?

Yes.

> Also the S in EXRS already means sub-object, so you could get

ok.

> EXRS. Is the scope of contradiction just the previous and next ERO

Yes. This may not be a contradiction. We will think of some text to clarify
this.

> where EXRS may be useful versus XRO.

EXRS - If we need to exclude a resource between A and B only (could be a
policy thing), but may want to use the resource elsewhere  in the path.

> Also, can there be conflicts between

I can't think of conflicts between EXRS and XRO, if X is excluded by EXRS and
XRO, then it is just redundant to specify X in EXRS.

Thanks
Cheng-Yin