Subject: [mpls] one more thing on per-interface MIP addressing...

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Dec 2012 10:50:09 +0000

Hi,

let me add one more thing to the discussion. We had many of these discussions at various places like the mailing list, the meetings etc. The fixed location ID TLV e.g. was one of those and I attached one dated Email exchange on this, where I argued that this would be beneficial for an implementation at line rate. This is about 20 months ago. I really appreciate the debate we are having at the moment (I only wish we had it at the time when we discussed the various options and not during last call). So what I would like to say is that we should not go through all possible HW-friendly options again that have been discussed (at least not without going through the mailing list archives before hand) and reiterate the same discussions we had 2 years ago. I don't mind discussing two, but let as not add more.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rolf Winter
> Sent: Montag, 28. März 2011 12:19
> To: Eric Gray
> Cc: [email-masked]
> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-
> demand-cv-03
> 
> Hi,
> 
> I still think there is a logical error. Let me explain. In case there
> is no IP you simply cannot use it. You say you could enable IP but then
> that is not a case where there is no IP. In order to be constructive
> here is a text change suggestion:
> 
> "In certain MPLS-TP deployment scenarios IP addressing might not be
> available. In those cases On-demand CV and/or route tracing MUST be run
> without IP addressing, using the ACH channel type specified in Section
> 3. In other cases it might be available, however, it may be preferred
> to use some form of non-IP encapsulation. In those cases, the
> procedures as outlined in section 3 SHOULD also be used."
> 
> Regarding the per-interface MIP discussion. The HW aspect also popped
> up in the PWE3 session and I think this is an important consideration,
> in particular for OAM. Even if we talk about TLVs, we could make it a
> MUST that an Address TLV is always the first one to appear. If you can
> facilitate an easy implementation in hardware, I see no reason to
> deliberately not do it.
> 
> Best,
> 
> Rolf
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> 
> > -----Original Message-----
> > From: Eric Gray [mailto:[email-masked]]
> > Sent: Montag, 28. März 2011 11:43
> > To: Rolf Winter
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-
> > demand-cv-03
> >
> > Rolf,
> >
> > 	With regard to the use of SHOULD (verses MUST) - the intent
> > (according to RFC 2119 - see the quote below) is consistent with this
> > case.  If - for some reason - one had a really good reason to use IP
> > addressing in some specific case, one could take steps to make IP
> > addressing available.
> >
> > 	This could be said to introduce a logical disconnect, but we are
> > saved from going down that path by the fact that the statement also
> > includes the case where (for some reason) there is a case in which
> > some other addressing scheme might be preferred.  In many of the
> cases
> > where another addressing scheme may be preferred, it is still
> possible
> > (in fact likely) that IP addressing is available.
> >
> > 	Otherwise, it would not have been necessary to distinguish this
> case
> > from the one in which IP addressing is not available.
> >
> > 	For the case where IP addressing is not the preferred mode, we
> are
> > recommending a mode in which it is not necessary.
> >
> > 	With regard to having addresses located in the same place, this
> > protocol is meant for connectivity testing on an on-demand basis and
> > is therefore not optimized for processing in hardware.
> >
> > 	Whether addresses or identifiers, if we are talking about TLV
> > contents, there are issues with trying to guarantee location of
> > specific content, because of the fact that the TLV in question will
> > probably follow other TLVs - thus making locations difficult to
> > predict in any case.
> >
> > 	With regard to needing more text on per-interface MIPs, do you
> have
> > specific suggestions as to what text we might add?
> >
> > 	I understand (from discussion with WG chairs) that we are not
> allowed
> > to explicitly address last call comments during the IETF meeting in
> > Prague, because the last call is still ongoing at that time.
> >
> > --
> > Eric
> >
> > PS -
> > From RFC 2119 -
> > 'SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> >           may exist valid reasons in particular circumstances to
> >           ignore a particular item, but the full implications must
> >           be understood and carefully weighed before choosing a
> >           different course.'
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Rolf Winter
> > Sent: Tuesday, March 22, 2011 4:57 AM
> > To: [email-masked]; [email-masked]
> > Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-
> > demand-cv-03
> >
> > Hi,
> >
> > some comments below:
> >
> > Section 1.3 says: " In certain MPLS-TP deployment scenarios IP
> > addressing might not be
> >    available or it may be preferred to use some form of non-IP
> >    encapsulation for On-demand CV, route tracing and BFD packets.  In
> >    such scenarios, On-demand CV and/or route tracing SHOULD be run
> >    without IP addressing..."
> >
> > I am not sure the "SHOULD" is right here. If no IP addressing is
> > available, this thing MUST be run without IP addressing, mustn't it?
> >
> > I think some additional text regarding per-interface MIP addressing
> > would be nice. As far as I understand the document, all TLVs will be
> > inside the LSP ping packet (rather than as ACH TLVs).
> >
> > Some people had concerns earlier, that addressing information should
> > be in a fixed location for easier processing. Is this the case here I
> > wonder?
> >
> > It would be nice if you could address this in your presentation in
> > Prague.
> >
> > Thanks,
> >
> > Rolf
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > [email-masked]
> > > Sent: Mittwoch, 16. März 2011 00:26
> > > To: [email-masked]
> > > Cc: MPLS-TP ad hoc team
> > > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-
> > demand-
> > > cv-03
> > >
> > > Working Group,
> > >
> > > this is to start a 3 week working group last call on
> > >
> > > draft-ietf-mpls-tp-on-demand-cv-03
> > >
> > > Please send comments to the working group mailing list
> [email-masked]
> > >
> > > The working group last call ends on April 8, 2011.
> > >
> > > /Loa
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls