Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)

From: "Vivek Kumar" <[email-masked]>
Date: Sat, 19 Jan 2013 03:58:15 +0000

Hi David,
  The new text says "The traffic is looped back unmodified  (other than normal per-hop processing such as TTL decrement) in the  direction of the point of origin by an interface at either an  intermediate node or a terminating node".
  I feel if we are mentioning TTL processing as one exception , then we should also mention swapping src and destination Ethernet address when doing loopback  . What do you say ?

Regards,
Vivek

Message: 1
Date: Fri, 18 Jan 2013 20:28:52 +0000
From: Gregory Mirsky <[email-masked]>
To: "Sami Boutros (sboutros)" <[email-masked]>, "David Ball -X
	(daviball	- Ensoft Ltd at Cisco)" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>,	"<[email-masked]>"
	<[email-masked]>,	"<[email-masked]>" <[email-masked]>,
	"Siva Sivabalan \(msiva\)" <[email-masked]>,	"<[email-masked]>"
	<[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Sami,
I think that the "This is done using management." can not and should not be interpreted as "The Loopback function MUST be done via management only." I would ask you to consider changing it to "This can be done using management plane.", thus leaving non-management means for further consideration.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sami Boutros (sboutros)
Sent: Friday, January 18, 2013 6:33 AM
To: David Ball -X (daviball - Ensoft Ltd at Cisco)
Cc: <[email-masked]>; <[email-masked]>; Siva Sivabalan (msiva); <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)

Looks good to me.

I agree that in the new text it is clear that we are not requiring a MIP or MEP at the node that perform the loopback function along the transport path

As well I feel it is clear the way I read it, that

1- A MEP is required as a must at both ends of the transport path to perform the transport path lock function prior to setting up the loopback on a node along the transport path.
2- The Loopback function MUST be done via management only.

If the above is not clear to others while reading the new text, then we may need to update it.

Thanks,

Sami
On Jan 18, 2013, at 4:42 AM, David Ball wrote:

> Hi Adrian,
>
> I think we are done, here is the updated text:
>
> ====
>
> Section 4, paragraphs 2-7; old text:
>
>   The loopback function is used to test the integrity of a transport
>   path from a MEP up any other node in the same MEG.  This is achieved
>   by setting the target node into loopback mode, and transmitting a
>   pattern of test data from the MEP.  The target node loops all
>   received data back toward the originator, and the MEP extracts the
>   test data and compares it with what it sent.
>
>   Loopback is a function that enables a receiving MEP or MIP to return
>   traffic to the sending MEP when in the loopback state.  This state
>   corresponds to the situation where, at a given node, a forwarding
>   plane loop is configured, and the incoming direction of a transport
>   path is cross-connected to the outgoing reverse direction.
>   Therefore, except in the case of early TTL expiry, traffic sent by
>   the source will be received by that source.
>
>   Data-plane loopback is an out-of-service function, as required in
>   Section 2.2.5 of RFC 5860 [1].  This function loops back all traffic
>   (including user data and OAM).  The traffic can be originated from
>   one internal point at the ingress of a transport path within an
>   interface or inserted from an input port of an interface using
>   external test equipment.  The traffic is looped back unmodified
>   (other than normal per-hop processing such as TTL decrement) in the
>   direction of the point of origin by an interface at either an
>   intermediate node or a terminating node.
>
>   It should be noted that the data-plane loopback function itself is
>   applied to data-plane loopback points residing on different
>   interfaces from MIPs/MEPs.  All traffic (including both payload and
>   OAM) received on the looped back interface is sent on the reverse
>   direction of the transport path.
>
>   For data-plane loopback at an intermediate point in a transport path,
>   the loopback needs to be configured to occur at either the ingress or
>   egress interface.  This is done using management.
>
>   The management plane can be used to configure the loopback function.
>   The management plane must ensure that the two MEPs are locked before
>   it requests setting MEP or MIP in the loopback state.
>
> New text:
>
>   The loopback function is used to test the integrity of a transport
>   path from a MEP to any other node along the same transport path.
>   This is achieved by setting the target node into loopback mode for
>   that transport path, and  transmitting a pattern of test data from
>   the MEP.  The target node loops all data received on the transport
>   path back towards the sending MEP, which extracts the test data
>   and compares it with what it sent.
>
>   Loopback is a function that enables a given node on a transport
>   path to return traffic to the sending MEP for that transport path
>   when in the loopback mode.  This mode corresponds to the situation
>   where, at a given node, a forwarding plane loop is configured, and
>   the incoming direction of a transport path is cross-connected to the
>   outgoing reverse direction.  Therefore, except in the case of early
>   TTL expiry, traffic sent by the source will be received by that
>   source.
>
>   Data-plane loopback is an out-of-service function, as required in
>   Section 2.2.5 of RFC 5860 [1].  This function loops back all traffic
>   (including user data and OAM).  The traffic can be originated from
>   one internal point at the ingress of a transport path within an
>   interface or inserted from an input port of an interface using
>   external test equipment.  The traffic is looped back unmodified
>   (other than normal per-hop processing such as TTL decrement) in the
>   direction of the point of origin by an interface at either an
>   intermediate node or a terminating node.
>
>   It should be noted that the data-plane loopback function for a
>   given transport path can be applied to data-plane loopback points
>   residing on interfaces where there may be no MEP or MIP for that
>   transport path.
>
>   For data-plane loopback at an intermediate point in a transport path,
>   the loopback needs to be configured to occur at either the ingress or
>   egress interface.  This is done using management.
>
>   The management plane must ensure that the MEPs at either end of a
>   transport path are locked before it requests setting a given node of
>   that transport path into loopback mode.

>
> Notes:
>
>   The existing text has caused confusion about exactly where the
>   loopback is applied.  It does not clearly express the original
>   intent, which was that there may or may not be a MEP or MIP at the
>   loopback point.  In particular, paragraphs 2 and 7 imply that the
>   loopback point must be at a MEP or MIP, while paragraph 5 implies
>   that loopback is performed at a point where there is no MEP or MIP.
>
>   The new text updates paragraphs 2, 3, 5 and 7 to clarify that the
>   loopback may be performed at any point along the transport path,
>   whether or not there is a MEP or MIP there, and that the loopback
>   only applies to the transport path in question.  Paragraphs 4 and 6
>   are unchanged.
>
> ====
>
>
>       David
>
>

---

From: "Vivek Kumar" <[email-masked]>
Date: Sat, 19 Jan 2013 04:03:06 +0000

Hi David,
 
Sorry . Ignore my previous comment . I said in context of ETH-OAM . It's not applicable here . 

Regards,
vivek

-----Original Message-----
From: Vivek Kumar 
Sent: Saturday, January 19, 2013 9:28 AM
To: [email-masked]
Subject: Re: [Editorial Errata Reported] RFC6435 (3429) 

Hi David,

Regards,
Vivek

Message: 1

Hi Sami,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sami Boutros (sboutros)
Sent: Friday, January 18, 2013 6:33 AM
To: David Ball -X (daviball - Ensoft Ltd at Cisco)
Cc: <[email-masked]>; <[email-masked]>; Siva Sivabalan (msiva); <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429)

Looks good to me.

Thanks,

Sami

---

From: Mach Chen <[email-masked]>
Date: Mon, 21 Jan 2013 02:34:45 +0000

Hi Greg,

I totally agree with you here!

This errata only intends to clarify whether the location of the loopback function should be with MIP/MEP, through the discussion, the consensus is made. We should not change other aspects other than the location issue. 

The last para of the new text says:
  "The management plane must ensure that the MEPs at either end of a 
   transport path are locked before it requests setting a given node of 
   that transport path into loopback mode."

While the original text says:
  "The management plane can be used to configure the loopback function.
   The management plane must ensure that the two MEPs are locked before
   it requests setting MEP or MIP in the loopback state."

It removes "The management plane can be used to configure the loopback function " and implicitly makes that management plane as a "MUST" for loopback function although the original text says "the management plane can be...".  

So, I'd like to suggest to change the last para of the new text as follows:

Old new text:

New text:

Best regards,
Mach

> From: Mach Chen
> Sent: Monday, January 21, 2013 10:03 AM
> To: Mach Chen
> Subject: FW: [Editorial Errata Reported] RFC6435 (3429)
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gregory Mirsky
> Sent: Saturday, January 19, 2013 4:29 AM
> To: Sami Boutros (sboutros); David Ball -X (daviball - Ensoft Ltd at Cisco)
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; Siva
> Sivabalan (msiva); <[email-masked]>
> I think that the "This is done using management." can not and should not be
> interpreted as "The Loopback function MUST be done via management only." I
> would ask you to consider changing it to "This can be done using management
> plane.", thus leaving non-management means for further consideration.
> 
>         Regards,
>                 Greg
> 
> Cc: <[email-masked]>; <[email-masked]>; Siva Sivabalan (msiva);
> <[email-masked]>; <[email-masked]>
> I agree that in the new text it is clear that we are not requiring a MIP or MEP at
> the node that perform the loopback function along the transport path
> 
> 1- A MEP is required as a must at both ends of the transport path to perform
> the transport path lock function prior to setting up the loopback on a node
> along the transport path.
> > On Fri, Jan 18, 2013, Adrian Farrel wrote:
> >> OK, when we are done, can some write me an email that contains the
> >> text that would have been in the Errata Report if we had known then what
> we know now?
> >>
> >> Then I will process the existing report and the new text.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> From: VIGOUREUX, MARTIN (MARTIN)
> >> [mailto:[email-masked]]
> >> Sent: 17 January 2013 20:00
> >> To: David Ball
> >> Cc: [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan
> >> (msiva)'; [email-masked]; [email-masked]; 'Stewart
> >> Bryant (stbryant)'; [email-masked]; 'George Swallow (swallow)';
> >> [email-masked]; [email-masked]
> >> Subject: RE: [Editorial Errata Reported] RFC6435 (3429)
> >>
> >> David,
> >>
> >> Yes it does. Thanks.
> >> I first thought of removing all references to MEP/MIP but should have
> >> given it a second thought.
> >>
> >> -m
> >>  _____
> >>
> >> De : David Ball
> >> Envoy? : 17/01/2013 18:41
> >> ? : VIGOUREUX, MARTIN (MARTIN)
> >> Cc : [email-masked]; 'Sami Boutros (sboutros)'; 'Siva Sivabalan
> >> (msiva)'; [email-masked]; [email-masked]; 'Stewart
> >> Bryant (stbryant)'; [email-masked]; 'George Swallow (swallow)';
> >> [email-masked]; [email-masked] Objet : Re: [Editorial Errata
> >> Reported] RFC6435 (3429) Hi Martin,
> >>
> >> Actually I think the last paragraph is talking about something
> >> different
> >> again: this is the MEPs that must be locked.
> >>
> >> Here is a transport path:
> >>
> >>  |>-------x----------x-------<|
> >>            --------->|
> >>            <---------v
> >>  A        B          C        D
> >>
> >> A and D are the MEPs; B is the source of the test, C is the loopback
> >> point.
> >>
> >> As we have discussed, C could be a MIP, could be the MEP at D, or
> >> could be at a point that is neither a MIP or a MEP.
> >>
> >> A and D are the MEPs that must be locked during the test.
> >>
> >> My question was about point B: I think in the original text point B
> >> must always be the same as the MEP at point A; your proposal allows
> >> it to be some other point, eg at a MIP or at a point where there is
> >> no MIP or MEP.
> >>
> >> If we keep the original text about point B, and just change the text
> >> about point C, then combining with your proposal we get the following
> >> change:
> >>
> >> Old text:
> >>   traffic to the sending MEP when in the loopback state.
> >>
> >>   [...]
> >>
> >>   Loopback is a function that enables a given node of a transport
> >>   when in the loopback mode.
> >>
> >>   [...]
> >>
> >> Does this work?
> >> On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> >>> David,
> >>>
> >>> agreed, and in fact this is consistent with the fact I kept MEP in
> >>> the last paragraph I changed.
> >>>
> >>> -m
> >>>
> >>>
> >>> Le 17/01/2013 18:09, David Ball a ?crit :
> >>>> Thanks Martin.
> >>>>
> >>>> Regarding the first paragraph, I agree with your change to add "for
> >>>> that transport path", that does make it clearer.
> >>>>
> >>>> Regarding the other paragraphs: We have agreed that the intent was
> >>>> that the point doing the loopback does not have to be a MEP or MIP,
> >>>> but your proposal also seems to change it so that the point
> >>>> transmitting the test data does not have to be a MEP.  I think the
> >>>> original text was consistent that the test was done *from* a MEP;
> >>>> the question was whether it was done from a MEP *to another
> >>>> MEP/MIP*, or from a MEP *to an arbitrary point*.
> >>>>
> >>>> So you might be right that the text describing the source of the
> >>>> test should also be changed, but I think that is a slightly separate issue.
> >>>> It is probably safest to keep the changes to a minimum and just fix
> >>>> the description of the point that is doing the loopback, ie the
> >>>> target of the test.
> >>>>
> >>>> Do you agree?
> >>>>
> >>>>
> >>>>    David
> >>>>
> >>>>
> >>>> On Thu, Jan 17, 2013, Martin Vigoureux wrote:
> >>>>> Adrian, yes, we are.
> >>>>>
> >>>>> So, David,
> >>>>>
> >>>>> I am fine with your suggested text which says:
> >>>>>   residing on interfaces where there may be no corresponding MEP
> >>>>>or
> >>>>>   MIP.
> >>>>>
> >>>>> I was thinking of:
> >>>>> s/may be no corresponding MEP or MIP./may be no MEP or MIP for
> >>>>> that transport path./ but this is optional.
> >>>>>
> >>>>> The new text will replace:
> >>>>>   interfaces from MIPs/MEPs.
> >>>>>
> >>>>>
> >>>>> Regarding the other paragraphs:
> >>>>>   traffic to the sending MEP when in the loopback state.
> >>>>>
> >>>>>   [...]
> >>>>>
> >>>>> They could be changed into:
> >>>>>   path.  This is achieved by setting a given node into loopback
> >>>>>mode
> >>>>>   for a given transport path, and sending over it a pattern of
> >>>>>test
> >>>>>   data.  The node in loopback mode loops all test data received on
> >>>>>the
> >>>>>   transport path back towards the sender, which extracts the test
> >>>>>   data and compares it with what it sent.
> >>>>>
> >>>>>   Loopback is a function which enables a given node of a transport
> >>>>>   path, when in the loopback mode, to return traffic to the sender
> >>>>>of
> >>>>>   that traffic.
> >>>>>
> >>>>>   [...]
> >>>>>
> >>>>>   The management plane must ensure that the MEPs of a transport
> >>>>>path
> >>>>>   are locked before it requests setting a given node of that
> >>>>>transport
> >>>>>   path in loopback mode.
> >>>>>
> >>>>> Let me know.
> >>>>> -m
> >>>>>
> >>>>> Le 16/01/2013 22:07, Adrian Farrel a ?crit :
> >>>>>> All, are we getting any closer to agreeing what we all intended to say?
> >>>>>>
> >>>>>> Once we have that, I can work out what to do with the Errata Report.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Adrian
> >>>>>>
> >>>>>>> From: David Ball [mailto:[email-masked]]
> >>>>>>> Sent: 10 January 2013 17:57
> >>>>>>> To: VIGOUREUX, MARTIN (MARTIN)
> >>>>>>> Cc: Sami Boutros (sboutros); [email-masked]; Siva Sivabalan
> >>>>>>> (msiva); [email-masked]; [email-masked]; Stewart
> >>>>>>> Bryant (stbryant); [email-masked]; George Swallow (swallow);
> >>>>>>> [email-masked]; [email-masked]
> >>>>>>> Hi Martin,
> >>>>>>> Ah, right I see: since the loopback is locally configured, there
> >>>>>>> is no need for a MEP/MIP to send/receive OAM frames - but there
> >>>>>>> may be a MEP/MIP.
> >>>>>>>
> >>>>>>> So would this work to clarify the text?
> >>>>>>>  "It should be noted that the data-plane loopback function for a
> >>>>>>>   residing on interfaces where there may be no corresponding MEP
> >>>>>>>or
> >>>>>>>   MIP."
> >>>>>>>
> >>>>>>> For completeness, the references to "MEP or MIP" in paragraphs 3
> >>>>>>> and 7 of section 4 would also need to be changed, to instead
> >>>>>>> refer to the transport path that is being put in to loopback.
> >>>>>>>
> >>>>>>> As another data point, I found this text in RFC6371 section 6.3.2:
> >>>>>>>  "It should be noted that data-plane loopback function itself is
> >>>>>>>   applied to data-plane loopback points that can reside on
> >>>>>>>different
> >>>>>>>   interfaces from MIPs/MEPs."
> >>>>>>> Note the critical difference compared to RFC6435: "that can reside"
> >>>>>>> instead of "residing".
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> David
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jan 09, 2013, VIGOUREUX, MARTIN (MARTIN) wrote:
> >>>>>>>> Sami,
> >>>>>>>>
> >>>>>>>> Thanks. Yet, I am not sure David's interpretation and mine exactly
> match.
> >>>>>>>> David, correct me if I am wrong. For me it says that we can do
> >>>>>>>> loopback on different interfaces (for different LSPs) but
> >>>>>>>> implies that there is a mip/mep for that lsp on that interface,
> >>>>>>>> while my interpretation is that the presence of a mip/mep for
> >>>>>>>> that lsp on that interface is not needed.
> >>>>>>>>
> >>>>>>>> -m
> >>>>>>>> ________________________________ De : Sami Boutros (sboutros)
> >>>>>>>> Envoy? : 09/01/2013 19:00 ? : VIGOUREUX, MARTIN (MARTIN) Cc :
> >>>>>>>> [email-masked]; David Ball -X (daviball - Ensoft Ltd at
> >>>>>>>> Cisco);
> >>>>>> Siva
> >>>>>>> Sivabalan (msiva); [email-masked]; [email-masked];
> >>>>>>> Stewart Bryant (stbryant); [email-masked]; George Swallow (swallow);
> >> [email-masked];
> >>>>>>> [email-masked]
> >>>>>>>> Objet : Re: [Editorial Errata Reported] RFC6435 (3429)
> >>>>>>>>
> >>>>>>>> I agree with Martin, the text proposed by David describe more
> >>>>>>>> accurately
> >>>>>> what
> >>>>>>> we meant.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Sami
> >>>>>>>> On Jan 9, 2013, at 6:18 AM, Martin Vigoureux wrote:
> >>>>>>>>
> >>>>>>>>> Adrian, David,
> >>>>>>>>>
> >>>>>>>>> what I think we meant here was that a loop-back function could
> >>>>>>>>> be done
> >> on
> >>>>>>> an interface regardless of the presence of a MIP/MEP on that
> interface.
> >> Yet, I
> >>>>>>> have to admit that MIP and MEP are used in Section 4 of RFC6435,
> >>>>>>> thus
> >> surely
> >>>>>>> causing confusion.
> >>>>>>>>>
> >>>>>>>>> I'd welcome the views/souvenirs of my co-authors.
> >>>>>>>>>
> >>>>>>>>> -m
> >>>>>>>>>
> >>>>>>>>> Le 12/12/2012 19:17, Adrian Farrel a ?crit :
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> Authors of RFC 6435: I need to hear from you that you meant
> >>>>>>>>>> the text
> >> that
> >>>>>>> David
> >>>>>>>>>> suggests. It is very clearly not what you wrote and, if you
> >>>>>>>>>> meant
> >>>>>> something
> >>>>>>>>>> different, it is clear why people are confused!
> >>>>>>>>>>
> >>>>>>>>>> Working group: I need to hear from you that you agree with
> >>>>>>>>>> David's interpretation and support his proposed change.
> >>>>>>>>>>
> >>>>>>>>>> Only then will I try to work out whether this is a "typo"
> >>>>>>>>>> worthy of an
> >>>>>> errata
> >>>>>>>>>> report, or a technical change needing a revised RFC.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Adrian
> >>>>>>>>>>
> >>>>>>>>>>> From: RFC Errata System [mailto:[email-masked]]
> >>>>>>>>>>> Sent: 12 December 2012 17:45
> >>>>>>>>>>> To: [email-masked]; [email-masked];
> >>>>>>>>>>> [email-masked]; [email-masked];
> >>>>>>>>>>> [email-masked]; [email-masked];
> >>>>>>>>>>> [email-masked]; [email-masked];
> >>>>>>> [email-masked];
> >>>>>>>>>>> [email-masked]
> >>>>>>>>>>> Cc: [email-masked]; [email-masked];
> >>>>>>>>>>> [email-masked]
> >>>>>>>>>>> Subject: [Editorial Errata Reported] RFC6435 (3429)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The following errata report has been submitted for RFC6435,
> >>>>>>>>>>> "MPLS Transport Profile Lock Instruct and Loopback Functions".
> >>>>>>>>>>>
> >>>>>>>>>>> --------------------------------------
> >>>>>>>>>>> You may review the report below and at:
> >>>>>>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=6435
> >> <http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429>
> >> &eid=3429
> >>>>>>>>>>>
> >>>>>>>>>>> --------------------------------------
> >>>>>>>>>>> Type: Editorial
> >>>>>>>>>>> Reported by: David Ball<[email-masked]>
> >>>>>>>>>>>
> >>>>>>>>>>> Section: 4 (para 5)
> >>>>>>>>>>>
> >>>>>>>>>>> Original Text
> >>>>>>>>>>> -------------
> >>>>>> applied to
> >>>>>>>>>> data-
> >>>>>>>>>>> plane loopback points residing on different interfaces from
> MIPs/MEPs.
> >>>>>>>>>>>
> >>>>>>>>>>> Corrected Text
> >>>>>>>>>>> --------------
> >>>>>>>>>>> It should be noted that the data-plane loopback function may
> >>>>>>>>>>> be
> >> applied
> >>>>>> at
> >>>>>>>>>>> MIPs/MEPs on different interfaces for different LSPs.
> >>>>>>>>>>>
> >>>>>>>>>>> Notes
> >>>>>>>>>>> -----
> >>>>>>>>>>> The existing text has caused confusion (specifically, among
> >>>>>>>>>>> experts in
> >>>>>> ITU-T
> >>>>>>>>>> SG15
> >>>>>>>>>>> when discussing G.8121.2), in that it seems to suggest that
> >>>>>>>>>>> the
> >>>>>> interface
> >>>>>>>>>> where
> >>>>>>>>>>> the MIP/MEP is located may be a different interface to the
> >>>>>>>>>>> one where
> >> the
> >>>>>>>>>>> loopback is applied.
> >>>>>>>>>>>
> >>>>>>>>>>> Having spoken with some of the original authors, it seems
> >>>>>>>>>>> this was not
> >>>>>> the
> >>>>>>>>>> intent
> >>>>>>>>>>> of this sentence; the intent was to point out that as
> >>>>>>>>>>> different LSPs
> >>>>>> would
> >>>>>>>>>> have
> >>>>>>>>>>> MIPs/MEPs on different interfaces, the corresponding
> >>>>>>>>>>> loopback
> >> functions
> >>>>>>> would
> >>>>>>>>>>> also be applied on different interfaces.
> >>>>>>>>>>>
> >>>>>>>>>>> Instructions:
> >>>>>>>>>>> -------------
> >>>>>>>>>>> This errata is currently posted as "Reported". If necessary,
> >>>>>>>>>>> please use "Reply All" to discuss whether it should be
> >>>>>>>>>>> verified or rejected. When a decision is reached, the
> >>>>>>>>>>> verifying party (IESG) can log in to change the status and edit the
> report, if necessary.
> >>>>>>>>>>>
> >>>>>>>>>>> --------------------------------------
> >>>>>>>>>>> RFC6435 (draft-ietf-mpls-tp-li-lb-08)
> >>>>>>>>>>> --------------------------------------
> >>>>>>>>>>> Title               : MPLS Transport Profile Lock Instruct
> >>>>>>>>>>> and
> >> Loopback
> >>>>>>>>>> Functions
> >>>>>>>>>>> Publication Date    : November 2011
> >>>>>>>>>>> Author(s)           : S. Boutros, Ed., S. Sivabalan, Ed., R.
> >>>>>>>>>>> Aggarwal,
> >>>>>> Ed., M.
> >>>>>>>>>> Vigoureux,
> >>>>>>>>>>> Ed., X. Dai, Ed.
> >>>>>>>>>>> Category            : PROPOSED STANDARD
> Source
> >>>>>>>>>>> : Multiprotocol Label Switching Area                :
> >>>>>>>>>>> Routing Stream              : IETF Verifying Party     :
> >>>>>>>>>>> IESG
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> David Ball
> >>>>>>> <[email-masked]>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> >> --
> >> David Ball
> >> <[email-masked]>
> >
> > --
> > David Ball
> > <[email-masked]>
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>