Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map

Right, but the reason was that the TLV can be anywhere, i.e. give more than a single TLV in an OAM frame, there is no guarantee that the TLV will be the first, second, third... Even if you guarantee that the TLV will be the say second TLV, there is no guarantee that the first will be of constant length or always the same and so forth. This requires parsing of TLVs which cannot practically be done in HW at line rate. I understand Shahram to ask for an ID TLV to be required to always be the first TLV independent of the number of TLVs in an OAM frame. Reasons against this that I heard include: "we have never done that and will never do it", "this defeats the purpose of TLVs which are designed with this flexibility", "this is a HW problem not a protocol issue", "what if another TLV comes up that wants to be first too" and others.

Best,

Rolf 

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

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Stewart Bryant
> Sent: Dienstag, 4. Dezember 2012 11:28
> To: mpls@ietf.org
> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-
> mep-map
> 
> No one liked those (for h/w reasons), so we never used them for any
> first generation OAM applications. If you look at the registry you will
> see that none have been defined.
> 
> Stewart
> 
> On 04/12/2012 09:31, Shahram Davari wrote:
> > How about the G-ACH TLV that immediately follows ACH.
> >
> > Regards,
> > Shahram
> >
> >
> > On Dec 4, 2012, at 12:46 AM, "Rolf Winter" <Rolf.Winter@neclab.eu>
> wrote:
> >
> >> Hi,
> >>
> >> quite some time ago we asked whether we could mandate TLV ordering
> (at least mandating one out of N TLVs to be the first in the OAM PDU)
> in order to allow efficient implementation in HW. This actually would
> be a good thing in this case. The responses we got weren't quite
> positive (which is actually quite a positive description of the
> responses we got) but I don't see that the GACh RFC is actually
> disallowing it. Still we would need to go back and make changes to a
> few RFCs. That was also something people weren't really happy about.
> Again, these were some of the constraints we worked with which led to
> what is on the table right now. We weren't blind to HW considerations,
> vice versa as you can see when you look at the appendix that was
> removed in the latest version of the document.
> >>
> >> Best,
> >>
> >> Rolf
> >>
> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> >> London W3 6BL | Registered in England 2832014
> >>
> >>
> >>> -----Original Message-----
> >>> From: Puneet Agarwal [mailto:pagarwal@broadcom.com]
> >>> Sent: Dienstag, 4. Dezember 2012 06:44
> >>> To: hideki.endo.es@hitachi.com
> >>> Cc: Shahram Davari; Rolf Winter; mpls@ietf.org
> >>> Subject: Re: [mpls] working group last call
> >>> ondraft-ietf-mpls-tp-mip- mep-map
> >>>
> >>> Hi hideki,
> >>>
> >>> Is the determination that the mip identifier is present in the same
> >>> location  always in the pdu or is it variable (based on oam msg
> type)?
> >>>
> >>> Thx
> >>>
> >>> Puneet
> >>>
> >>>
> >>>
> >>> On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com"
> >>> <hideki.endo.es@hitachi.com> wrote:
> >>>
> >>>> draft-ietf-mpls-tp-mip-mep-map
> >>
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> 
> --
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls