-----Messaggio originale-----
Da: Alexander Vainshtein
[mailto:Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com]
Inviato: lunedì 15 novembre 2010 13.29
A: BUSI, ITALO (ITALO)
Cc: mpls-tp(_at_)ietf(_dot_)org; adrian(_at_)olddog(_dot_)co(_dot_)uk;
ietf(_at_)ietf(_dot_)org
Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
networks
Italo,
My original comment on SPME has been sent to the list on 07-Jul-10.
You can see it at http://www.ietf.org/mail-archive/web/mpls-
tp/current/msg04369.html .
It has not been posted as an LC comment, presumably because the draft has
not been in any kind of LC at that moment.
Adrian,
Please consider this comment as an IESG LC comment.
Regards,
Sasha
-----Original Message-----
From: Alexander Vainshtein
Sent: Monday, November 15, 2010 9:03 AM
To: BUSI, ITALO (ITALO)
Cc: mpls-tp(_at_)ietf(_dot_)org; adrian(_at_)olddog(_dot_)co(_dot_)uk
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
networks
Italo,
Lots of thanks for a prompt response.
I will look up my archives and resend the specific comment regarding SPME.
But the gist of this comment has been, that SPME is a new LSP, so that
monitoring it does not necessarily say anything about the original LSP
passing thru the segment in question. The simplest use case demonstrating
the difference is a case of incomplete configuration, when the original
LSP has not been configured in one of the internal nodes of the segment,
but SPME was (and vice versa).
Regarding MIPs, I'd like to explain my doubts.
1. We all agree (or so it seems) that intermediate points of LSPs and PWs
can only be reached due to TTL expiration.
2. By default TTL expiration extracts a packet from the data plane and
sends it to the control plane instead.
As per RFC 4379, this process includes preservation of the original
received label stack
and noting the actual ingress interface so that they are available for
the CP processing.
3. Taking (1) and (2) above as given, could you please clarify, what
exactly does it mean if:
(a) A per-node MIP is disabled?
(b) A per-interface MIP is disabled?
4. Are MIPs bound to specific Managed Entities (LSPs)? If they are, what
should happen if:
a) An LSP uses labels from the per-platform label stace, and hence
packets associated with this LSP can
be received from any interface?
b) A per-interface MIP is enabled for this LSP on one interface and
disabled on another one?
Regards,
Sasha
________________________________________
From: BUSI, ITALO (ITALO) [italo(_dot_)busi(_at_)alcatel-lucent(_dot_)com]
Sent: Monday, November 15, 2010 12:54 AM
To: Alexander Vainshtein; adrian(_at_)olddog(_dot_)co(_dot_)uk
Cc: mpls-tp(_at_)ietf(_dot_)org
Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
networks
Sasha,
See in line marked with [ib]
Thanks in advance
Italo
-----Messaggio originale-----
Da: mpls-tp-bounces(_at_)ietf(_dot_)org
[mailto:mpls-tp-bounces(_at_)ietf(_dot_)org] Per conto
di Alexander Vainshtein
Inviato: venerdì 12 novembre 2010 11.37
A: adrian(_at_)olddog(_dot_)co(_dot_)uk
Cc: mpls-tp(_at_)ietf(_dot_)org
Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
networks
Adrian,
I've looked up the MPLS-TP OAM framework draft and it indeed discusses
per-interface MIPs that have not been considered (according to my
reading)
in RFC 5654.
I think that, at the very least, the notion of a per-interface MIP
requires additional clarification. E.g., can you introduce a per-
interface
MIP in an LSP that uses labels from the per-platform space?
[ib] Could you be more specific about how the label space impacts the
support of per-interface vs per-node MIP?
On a more generic level, taking into account that the only way to reach
a
MIP in an LSP is to send a packet that would experience TTL expiration
in
the node of interest, what is the difference in behavior of LSPs with
configured MIPs and LSPs without them?
[ib] We discussed this point during the development of the OAM framework
and we have agreed that every node has MIP(s) and that the operator can
disable them. See the following text extracts from section 3.4:
An intermediate node within a MEG can either:
o Support per-node MIP (i.e. a single MIP per node in an
unspecified location within the node);
o Support per-interface MIP (i.e. two or more MIPs per node on
both sides of the forwarding engine).
And
Once a MEG is configured, the operator can enable/disable the
MIPs on the nodes within the MEG. All the intermediate nodes and
possibly the end nodes host MIP(s). Local policy allows them to
be enabled per function and per MEG. The local policy is
controlled by the management system, which may delegate it to
the control plane.
I hope this would help.
I also note that the framework draft still promotes hierarchy of labels
for SPMEs and/or TCM.
I believe that I've commented on this concept earlier, and in any case I
plan to send an IESG LC comment on this point: IMO my previous comments
in
this regard have not been resolved.
[ib] Could you please re-send your comment? This would help expediting its
resolution as I fear we have missed it. I apologize for that.
Regards,
Sasha
________________________________________
From: mpls-tp-bounces(_at_)ietf(_dot_)org
[mpls-tp-bounces(_at_)ietf(_dot_)org] On Behalf Of
Adrian Farrel [adrian(_at_)olddog(_dot_)co(_dot_)uk]
Sent: Thursday, November 11, 2010 6:28 PM
To: 'D'Alessandro Alessandro Gerardo'
Cc: mpls-tp(_at_)ietf(_dot_)org
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
networks
Hi,
I think the difference in the way we are presenting this lies in me
saying
that we have to have a model and tools that allow vendors to build
equipment that allows operators to deploy MPLS-TP networks that
follow the "legacy transport network" mode of operation.
[Alessandro] It seems to me we are claiming the same thing
It seems to me that you are saying that the architecture must
prohibit
people from building and deploying in other modes, and I can't see
the value of that prohibition.
[Alessandro] No, I haven't said that. I said the architecture must
include
all the constructs that are required to get the above mentioned goal
(e.g. a per interface MIP).
My apologies. It looks like we are perfectly aligned.
In addition, I believe that the OAM Framework (section 3.4 already
includes the
function). So I think we are done.
Adrian
_______________________________________________
mpls-tp mailing list
mpls-tp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
mpls-tp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls-tp