Hi Elwyn,
Thanks for your prompt response. Attached is a new revision which reflects your
comments and suggestions, please let me know if this revision is OK to
progress, thanks.
Hi Lou,
Thanks for your suggestion.
In this new revision the text about valid ERO subobject types is revised a bit,
as I noticed the type value of "label" (3) is also less than 32, while it may
not be used to identify a loopback target.
Currently the IANA allocation rules for 5-31 is not changed by this revision.
If you think this change is needed, I can update the draft before submission.
Thanks.
Cheers,
Jie
> -----Original Message-----
> From: Elwyn Davies [mailto:[email protected]]
> Sent: Thursday, February 26, 2015 2:14 AM
> To: Dongjie (Jimmy); General area reviewing team
> Cc: [email protected]
> Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
>
> Hi, Jie.
>
> I think we are almost done.
>
> There is a proposal for the specific types at the end.
>
> Cheers,
> Elwyn
>
>
>
> On 25/02/2015 06:10, Dongjie (Jimmy) wrote:
> > Hi Elwyn,
> >
> > Thanks a lot for your response. Please see my replies inline:
> >
> > Best regards,
> > Jie
> >
> >>>> s3.2, para 2:
> >>>> OLD:
> >>>> The ingress MUST ensure that the desired loopback mode is
> >>>> strictly identified in the ERO.
> >>>>
> >>>> Am I right that "mode" is a typo? Should it be "node" rather than
> >>>> "mode? I couldn't see anything about "loopback modes" in RFC 5860
> >>>> or RFC 6371. After much head scratching I came to the conclusion that
> "node"
> >>>> was the right answer... If not then please explain where modes are
> defined.
> >>> I guess we may not call it a typo. The above sentence was added
> >>> during the
> >> WG review, the intention was to strictly identify the entity at which
> >> the loopback is desired, which can be either a node or an interface of a
> node.
> >>> If we replace "mode" with "entity", do you think it can be clearer?
> >>>
> >>>> Continuing on the basis that the word s/b "node"... I think this would
> >>>> be clearer as follows:
> >>>> NEW
> >>>> The ingress node MUST ensure that the node where loopback is
> >>>> intended to occur is marked as a strict hop (i.e., not a loose hop) in
> >>>> the
> ERO.
> >>> If you agree with the above change, in your suggestion we can also
> >>> substitute
> >> "node" with "entity".
> >> That would help. How about:
> >> NEW (mk 2):
> >>
> >> The ingress node MUST ensure that the entity (node or interface), at
> >> which loopback is intended to occur, is marked as a strict hop (i.e.,
> >> not a loose hop) in the ERO type subobject.
> > Agree with this description. Will update in the new revision.
> Fine.
> >
> >>> The prior subobject of "ERO Hop Attributes subobject" would also be
> >>> ERO
> >> subobject which identifies the target entity of loopback. As
> >> specified in the sentence below, the type value of the prior
> >> subobject ensures the prior subobject would be an IP prefix or an
> >> interface ID, which can identify the node or interface at which
> >> loopback is desired. Note that the current description requires both
> >> the "ERO Hop Attributes subobject" and the prior subobject have the L
> >> bit set to 0 to ensure that the two subobjects together strictly specify a
> loopback request on an specific entity (node or interface).
> >>> We can rephrase to make it clearer.
> >> I have looked into this issue a bit more deeply, and realize that my
> >> problem is not really with this draft but, at least partly, with
> >> draft-ietf-teas-lsp-attribute-ro-01. Having gone back to RFC3209, I
> >> understand that the subobjects in an ERO as defined there are all
> >> specifiers for type of 'entity' that could be waypoints on the
> >> explicit route. There is no allowance for other types of subobject
> >> (such as the attribute subobjects being introduced by
> >> draft-ietf-teas-lsp-attribute-ro-01). As introduced in RFC 3209,
> >> both EROs and RROs contained only entity type subobjects, but RFC
> >> 5420 changed this for *RROs only* by introducing RRO Attributes
> >> subobjects which could be inserted between the type subobjects. Thus
> >> as standardized currently, EROs aren't allowed any other sort of subobject
> and there is no equivalent to the "Presence Rules" defined for RROs in RFC
> 5420
> section 7.3.1.
> >>
> >> draft-ietf-teas-lsp-attribute-ro-01 updates the presence rules for
> >> RROs to allow for the RRO Hop Attributes subobjects but the necessary
> >> presence rules that would control where the ERO HOP Attributes could
> >> be inserted are not properly defined in
> >> draft-ietf-teas-lsp-attribute-ro-01. Para 1 of s2.3 of
> >> draft-ietf-teas-lsp-attribute-ro-01 seems to indicate that the HOP
> >> Attributes would be placed after all the type subobjects which
> >> doesn't seem right. I would have thought that the hop attributes
> >> needed to be interleaved between the type subobjects - and I think
> >> that is what the existing text in the lock draft is trying to say.
> >>
> >> So I think the draft-ietf-teas-lsp-attribute-ro-01 needs to be
> >> clarified
> >> - a specific section on Presence Rules as in RFC 5420 would help.
> >>
> >> The text about checking that the L bit in the lock draft is
> >> confusing, because the L bit is *required* by
> >> draft-ietf-teas-lsp-attribute-ro-01
> >> to be 0 in *all* Hop Attributes subobjects whether they are
> >> associated with loose or strict hops and need not be mentioned. The
> >> L bit is only set in the type subobject if it is a loose hop so the check
> >> should
> be
> >> that the type subobject has its L bit clear. It should also be made
> >> clearer in the lock draft that there can be multiple Hop Attribute
> >> subobjects after the type subobject.
> >>
> >> I hope this helps.
> > You are correct, the L bit in the ERO hop attributes subobject must be 0,
> > thus
> we would only specify that the L bit in the prior ERO subobject MUST be set
> to 0
> in the new revision.
> OK.
> >
> > As for the rules about multiple Hop Attribute subobjects in ERO, IMO maybe
> > it
> is more suitable to be specified in draft-ietf-teas-lsp-attribute-ro, but we
> can
> also add such descriptions if you think they belongs to this draft.
> I will negotiate with the authors of draft-ietf-teas-lsp-attribute-ro to see
> if we
> can agree a revision.
> >
> >>>> s3.2, para 3:
> >>>>> Currently, the type value MUST be verified to be
> >>>>> less than 32, and for type values 1 and 2 the prefix length MUST be
> >>>>> 32 and 128 respectively.
> >>>> It would be better to use the names of the types (1 = IPv4, 2 =
> >>>> IPv6) that would make it clearer why the lengths are as they are
> >>>> specified.
> >>>> Is it possible to explain why the type has to be less than this
> >>>> apparently arbitrary limit of 32? And hence what allocation
> >>>> constraints ought to be applied in the future - this might need a
> >>>> change in the IANA allocation rules that should be specified in this
> document.
> >>> The limit of 32 was to ensure the subobject type can identify a
> >>> specific node
> >> or interface. Maybe we can specify the required types (node,
> >> interface) explicitly to make it clear.
> >> That would help.
> >> It has just occurred to me why you want to say that the prefix
> >> lengths are
> >> 32/128 bits - so that the IP address refers to exactly one node.
> >> However this is possibly confusing because RFC 3209 *requires* the
> >> values to be 32/128 respectively and the subobjects do carry just a
> >> host address and not a domain prefix as might be implied by lower values.
> > As specified in 4.3.3 of RFC 3209, for the ERO subobjects, the prefix
> > lengths
> are not required to be just 32/128. While as specified in 4.4.1 of RFC 3209,
> for
> the RRO subobjects, the prefix lengths are required to be 32/128.
> You are right: I missed that RRO and ERO were different. So specifying the
> prefix lengths is indeed needed as you say.
> >
> >> I noted having looked again at the registry [1], and it appears that
> >> nobody has yet defined an ERO type for 4 octet AS numbers which have
> >> now
> >> (finally) been standardized. This might mean that 32 was not the
> >> right boundary. Perhaps this means that you need to define an update
> >> to the allocation rules for the registry so that values below (say)
> >> 32 are required to identify exactly one physical node and not an
> >> abstract node with potentially many physical nodes.
> > Thanks for your suggestion. Since this draft just want to restrict the type
> > of
> ERO subobjects that can appear prior to the ERO hop attributes subobject,
> making such update to IANA was not our original intention, also requires
> discussion with ADs and TEAS chairs.
> >
> > What about we specify the allowed ERO subobject types explicitly, similar to
> 6.1.1 of RFC 4990? The specification could be something like:
> >
> > The prior subobject MUST be able to identify a specific node or interface,
> specifically it MUST be one of the following: type "IPv4 prefix" with prefix
> length 32, type "IPv6 prefix" with prefix length 128, or type "Unnumbered
> Interface ID".
> That would certainly cover the situation as it is at the moment. I can't
> immediately think of any new types that might be added and would be relevant
> as loopback points, but you might have some ideas on this.
> I was trying to think of an easy way to factor this into the IANA registration
> process but I can't see anything very simple. I think a few 'weasel words'
> will do
> for an unlikely event. How about:
> NEW mk 3:
> The prior subobject MUST be able to identify a specific node or interface,
> specifically, at the time of writing, it can be one of the
> following:
> - Type "IPv4 prefix" with prefix length 32,
> - Type "IPv6 prefix" with prefix length 128, or
> - Type "Unnumbered Interface ID".
> If any new subobject types are defined in future and they identify a specific
> node or interface, the specification of the new type can extend this list.
>
>
> >> [1]
> >> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#r
> >> svp-
> >> parameters-25
Network Working Group J. Dong
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: August 29, 2015 Z. Li
China Mobile
D. Ceccarelli
Ericsson
February 25, 2015
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
draft-ietf-teas-rsvp-te-li-lb-04
Abstract
This document specifies extensions to Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
Loopback (LB) mechanisms for Label Switched Paths (LSPs). These
mechanisms are applicable to technologies which use Generalized
Multi-Protocol Label Switching (GMPLS) for the control plane.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2015.
Dong, et al. Expires August 29, 2015 [Page 1]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 4
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in the
Multiprotocol Label Switching Transport Profile (MPLS-TP) are
specified in [RFC5860], and the framework of LI and LB is specified
in [RFC6371]. An LSP that is locked, using LI, is prevented from
carrying user data traffic. The LB function can only be applied to
an LSP that has been previously locked.
In general the LI and LB are useful Operations, Administration and
Maintenance (OAM) functions for technologies which use Generalized
Multi-Protocol Label Switching (GMPLS) for the control plane, e.g.,
time-division multiplexing, wavelength-division multiplexing and
packet switching. It is natural to use and extend the GMPLS control
Dong, et al. Expires August 29, 2015 [Page 2]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
plane protocol to provide a unified approach for LI and LB
provisioning in all these technologies.
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE
extensions for the configuration of pro-active MPLS-TP OAM functions,
such as Continuity Check (CC), Connectivity Verification (CV), Delay
Measurement (DM) and Loss Measurement (LM). The provisioning of on-
demand OAM functions such as LI and LB are not covered in that
document.
This document specifies extensions to Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) to support lock instruct and loopback
mechanisms for Label Switched Paths (LSPs). The mechanisms are
applicable to technologies which use GMPLS for the control plane.
For a network supporting MPLS-TP, the mechanisms defined in this
document are complementary to [RFC6435].
2. Flag Definitions for LI and LB
2.1. Lock Instruct Indication
In order to indicate the lock/unlock status of the LSP, the A
(Administratively down) bit in the Administrative Status
(ADMIN_STATUS) object [RFC3471] [RFC3473] is used.
2.2. Extensions for Loopback
In order to indicate the loopback mode of LSP, a new bit flag is
defined in the Attribute Flags TLV [RFC5420].
Loopback flag:
This flag indicates a particular node on the LSP is required to
enter loopback mode. This can also be used for specifying the
loopback state of the node.
- Bit number: TBA-1
- Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No
- Attribute flag carried in RRO Attributes subobject: Yes
Dong, et al. Expires August 29, 2015 [Page 3]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
3. Operational Procedures
3.1. Lock Instruct
When an ingress node intends to put an LSP into lock mode, it MUST
send a Path message with the Administratively down (A) bit used as
specified above and the Reflect (R) bit in the ADMIN_STATUS Object
set.
On receipt of this Path message, the egress node SHOULD try to take
the LSP out of service. If the egress node locks the LSP
successfully, it MUST send a Resv message with the A bit in the
ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Lock Failure", and the following Resv messages MUST be sent with the
A bit cleared.
When an LSP is put in lock mode, the subsequent Path and Resv
messages MUST keep the A bit in the ADMIN_STATUS Object set.
When the ingress node intends to take the LSP out of the lock mode,
it MUST send a Path message with the A bit in the ADMIN_STATUS Object
cleared.
On receipt of this Path message, the egress node SHOULD try to bring
the LSP back to service. If the egress node unlocks the LSP
successfully, it MUST send a Resv message with the A bit in the
ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr
message with the Error Code "OAM Problem" [RFC7260] and the new Error
Value "Unlock Failure", and the following Resv messages MUST be sent
with the A bit set.
When an LSP is taken out of lock mode, the subsequent Path and Resv
messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
3.2. Loopback
The loopback request can be sent either to the egress node or to a
particular intermediate node. The mechanism defined in
[I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback
request to a particular node on the LSP. The ingress node MUST
ensure that the LSP is in lock mode before it requests setting a
particular node on the LSP into loopback mode.
When a ingress node intends to put a particular node on the LSP into
loopback mode, it MUST send a Path message with the Loopback
Attribute Flag defined above in the Attribute Flags TLV set. The
mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to
Dong, et al. Expires August 29, 2015 [Page 4]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
address the loopback request to the particular node. The ingress
node MUST ensure that the entity (node or interface), at which
loopback is intended to occur, is marked as a strict hop in the
Explicit Route object (ERO) subobject. The Administratively down (A)
bit in the ADMIN_STATUS object MUST be kept set to indicate that the
LSP is still in lock mode.
On receipt of this Path message, the target node of the loopback
request MUST check if the LSP is in lock mode by verifying that the
Administratively down (A) bit is set in the ADMIN_STATUS object. If
the bit is not set, the loopback request MUST be ignored.
If the Administratively down (A) bit is set, the node MUST check that
the desired loopback entity is strictly identified by verifying that
the L bit is set to 0 in the ERO subobject prior to the ERO Hop
Attributes subobject. The prior subobject MUST be able to identify a
specific node or interface, specifically, at the time of writing, it
can be one of the following:
o Type "IPv4 prefix" with prefix length 32;
o Type "IPv6 prefix" with prefix length 128;
o Type "Unnumbered Interface ID".
If any new subobject types are defined in future and they identify a
specific node or interface, the specification of the new type can
extend this list.
If the desired loopback entity is not strictly identified, the
request MUST be ignored and a "Bad EXPLICIT_ROUTE object" error
SHOULD be generated. Otherwise, the node SHOULD try to put the LSP
into loopback mode. If the node puts the LSP into loopback mode
successfully, it MUST set the Loopback Attribute Flag if it adds, per
[I-D.ietf-teas-lsp-attribute-ro], an RRO Hop Attributes subobject to
the RECORD_ROUTE Object (RRO) of a Path or Resv message. The
Administratively down (A) bit in the ADMIN_STATUS object MUST be kept
set in the message. If the node cannot put the LSP into loopback
mode, it MUST send a PathErr message with the Error Code "OAM
Problem" [RFC7260] and the new Error Value "Loopback Failure".
When the ingress node intends to take the particular node out of
loopback mode, it MUST send a Path message with the Loopback
Attribute Flag in the Attribute Flags TLV cleared. The mechanism
defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that
the particular node SHOULD exit loopback mode for this LSP. The
Administratively down (A) bit in the ADMIN_STATUS object MUST be kept
set to indicate the LSP is still in lock mode.
Dong, et al. Expires August 29, 2015 [Page 5]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
On receipt of this Path message, the target node SHOULD try to take
the LSP out of loopback mode. If the node takes the LSP out of
loopback mode successfully, it MUST clear the Loopback Attribute Flag
in the RRO Hop Attributes subobject and push this subobject onto the
RRO object in the corresponding Path or Resv message. The
Administratively down (A) Bit in the ADMIN_STATUS Object MUST be kept
set in the message. Otherwise, the node MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Exit Loopback Failure".
After the loopback mode is cleared successfully, the ingress node MAY
remove the Lock Instruct using the mechanism defined in section 3.1.
The ingress node MUST NOT request to exit lock mode if the LSP is
still in loopback mode. The egress node MUST ignore such request
when the LSP is still in loopback mode.
4. IANA Considerations
IANA is requested to administer the assignment of new values defined
in this document and summarized in this section.
4.1. Attribute Flags
IANA maintains a registry called "Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
"Attribute Flags".
IANA is requested to assign a new bit flag as follows:
Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+-------------
TBA-1| Loopback | Yes | No | Yes | Yes |this document
4.2. RSVP Error Value Sub-codes
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Error Codes and
Globally-Defined Error Value Sub-Codes".
IANA is requested to assign four new Error Value sub-codes for the
"OAM Problem" Error Code:
Dong, et al. Expires August 29, 2015 [Page 6]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
Value | Description | Reference
-----------+-----------------------------+--------------
TBA-2 | Lock Failure | this document
TBA-3 | Unlock Failure | this document
TBA-4 | Loopback Failure | this document
TBA-5 | Exit Loopback Failure | this document
5. Security Considerations
This document does not introduce any new security issues above those
identified in [RFC3209] [RFC3473] and
[I-D.ietf-teas-lsp-attribute-ro]. For a more comprehensive
discussion of GMPLS security and attack mitigation techniques, please
see the Security Framework for MPLS and GMPLS Networks [RFC5920].
In addtion, the reporting of the loopback status using the RRO may
reveal details about the node that the operator wishes to remains
confidential. The privacy considerations as described in section 5,
paragraph 3 of [I-D.ietf-teas-lsp-attribute-ro] also applies to this
document.
6. Acknowledgements
The authors would like to thank Greg Mirsky, Lou Berger and Francesco
Fondelli for their comments and suggestions.
7. References
7.1. Normative References
[I-D.ietf-teas-lsp-attribute-ro]
Margaria, C., Martinelli, G., Balls, S., and B. Wright,
"LSP Attribute in ERO", draft-ietf-teas-lsp-attribute-
ro-02 (work in progress), February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
Dong, et al. Expires August 29, 2015 [Page 7]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, June 2014.
7.2. Informative References
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
Skoldstrom, P., and D. Ward, "Configuration of Pro-Active
Operations, Administration, and Maintenance (OAM)
Functions for MPLS-based Transport Networks using RSVP-
TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 (work in
progress), January 2015.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", RFC 6435, November 2011.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: [email protected]
Dong, et al. Expires August 29, 2015 [Page 8]
Internet-Draft RSVP-TE Extensions for LI&LB February 2015
Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: [email protected]
Zhenqiang Li
China Mobile
Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave.
Beijing 100053
China
Email: [email protected]
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: [email protected]
Dong, et al. Expires August 29, 2015 [Page 9]
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
