[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ccamp-gmpls-egress-control-00.txt
Hi Lyndon,
First note that this draft does not update the protocols and procedures of RFC3473. It
restates them more explicitly.
If you look at the RFC index (http://www.ietf.org/iesg/1rfc_index.txt) you'll see there is
very little precedent for this type of work.
We can find BCP 75 and 76 ( and http://www.ietf.org/rfc/rfc3666.txt) which could sort of
be said to update (or at least qualify) RFC 3261 and RFC 3264.
Neither is listed with an "updates" clause.
Nor does RFC 3481 (BCP 71) have any back/forward pointer with the TCP standard.
However, I take your point: how does someone wanting to know everything about GMPLS know
to read this new document?
We will look to see how this can be managed.
In return can you tell me: how does anyone wanting to see all of the RFCs related to (say)
TCP find them all?
Cheers,
Adrian
----- Original Message -----
From: "Ong, Lyndon" <LyOng@Ciena.com>
To: "'Lou Berger'" <lberger@movaz.com>; "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, April 08, 2004 10:20 PM
Subject: RE: draft-ietf-ccamp-gmpls-egress-control-00.txt
> Hi Guys,
>
> Administrative question - if this comes out as a BCP,
> does the RFC table note this as some kind of update
> to 3473?
>
> I'd be a little worried if there is no notation against
> the RFC to point people to the clarification.
>
> Thanks,
>
> Lyndon
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@movaz.com]
> Sent: Thursday, April 08, 2004 2:11 PM
> To: Adrian Farrel
> Cc: Berger, Lou; ccamp@ops.ietf.org
> Subject: Re: draft-ietf-ccamp-gmpls-egress-control-00.txt
>
>
> Adrian,
> See responses below.
>
> At 03:46 PM 4/8/2004 -0400, Adrian Farrel wrote:
> >Hi Lou,
> >
> > > >Please give the intended category of the work...
> > > >Proposed Category: Best Common Practice
> > >
> > > 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.
>
> will put into draft - I've always seen this in the last call announcement -
> but whatever...
>
>
> >
> > > >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
> > >
> > > fixed last week.
> >
> >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.
>
> will be fixed in next rev...
>
> >[...]>
> > > >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.
> > >
> > > I think the wording is consistent with RFC3473 and unambiguous. Please
> > > 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.
>
> Done!
>
> > > > 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.
> > > sure, will use phrasing from rfc3209.
> > >
> > > >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.
> > > okay.
> > >
> > > ><5. References
> > > > >5. Normative References
> > > >
> > > >Need BCP 78, and 79 as informational references.
> > > >Also RFC 3668.
> > >
> > > 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.
>
> ahh, you fell for my trick question! (they're the same document ;-)
>
> >
> > > >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.
> > > sure.
> > >
> > > >Don't need the footer...
> > > >Generated on: Mon Mar 15 10:52:32 2004
> > >
> > > picky, picky, picky...
> >That's what I'm paid for.
> >
> >Thanks, Lou. Looking forward to seeing the revision published.
> >
> >Adrian
> >
>
> Thanks again.
>
> submitting in a few minutes...
>
> Lou
>
>
>