[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last calls - comments ondraft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Hi Stefaan, Dimitri,
stefaan.de_cnodder@alcatel.be wrote:
> Hi Dimitri,
>
> 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
> > subobjects do
> >
>
> 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.
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
>
>
> >>> 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
> >
>
> yes
>
> >>> 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
> >>>
> >>> " 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 ?
> >
>
> 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
> >>> 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
> >
>
> ok
>
> >>> 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
> > type/length) subobjects
> >
>
> 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
> >>> 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 ?
> >
>
> 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
> >
>
> ok
>
> >>> 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
> >
>
> 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
> >> its Subobjects".
> >
> >
> > 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.
>
> regards,
>
> Stefaan