Skip to main content

Component Link Recording and Resource Control for TE Links
draft-ietf-mpls-explicit-resource-control-bundle-10

Revision differences

Document history

Date Rev. By Action
2024-01-16
10 Adrian Farrel
This document fell at the last hurdle when the authors failed to respond to or address the shepherding AD's review comments.
It appears to have …
This document fell at the last hurdle when the authors failed to respond to or address the shepherding AD's review comments.
It appears to have been abandoned.
It will be unadopted
2024-01-16
10 Adrian Farrel Tag Other - see Comment Log set. Tag Approved in minutes cleared.
2024-01-16
10 Adrian Farrel IETF WG state changed to Dead WG Document from WG Document
2024-01-16
10 Adrian Farrel Note that this document has nothing to do with draft-ietf-bliss-shared-appearances!
2015-10-14
10 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-explicit-resource-control-bundle@ietf.org, martin.vigoureux@alcatel-lucent.com to martin.vigoureux@alcatel-lucent.com
2011-10-29
10 (System) This was part of a ballot set with: draft-ietf-bliss-shared-appearances
2011-10-29
10 (System) Document has expired
2011-10-29
10 (System) State changed to Dead from AD is watching.
2011-07-25
10 Adrian Farrel
State changed to AD is watching from AD Evaluation.
Hi,

I have performed a further AD review of this document because my first review was …
State changed to AD is watching from AD Evaluation.
Hi,

I have performed a further AD review of this document because my first review was quite substantial and it has been a while since then.

idnits throws up a large number of issues. A substantial number are caused by formatting problems with the document as submitted. It would be wise to fix these to allow you to uncover the real problems that are lurking.

I do not appear to have received a direct response to my previous review (sorry if I lost it) and so I am piecing together your responses from the changes you have made. A number of issues remain to be addressed. I have interleaved these with a few new comments.

> I have a meta-question about this draft. Given RFC 4990 Section 6.2,
> why is this extension needed? I can see it would work, but what is the
> benefit of creating a second way to signal a component link in an ERO
> or RRO?

I still think this question needs to be answered in the document. I would expect a direct reference to 4990, a statement of the limitation of 4990, and a summary of how this proposal resolves the limitation.

The Abstract makes a forceful assertion on the need for this work, but the document seems to completely ignore the solution set out in 4990.

> I think you need to rewrite the Abstract. Consider that you should be
> able to read the Abstract in a fair degree of isolation, so it should
> give context.
>
> At the moment you jump straight into Record Route without any hints
> that you are dealing with GMPLS!
>
> You also need to remove citations from the Abstract (you are allowed
> to name the documents).

I don't see any changes for these points.

> Section 1 needs to include a definition of "Component Interface"

I don't see a change for this.

> Can you go through the document and expand all of the acronyms where
> they are first used.

LSP is expanded but some time after first use
SRLG is expanded but not quite in the right place
LSR isn't expanded

---

Section 4.1
s/oPTIoNAL/OPTIONAL/

> Section 4.1
>
>    The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
>    being sent upstream by a node processing an ERO that contains the
>    Component Interface ID sub-object:
>
>    o) The first component interface identifier subobject is not
>      preceded by a sub-object containing an IPv4 or IPv6 address, or
>      an interface identifier [RFC3477], associated with a TE link.
>
> and later...
>
>    Inferred from above, the interface subobject should never be the
>    first subobject in a newly received message.  If the component
>    interface subobject is the first subobject in a received ERO, then it
>    SHOULD be treated as a "Bad strict node" error.
>
> These seem to contradict each other.

Doesn't appear to have been resolved.

---

Section 7

There seems to be a discrepancy about the codepoint requests.
This is marked as an Experimental document (for publication as an Experimental RFC). Yet it is making requests for codepoints from "Standard Actions" registries.

My understanding is IANA will not allow this.

So either the status of the I-D needs to change, or the allocations need to change.


Thanks,
Adrian
2011-05-04
10 Adrian Farrel State changed to AD Evaluation from AD is watching::Revised ID Needed.
Moved back for re-evaluation after author mark-ups
2011-04-27
10 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-10.txt
2011-04-21
10 Adrian Farrel State changed to AD is watching::Revised ID Needed from AD Evaluation::Revised ID Needed.
No progress for 6 months after AD review
2010-10-31
10 Adrian Farrel State changed to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Adrian Farrel
2010-10-31
10 Adrian Farrel
AD review

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or …
AD review

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or issues before the document goes
forward to IETF last call and IESG review. By getting these issues
out at this stage we can hope for a higher quality review and a
smoother passage through the process.

I am having some trouble with the draft. There are a good number of
small issues of language and the like. These are easily fixed although
I confess that they are so plentiful that I have not noted them all.
More important, are the issues of content that I have noted below.

I think my comments need to be addressed for this document to stand
half a chance of getting through IESG review, and I would like you to
have a look and see whether you can work to improve the text before I
take it forward. Perhaps you should take some time to talk with the
document shepherd and WG chairs to determine what the best course of
action is. All of the comments are, of course, open for discussion.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

I have a meta-question about this draft. Given RFC 4990 Section 6.2,
why is this extension needed? I can see it would work, but what is the
benefit of creating a second way to signal a component link in an ERO
or RRO?

---
I think you need to rewrite the Abstract. Consider that you should be
able to read the Abstract in a fair degree of isolation, so it should
give context.

At the moment you jump straight into Record Route without any hints
that you are dealing with GMPLS!

You also need to remove citations from the Abstract (you are allowed
to name the documents).

---

Please search out "draft" and replace with "document" since you hope
that it will become an RFC at some point :-)

---

Section 1 needs to include a definition of "Component Interface"

---

Section 1

  For unnumbered component links, the component link
  ID is assumed to be unique on an advertising node.

I think you might usefully reference RFC 3477 here. The definition of
an unnumbered TE link in 3477 uses this concept, and you are extending
it to be used in unnumbered component links.

I recall there was some debate about the validity of this extension.
Many people said that they wanted the component link ID to be unique in
the scope of the bundle (cf. port numbers). Of course, the component
link ID can be constructed from the rack-shelf-card-port to achieve the
necessary uniqueness, but it is far from obvious to me that the
assumption you make is universal.

So you should at least expose this a little more clearly. Perhaps there
is something in section 2.1 of RFC 4201 and section 13.12 of RFC 4204
you can reference explicitly?

---

It is usual to begin the document with the Introduction. This is
certainly the preference of the RFC Editor, and she may well ask you
to change the order of your sections. Might as well do it now!

---

Can you go through the document and expand all of the acronyms where
they are first used.

---

Section 2

s/networks [RFC3945] that deals/networks [RFC3945] that deal/

---

Section 2

  Link Bundling, introduced in [RFC4201], is used to improve routing
  scalability by reducing the amount of TE related information that
  needs to be flooded and handled by IGP in a TE network. This is
  accomplished by aggregating and abstracting the TE Link resource. In
  some cases the complete resource identification is left as a local
  decision.

I really don't think the reader will understand this.
What does "complete resource identification mean"?
Do you mean choice is left as a local decision? Because identification
is always a local decision.

---

Section 2

  In GMPLS networks [RFC3945] that deals with unbundled (being either
  PSC, L2SC, TDM or LSC) TE Links, one of the types of resources that
  an LSP originator can control and would like to record are the TE
  Link interfaces used by the LSP. The resource control and recording
  is done by the use of an explicit route, i.e., Explicit Route (ERO)
  Object and record Route, i.e., Record Route Object (RRO) object,
  respectively.

  Link Bundling, introduced in [RFC4201], is used to improve routing
  scalability by reducing the amount of TE related information that
  needs to be flooded and handled by IGP in a TE network. This is
  accomplished by aggregating and abstracting the TE Link resource. In
  some cases the complete resource identification is left as a local
  decision. However, as described above there are cases when it is
  desirable for a non-local (e.g., LSP head-end) node to identify
  completely or partially the LSP resources.  In either case, and for
  administrative reasons, it is required to know which component link
  within a bundled TE link has been used for a given LSP.

I don't think you can get away without actually saying what the reason
for wanting to know/control this information is? Why does an LSP
originator want to control the component links? You need to set out
the requirements and problem description better.

---

Section 2

  Link Bundling, introduced in [RFC4201], is used to improve routing
  scalability by reducing the amount of TE related information that
  needs to be flooded and handled by IGP in a TE network. This is
  accomplished by aggregating and abstracting the TE Link resource. In
  some cases the complete resource identification is left as a local
  decision. However, as described above there are cases when it is
  desirable for a non-local (e.g., LSP head-end) node to identify
  completely or partially the LSP resources. In either case, and for
  administrative reasons, it is required to know which component link
  within a bundled TE link has been used for a given LSP.

"In either case"?
What is the other case?

---

Section 2

  When link bundling is used to aggregate multiple component links into
  a TE link, label is not the only resource that needs to be identified
  and recorded.

But this is the first time you have mentioned recording labels.

---

Try to remove things like "RRO objects" because the "O" in "RRO" means
"object".

---

Section 3.2

I don't think this section makes it crystal clear whether, on Resv RRO
processing, a node pushes the upstream or downstream component link
identifier. Yes, this follows Resv RRO processing for the normal case
(i.e., the node always pushes the downstream interface ID), but you
could help make this clear.

---

Section 4.1

  The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
  being sent upstream by a node processing an ERO that contains the
  Component Interface ID sub-object:

  o) The first component interface identifier subobject is not
      preceded by a sub-object containing an IPv4 or IPv6 address, or
      an interface identifier [RFC3477], associated with a TE link.

and later...

  Inferred from above, the interface subobject should never be the
  first subobject in a newly received message.  If the component
  interface subobject is the first subobject in a received ERO, then it
  SHOULD be treated as a "Bad strict node" error.

These seem to contradict each other.

---

Section 5

5. Forward Compatibility Note

Isn't this section actually about backward compatibility?

---

Section 6

Don't you think that revealing additional information about component
links and allowing additional control is an additional security risk?
Therefore, the implementation of this I-D increases the need to consider
implementing and deploying RSVP-TE security mechanisms.

You should make reference to RFC 5920.


---

Section 7

It would be really helpful if you named the registries from which you
want assignments made so that IANA can work it out.

---

Section 7

  o) A new "Component Link Recording desired" flag (value TBD)
      of the LSP_ATTRIBUTES object [RFC5420]

The registry requires that you supply...

  Bit No
  Name
  Attribute Flags Path
  Attribute Flags Resv
  RRO

2010-10-29
10 Adrian Farrel Pending discussions with WG chairs
2010-10-29
10 Adrian Farrel State changed to AD Evaluation::External Party from AD Evaluation by Adrian Farrel
2010-10-29
10 Adrian Farrel State changed to AD Evaluation from Publication Requested by Adrian Farrel
2010-10-25
10 Cindy Morgan State changed to Publication Requested from AD is watching by Cindy Morgan
2010-10-25
10 Cindy Morgan [Note]: changed to 'Loa Andersson (loa@pi.nu) is the Document Shepherd' by Cindy Morgan
2010-10-25
10 Cindy Morgan
> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>    …
> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.


> (1.b) Has the document had adequate review both from key WG members
>      and from key non-WG members? Does the Document Shepherd have
>      any concerns about the depth or breadth of the reviews that
>      have been performed?

The document has been reviewed in the MPLS and CCAMP working groups
after being returned to the MPLS working group, mostly becasue of the
MPLS working group by the AD. A result of the joint MPLS and CCAMP
review was an agreement to request that the document is published
as experimental RFC.

No concerns.

The shephered is convinced that this is sufficient review for this
document.


> (1.c) Does the Document Shepherd have concerns that the document
>      needs more review from a particular or broader perspective,
>      e.g., security, operational complexity, someone familiar with
>      AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is no IPR claim for this draft.



> (1.e) How solid is the WG consensus behind this document? Does it
>      represent the strong concurrence of a few individuals, with
>      others being silent, or does the WG as a whole understand and
>      agree with it?

The support in the working group is good to publish the document as
an experimental RFC.



> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent? If so, please summarise the areas of conflict in
>      separate email messages to the Responsible Area Director. (It
>      should be in a separate email because this questionnaire is
>      entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

The nits tool does not report any nits.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There is well written IANA considerations section the document, requesting
three Component Interface Identifier RRO subobject of the Record Route
Object (RRO).

Three Component Interface Identifier subobject of the Explicit Route
Object (ERO).

A new "Component Link Recording desired" flag of the LSP_ATTRIBUTES
object.



> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary


  Link Bundling is used to improve routing scalability by reducing
  the amount of TE related information that needs to be flooded and
  handled by IGP in a TE network. This is accomplished by aggregating
  and abstracting the TE Link resource.

  When link bundling is used to aggregate multiple component links into
  a TE link, label is not the only resource that needs to be identified
  and recorded.

  For the bundled TE link case, in order to fully specify the resources
  on a link for a given LSP, the component link needs to be specified along
  with the label. In the case of bi-directional LSPs both upstream and
  downstream information may be specified. Therefore, explicit resource
  control and recording over a bundled TE link also requires ability to
  specify a component link within the TE link.

  This draft defines extensions to and describes the use of RSVP-TE
  to specify the component link identifier for resource recording
  and explicit resource control over TE link bundles.

  The document, defines component interface identifier RRO and ERO subobjects
  defined to complement their Label RRO and ERO counterparts along with
  procedures for processing component interface identifier RRO and ERO subobjects
  and how they can co-exist with the Label RRO and ERO subobjects are specified.



Working Group Summary

  The document is a product of the MPLS working group, it has been along
  for some time and the working group has agreed to publish it as  an
  experimental RFC in order to gain more experience.

Document Quality

The document has been reviewed in the MPLS and CCAMP working groups.

2010-10-25
10 Cindy Morgan Intended Status has been changed to Experimental from Proposed Standard by Cindy Morgan
2010-10-25
08 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-08.txt
2010-05-31
10 Cindy Morgan State Changes to AD is watching from Dead by Cindy Morgan
2010-05-31
07 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-07.txt
2010-05-21
10 (System) Document has expired
2010-05-21
10 (System) State Changes to Dead from AD is watching by system
2010-01-16
10 Adrian Farrel Draft moved to AD Watching state while WG chairs resolve questions from the AD.
2010-01-16
10 Adrian Farrel State Changes to AD is watching from AD Evaluation by Adrian Farrel
2009-12-28
10 Adrian Farrel State Changes to AD Evaluation from Publication Requested by Adrian Farrel
2009-11-30
10 Cindy Morgan
  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the …
  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Martin Vigoureux (martin.vigoureux@alcatel-lucent.com), Secretary to the MPLS WG,
is the Document Shepherd for draft-ietf-mpls-explicit-resource-control-bundle.
The Document Shepherd personally reviewed the Document and believes
this version (06) is ready for forwarding to the IESG for publication.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The Document had adequate review. The Document was both presented at MPLS
and CCAMP Working Group sessions and discussed on MPLS and CCAMP mailing
lists.
The Document Shepherd does not have any concern with the depth
or breadth of the reviews.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

The Document Shepherd does not have specific concerns with regards to the
need for a broader review. The Document may nevertheless be reviewed
by the Security Directorate as the Document states that security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant while it does not introduce new security issues.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The Document Shepherd does not have any issue nor concern with the Document.
No IPR disclosure related to the Document has been filed.


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The consensus is solid. Various support was openly expressed for
the adoption of the Document as an MPLS WG document, for example.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No strong or extreme position was raised against the Document.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The Document Shepherd personally verified document satisfies all ID nits,
and it does.
The Document does not contain content that would need specific review,
beyond what has already been done up to now.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The Document has two References sections (Normative and Informative).
The Normative Section only includes documents which are either in
RFC or STD status. There are no normative downward references.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The Document has an appropriate IANA Section. The Document does
specify protocol extensions and the reservations are requested in
the appropriate existing IANA registry. The requested values fall
in the range of values to be assigned by Standards Action.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No section of the Document is written -and would need to be written- in
a given formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

Record Route is a useful administrative tool that has been used
extensively by the service providers. However, when TE links are
bundled, identification of label resource in Record Route Object
(RRO) is not enough for the administrative purpose. Network service
providers would like to know the component link within a TE link that
is being used by a given LSP. In other words, when link bundling is
used, resource recording requires mechanisms to specify the component
link identifier, along with the TE link identifier and Label. As it
is not possible to record component link in the RRO, this draft
defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify
component link identifiers for resource recording purposes.

This draft also defines the Explicit Route Object (ERO) counterpart
of the RRO extension. The ERO extensions are needed to perform
explicit label/ resource control over bundled TE link. Hence, this
document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to
specify component link identifiers for explicit resource control and
recording over TE link bundles.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

Nothing worth noting. Good consensus.


          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

The quality of the document is satisfactory as well as the review.
One implementation has been reported.


          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Martin Vigoureux is the Document Shepherd
Adrian Farrel is the responsible Area Director
The IANA Expert(s) for the registries in this document are .
2009-11-30
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-11-30
10 Cindy Morgan [Note]: 'Martin Vigoureux (martin.vigoureux@alcatel-lucent.com) is the Document Shepherd' added by Cindy Morgan
2009-11-18
06 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-06.txt
2009-03-09
05 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-05.txt
2008-07-06
04 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-04.txt
2008-04-02
03 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-03.txt
2006-10-23
02 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-02.txt
2006-02-27
01 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-01.txt
2005-09-12
00 (System) New version available: draft-ietf-mpls-explicit-resource-control-bundle-00.txt