[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ccamp-gmpls-egress-control-00.txt
Hi Lou,
In Seoul we agreed that this draft would become a WG document and we
talked a little about doing a working group last call immediately thereafter.
Thanks for re-spinning the draft as a WG draft. There are, however, a few
nits that I think you should tidy up before we do the last call.
Perhaps others would like to pitch in now if they have any substantive
comments before the last call.
Thanks,
Adrian
Please give the intended category of the work...
Proposed Category: Best Common Practice
Please correct draft name as it appears in the title and footers.
<draft-ccamp-gmpls-egress-control-00.txt
>draft-ietf-ccamp-gmpls-egress-control-00.txt
Abstract
Please remove [bracketed] citation from abstract.
Abstract
This note clarifies the procedures for the control of a label used on
an egress output/downstream interface.
I think this would be better phrased as...
This note clarifies the procedures for the control of the label used
on output/downstream interface of the final (egress) Label Switching
Router (LSR) of a Label Switched Path (LSP).
1. Background
The ability to control a label used on an egress output/downstream
interface was one of the early requirements for GMPLS.
Again, rephrase as...
The ability to control the label used on the output/downstream
interface of an egress LSR was one of the early requirements for
GMPLS.
2.1. ERO Procedures
Egress Control occurs when the node processing an ERO is the egress
and the ERO contains one or more label subobjects.
In view of the text quoted from section 6 of an early draft of GMPLS,
we either need to re-cast this whole draft as "Egress Label Control"
or we need to generalize the text here as egress control that allows
the control of interface, component link and label.
I prefer the second option.
Compare with section 2.2 which is more general.
To support Egress Control, an egress checks to see if the received
ERO contains an outgoing/downstream interface. If it does, the type
of the subobject or subobjects following the interface are examined.
If the associated LSP is unidirectional, one subobject is examined.
Two subobjects are examined for bidirectional LSPs. If the U-bit of
the subobject being examined is clear (0), then the value of the
label is copied into a new Label_Set object. Note, this Label_Set
object is for internal use only. This Label_Set object indicates the
label value that MUST be used for transmitting traffic associated
with the LSP on the indicated outgoing/downstream interface.
Not withstanding "this Label_Set object is for internal use only", I
find this text a bit peculiar!
You really just want to say that this subobject is used to specify the
label that the egress MUST apply to traffic that it forwards from this
LSP. (Compare with the next paragraph where you do not describe
creating an Upstream_Label object for internal use only.)
If you insist on talking about the Label_Set object, you will have to be
far more specific because there are four different varieties of that
object.
including if the listed label(s) are not acceptable or cannot be
supported in forwarding, SHOULD result in the generation of a PathErr
message containing a "Bad EXPLICIT_ROUTE object" error.
I'd prefer you to be more explicit...
... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error.
3. Security Considerations
< This note clarifies procedures defined in [RFC3473]. As such, no new
< security considerations are introduced.
> This note reiterates procedures defined in [RFC3473], but does not
> define any new procedures. As such, no new security considerations
> are introduced.
<5. References
>5. Normative References
Need BCP 78, and 79 as informational references.
Also RFC 3668.
8. Intellectual Property
Missing the personal disclaimer...
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Don't need the footer...
Generated on: Mon Mar 15 10:52:32 2004