Subject: draft-ietf-ccamp-gmpls-egress-control-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Apr 2004 16:23:44 +0100

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 05 Apr 2004 15:47:34 -0400

Adrian,
         Thanks for the comments.  See below.

Lou

>Proposed Category: Best Common Practice

this is normally done outside of the draft.

> >draft-ietf-ccamp-gmpls-egress-control-00.txt

fixed last week.

>Please remove [bracketed] citation from abstract.

done

>    Router (LSR) of a Label Switched Path (LSP).

sure.

>    interface of an egress LSR was one of the early requirements for

sure, why not.

>I prefer the second option.

no problem.  changed to ... "one or more subobjects related to the 
output/downstream interface"

>far more specific because there are four different varieties of that

I think the wording is consistent with RFC3473 and unambiguous.  Please 
suggest alternate wording.

>... containing a "Routing Problem"/"Bad EXPLICIT_ROUTE object" error.

sure, will use phrasing from rfc3209.

> >  define any new procedures.  As such, no new security considerations

okay.

>Need BCP 78, and 79 as informational references.

will do, but do you really want me to reference BCP 79 and  RFC 3668?

>    and any of which I become aware will be disclosed, in accordance with

sure.

>Generated on: Mon Mar 15 10:52:32 2004

picky, picky, picky...

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Apr 2004 20:46:47 +0100

Hi Lou,

> this is normally done outside of the draft.

Hmmm.
The draft needs to indicate its intended status so that folks can review it with that in mind.
If you don't want to say that the proposed status is BCP then please at least say informational.

> > >draft-ietf-ccamp-gmpls-egress-control-00.txt

Hah! But the secretariat has published it according to your first submission.
Actually, the version on the LabN site is also wrong.

I don't mean the document name, I mean the draft name as it appears throughout the document.

> suggest alternate wording.

Well!  I can't be held responsible for the failings of the editor of that RFC  :-)

Section 5.1.1 says with respect to the ERO Label Subobject...
   If the U-bit of the
   subobject being examined is clear (0), then value of the label is
   copied into a new Label_Set object.  This Label_Set object MUST be
   included on the corresponding outgoing Path message.

So I see where you are coming from, but I think this text is aimed at
specifying how you build the outgoing Path message, not how you
manage the label allocation on your downstream interface. It is 
wrong to suggest that an implementation must create a protocol
object for this purpose if no Path message is to be sent.

In fact, since there is no corresponding Resv with a Label Object
we need to pin this text down a little more clearly. How about the
following edit...

    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 MUST be used for transmitting traffic associated with the LSP
    on the indicated outgoing/downstream interface.

> will do, but do you really want me to reference BCP 79 and  RFC 3668?

It is unclear whether this is a requirement, but since the boilerplate text makes these references it seems reasonable to include them in the list.

> >Generated on: Mon Mar 15 10:52:32 2004

That's what I'm paid for.

Thanks, Lou. Looking forward to seeing the revision published.

Adrian

---

From: Lou Berger <[email-masked]>
Date: Thu, 08 Apr 2004 17:10:33 -0400

Adrian,
         See responses below.

>If you don't want to say that the proposed status is BCP then please at 

will put into draft - I've always seen this in the last call announcement - 
but whatever...

>I don't mean the document name, I mean the draft name as it appears 

will be fixed in next rev...

>[...]>

Done!

>It is unclear whether this is a requirement, but since the boilerplate 
>text makes these references it seems reasonable to include them in the list.

ahh, you fell for my trick question!  (they're the same document ;-)

>Thanks, Lou. Looking forward to seeing the revision published.

Thanks again.

submitting in a few minutes...

Lou