Sasha, I think that a comment similar to yours have been raised during WG LC and resolved by adding section 3.8 Please let us know if there are any specific issues with section 3.8 you wish to be addressed as part of the IETF LC. Thanks, Italo > -----Messaggio originale----- > Da: Alexander Vainshtein [mailto:Alexander.Vainshtein@xxxxxxxxxxx] > Inviato: lunedì 15 novembre 2010 13.29 > A: BUSI, ITALO (ITALO) > Cc: mpls-tp@xxxxxxxx; adrian@xxxxxxxxxxxx; ietf@xxxxxxxx > 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@xxxxxxxx; adrian@xxxxxxxxxxxx > 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.busi@xxxxxxxxxxxxxxxxxx] > Sent: Monday, November 15, 2010 12:54 AM > To: Alexander Vainshtein; adrian@xxxxxxxxxxxx > Cc: mpls-tp@xxxxxxxx > 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@xxxxxxxx [mailto:mpls-tp-bounces@xxxxxxxx] Per conto > > di Alexander Vainshtein > > Inviato: venerdì 12 novembre 2010 11.37 > > A: adrian@xxxxxxxxxxxx > > Cc: mpls-tp@xxxxxxxx > > 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@xxxxxxxx [mpls-tp-bounces@xxxxxxxx] On Behalf Of > > Adrian Farrel [adrian@xxxxxxxxxxxx] > > Sent: Thursday, November 11, 2010 6:28 PM > > To: 'D'Alessandro Alessandro Gerardo' > > Cc: mpls-tp@xxxxxxxx > > 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf