The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-09-26
|
06 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-09-26
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-09-25
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-09-25
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-09-25
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-09-25
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-09-25
|
06 | Suresh Krishnan | Request for Last Call review by GENART Completed: Ready. Reviewer: Suresh Krishnan. |
2012-09-24
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-09-21
|
06 | (System) | IANA Action state changed to In Progress |
2012-09-21
|
06 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-09-21
|
06 | Amy Vezza | IESG has approved the document |
2012-09-21
|
06 | Amy Vezza | Closed "Approve" ballot |
2012-09-21
|
06 | Adrian Farrel | Ballot approval text was generated |
2012-09-21
|
06 | Adrian Farrel | Ballot approval text was generated |
2012-09-21
|
06 | Adrian Farrel | Ballot writeup was changed |
2012-09-20
|
06 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-09-13
|
06 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-09-13
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-09-12
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-09-12
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-09-12
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-09-12
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-09-12
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-09-12
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-09-12
|
06 | Stewart Bryant | [Ballot comment] I am voting Yes on this useful and mainly well written document, however I do have some comments that I would request that … [Ballot comment] I am voting Yes on this useful and mainly well written document, however I do have some comments that I would request that the authors and responsible AD consider. In section 4.1 "If an ingress X chooses" I think that is an ingress LSR (although you define it later this is the first time we meet "X") ==== "This is to avoid jitter, latency and re-ordering issues for the flow." Re-order for sure, but I don't see how jitter and latency come into play. ======= "1. at the ingress LSR, MPLS encapsulation hasn't yet occurred, so deep inspection is not necessary;" Some people would consider a network layer device looking at the transport headers to do ECMP as a DPI. ======= "On the other hand, an ingress LSR (e.g., a PE router) has detailed knowledge of an packet's contents, typically through a priori configuration of the encapsulation(s) that are expected at a given PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They also have more flexible forwarding hardware." The last sentence is disputable because it is highly implementation dependent. There are ASIC and even Network Processor based PEs that will not be able to push as the extra labels. I would delete the last sentence. ======= 3. Entropy Labels and Their Structure Entropy labels are generated by an ingress LSR, based entirely on load balancing information. However, they MUST NOT have values in the reserved label space (0-15) [IANA MPLS Label Values]. Did I miss this reference to [IANA MPLS Label Values]? ======= "for multicast LSPs will be specified in a companion document." Companion or future? I don't think it is yet a WG draft ======= Section 8.1, 8.2 and 8.3 are quite hard to follow. They are only informational, so it would probably be better if they were in an appendix, so that any errors will not impact the protocol definition. It would also really help the reader if some text were provided in each case explaining what is happening. Once the first example has been explained in detail, many of the others just need text describing the delta. |
2012-09-12
|
06 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2012-09-11
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-09-11
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-09-11
|
06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-09-10
|
06 | Stephen Farrell | [Ballot comment] Security considerations: if the EL value is calculated only based on packet headers then a relatively efficient wiretapping interface could be added depending … [Ballot comment] Security considerations: if the EL value is calculated only based on packet headers then a relatively efficient wiretapping interface could be added depending on the function used to generate the EL value. If a network didn't want that to be possible or too easy then it could add some other input to the generation of the EL values that'd make it harder to build a table of EL values to tap given knowledge of the keys from the packet. For example the ingress LSR could generate a random input to the EL generation process every so often. I've no idea if that's practical nor worth inclusion but thought I'd mention it anyway just in case. |
2012-09-10
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-09-10
|
06 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-09-10
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-09-06
|
06 | Adrian Farrel | Ballot writeup was changed |
2012-09-06
|
06 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2012-09-06
|
06 | Adrian Farrel | Ballot has been issued |
2012-09-06
|
06 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2012-09-06
|
06 | Adrian Farrel | Created "Approve" ballot |
2012-09-06
|
06 | Adrian Farrel | Placed on agenda for telechat - 2012-09-13 |
2012-09-05
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-09-05
|
06 | Kireeti Kompella | New version available: draft-ietf-mpls-entropy-label-06.txt |
2012-09-03
|
05 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-09-03
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-08-28
|
05 | Pearl Liang | IANA has reviewed draft-ietf-mpls-entropy-label-05 and has the following comments: IANA understands that, upon approval of this document, there are four actions which IANA must complete. … IANA has reviewed draft-ietf-mpls-entropy-label-05 and has the following comments: IANA understands that, upon approval of this document, there are four actions which IANA must complete. First in the Multiprotocol Label Switching Architecture (MPLS) Label Values registry located at: http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xml a new label value will be registered as follows: Value: { TBD ] Description: Entropy Label Indicator (ELI) Reference: [ RFC-to-be ] Second, in the LDP TLV Type Name Space subregistry of the Label Distribution Parameters registry located at: http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xml a new TLV Type will be registered as follows: Range: [ TBD ] Description: Entropy Label Capability TLV Reference: [ RFC-to-be ] Notes/Registration Date: [ TBD ] Third, in the BGP Path Attributes subregistry of the Border Gateway Protocol Parameters registry located at: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml a new path attribute will be added as follows: Value: [ TBD ] Code: BGP Entropy Label Capability Attribute Reference: [ RFC-to-be ] Fourth, in the Attribute Flags subregistry of the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at: http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml a new Attribute Flag is to be registerred as follows: Bit | Name | Attribute | Attribute | RRO | No | | Flags Path | Flags Resv | | Reference ----+--------------------------+------------+------------+-----|-------------- TBD Entropy Label Capability Yes Yes No [ RFC-to-be ] IANA understands that these four actions are the only ones that need to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-08-23
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-08-23
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2012-08-21
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2012-08-21
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2012-08-20
|
05 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Use of Entropy Labels in … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Use of Entropy Labels in MPLS Forwarding) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'The Use of Entropy Labels in MPLS Forwarding' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209 and 5036. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1797/ http://datatracker.ietf.org/ipr/1605/ http://datatracker.ietf.org/ipr/1789/ |
2012-08-20
|
05 | Cindy Morgan | State changed to Last Call Requested from None |
2012-08-20
|
05 | Cindy Morgan | Last call announcement was changed |
2012-08-20
|
05 | Cindy Morgan | Last call announcement was generated |
2012-08-19
|
05 | Adrian Farrel | Last call was requested |
2012-08-19
|
05 | Adrian Farrel | Ballot approval text was generated |
2012-08-19
|
05 | Adrian Farrel | State changed to AD Evaluation from AD Followup |
2012-08-19
|
05 | Adrian Farrel | Last call announcement was changed |
2012-08-19
|
05 | Adrian Farrel | Last call announcement was generated |
2012-08-19
|
05 | Adrian Farrel | Last call announcement was generated |
2012-08-19
|
05 | Adrian Farrel | Last call announcement was generated |
2012-08-17
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-08-17
|
05 | Kireeti Kompella | New version available: draft-ietf-mpls-entropy-label-05.txt |
2012-08-16
|
04 | Adrian Farrel | AD Review Hi, I have conducted my usual review of this draft before it moves on for IETF last call and IESG evaluation. The purpose … AD Review Hi, I have conducted my usual review of this draft before it moves on for IETF last call and IESG evaluation. The purpose of the review is to check that the document is ready to be published as an RFC and to try to dig out any nits that should be resolved before wider review. I am very impressed with the readability of this document and thank the authors for their work so far. There are a number of minor nits and small technical questions. I considered leaving these to be handled during IETF last call, but I think there are enough of them that we should get them fixed in a new revision before progressing further. Please feel free to debate any of the points with me. Can you please make a new revision, and as soon as I see it I will start the last call. Thanks, Adrian === Please fix the following idnits -- The draft header indicates that this document updates RFC5036, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3031, but the abstract doesn't seem to mention this, which it should. == Unused Reference: 'RFC4364' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'RFC4762' is defined on line 961, but no explicit reference was found in the text --- Need to expand a number of acronyms on first use because they show up before Section 1.1 LSR You need to add the following acronyms to Section 1.1 LSP PW --- Section 1.2 s/MPLS is very/MPLS is a very/ s/most notably: IP, PWE3/most notably: IP, PWs/ (in fact, in most cases s/PWE3/PW/) --- Section 3 The CoS field of an entropy label can be set to any value deemed appropriate. and The CoS field can be set to any value deemed appropriate; typically, this will be the value in the label above the ELI in the label stack. The field (formerly the EXP bits) is now known as the TC field per RFC 5462. --- Section 3 This is accomplished by REQUIRING that the label That is not a 2119 word. Try... To accomplish this, it is REQUIRED that the label --- Somewhere in the document you need to say what would happen if a legacy node accidentally received an ELI. I think the answer is easy: there is no label mapping for the received label, so the packet is dropped per section 3.18 of RFC 3031. It would be helpful to say this in Section 4.1. --- Section 4.2 1. On an incoming packet, identify the application to which the packet belongs, and thereby pick the fields to input to the load balancing function; call the output LB. I think "LB" is load balancing function. Suggest... 1. On an incoming packet, identify the application to which the packet belongs, and thereby pick the fields to input to the load balancing function (LB); call the output LB. --- Section 4.2 4. If, for the chosen tunnel, Y has not indicated that it can process ELs, push onto the packet. If Y has indicated that it can process ELs for the tunnel, push onto the packet. X SHOULD put the same TTL and TC fields for the ELI as it does for TL. The TTL for the EL MUST be zero. The TC for the EL may be any value. Why is this "SHOULD". Under what conditions MAY this be varied? --- 4.4. Penultimate Hop LSR No change is needed at penultimate hop LSRs. I'm not clear about this. Consider a simple tunnel carrying IP. Before using the entropy label, PHP was a pop-and-go function such that the whole MPLS header (including BoS) was stripped and only a native IP packet was forwarded onto the final hop of the LSP. The implication in what you write is that for when the entropy label is used, the forwarded packet will contain ELI and EL. Surely you want to strip them as well? Otherwise a router that did not previously handle MPLS headers will suddenly need to. I know that signaling (as described) will enable the egress to say whether it can handle EL, but I am not sure that helps. So the rule would be that whenever you pop a label that is immediately followed by ELI, you must also pop ELI and EL. |
2012-08-16
|
04 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-08-15
|
04 | Adrian Farrel | Ballot writeup was changed |
2012-08-15
|
04 | Adrian Farrel | Ballot writeup was generated |
2012-08-15
|
04 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2012-08-09
|
04 | Amy Vezza | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The MPLS working group request that: The Use of Entropy Labels in MPLS Forwarding draft-ietf-mpls-entropy-label-04 is published as an RFC on the standards track. (2) 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 Load balancing, or multi-pathing, is an attempt to balance traffic across a network by allowing the traffic to use multiple paths. Load balancing has several benefits: it eases capacity planning; it can help absorb traffic surges by spreading them across multiple paths; it allows better resilience by offering alternate paths in the event of a link or node failure. As providers scale their networks, they use several techniques to achieve greater bandwidth between nodes. Two widely used techniques are: Link Aggregation Group (LAG) and Equal-Cost Multi-Path (ECMP). For MPLS networks, most of the same tecniques apply. However, finding useful keys in a packet for the purpose of load balancing can be more of a challenge. In many cases, MPLS encapsulation may require fairly deep inspection of packets to find these keys at transit LSRs. One way to eliminate the need for this deep inspection is to have the ingress LSR of an MPLS Label Switched Path extract the appropriate keys from a given packet, input them to its load balancing function, and place the result in an additional label, termed the 'entropy label', as part of the MPLS label stack it pushes onto that packet. This docuement assumes that a method are used by the ingress nodes, e.g. use certain fields, termed 'keys', within a packet's header as input to a load balancing function (typically a hash function) that selects the path for all packets in a given flow. For MPLS networks this document specifies how an entropy and entropy label indicator is introduced into the label stack. In MPLS networks the packet's MPLS entire label stack can then be used by transit LSRs to perform load balancing, as the entropy label introduces the right level of "entropy" into the label stack. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has a strong support in the working group and has been well reviewed. We have had good discussions both on the mailing list and at the meeting in Paris. The working last call high-lighted an issues, that was decided to not have an effect on this draft, but the working group chairs has initiated a separate discussion that were started at the Vancouver meeting. This is has to do with how an LSRs should behave if it can't inspect the entire label stack and how the use of entropy labels will cooperate with MPLS OAM.. 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? We know of one implementation, that yet has to be completed; and sevral vendors has indicated that they intend to implement this specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document shepherd. Adrian Farrel is/will be the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd have reviewed the document several times, e.g. when it was polled to become a wg document and at the wg last call, and one time in between. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No such concerns! (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. There are IPRs filed against this document. Before the working group last call started the working group chairs sent a mail to the working group and the authors, asking any members of the working group whom were aware of IPRs to speak up and requiring the authors either to indicate if they were aware of IPRs or say that they were not. The IPR claims has not been explicitly discussed on the wg mailing list, but the working group has been made aware of the IPR claims. All the authors said they were not aware of IPRs, the working group chairs has taken these statement as "We are not aware of any other IPR claims, then those that has already been filed." (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are three IPR claims filed for this document, two from IPR holders and one from a third party. (9) 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 working group is behind this document. It has been well discussed and reviewed. (10) 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 publicly available.) No such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The idnits-tool flags three "problems" 1. a number of "unused references" or "looks like references", between lines 704 and 825. The background is that when the behavior of the entropy label in different scenarios is described the the authors use "[" and "]", which causes the nits tool to believe this is references. 2. The document header says that this document updates RFC 3031 and RFC 5036, but this is not mentioned in the abstract. 3. there are there "Unused references" RFC4364, RFC4761 and RFC4762. They are defined in the reference section, but not used in the text. The authors will be required to fix this if a new version is need or it will be captured in a RFC Editors note. No other nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no such formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? No, all references, both normative and informative are to existing RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downward references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. RFC 3031 and and RFC 5036 will be updated, they are listed in the title page header, but there is no discussion on this in the abstract. This is discussed in the Introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document requests four new IANA allocations: - One Reserved Label for Entropy Label Indicator form the "Multiprotocol Label Switching Architecture (MPLS) Label Values" Registry. - One "LDP Entropy Label Capability TLV" from the IETF Consensus range in the LDP TLV Type Name Space Registry as the "Entropy Label Capability TLV". - One "BGP Entropy Label Capability Attribute" from Path Attribute Type Code from the "BGP Path Attributes" registry as the "BGP Entropy Label Capability Attribute". - One "RSVP-TE Entropy Label Capability flag" from the "Attribute Flags" from "RSVP TE Parameters" registry. All these allocation are well discussed in the working group. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language. |
2012-08-09
|
04 | Amy Vezza | Note added 'Loa Andersson (loa@pi.nu) is the document shepherd.' |
2012-08-09
|
04 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-08-09
|
04 | Amy Vezza | IESG process started in state Publication Requested |
2012-08-09
|
04 | (System) | Earlier history may be found in the Comment Log for draft-kompella-mpls-entropy-label |
2012-07-16
|
04 | Kireeti Kompella | New version available: draft-ietf-mpls-entropy-label-04.txt |
2012-06-13
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-entropy-label-03 | |
2012-05-26
|
(System) | Posted related IPR disclosure: Adrian Farrel's Statement about IPR related to draft-ietf-mpls-entropy-label-03 belonging to Cisco Systems | |
2012-05-09
|
03 | Stephanie McCammon | New version available: draft-ietf-mpls-entropy-label-03.txt |
2012-05-07
|
02 | Kireeti Kompella | New version available: draft-ietf-mpls-entropy-label-02.txt |
2011-10-31
|
01 | (System) | New version available: draft-ietf-mpls-entropy-label-01.txt |
2011-08-11
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-entropy-label-00 | |
2011-05-04
|
00 | (System) | New version available: draft-ietf-mpls-entropy-label-00.txt |