Re: [mpls] IPR poll for draft-chen-mpls-source-label

[Mach Chen <[e-mail]>]

Hi Stewart,

OK, if this is the logic, then SL/SLI tells the LSR dispatch the packet to PM engine for accounting then keep processing.

Best regards,
Mach

> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Tuesday, October 21, 2014 7:21 PM
> To: Mach Chen; Carlos Pignataro (cpignata)
> Cc: Eric Rosen; Ross Callon; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label
> 
> GAL tells an LSR what to do with the pkt - it says please  dispatch to the OAM
> handler.
> 
> - Stewart
> 
> On 21/10/2014 10:54, Mach Chen wrote:
> > Hi Carlos,
> >
> > Thanks for sharing your point!
> >
> >> The EL is used for forwarding/dispatch decisions. The SL is metadata,
> >> not used for forwarding. The fundamental change to the dataplane is
> >> using it to carry metadata.
> > If the criteria is whether a label is used for forwarding, how about GAL?
> >
> > Best regards,
> > Mach
> >
> >> -----Original Message-----
> >> From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
> >> Sent: Tuesday, October 21, 2014 5:11 PM
> >> To: Mach Chen
> >> Cc: Stewart Bryant (stbryant); Eric Rosen; Ross Callon;
> >> [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label
> >>
> >> Hi Mach,
> >>
> >> Please find one set of comments inline.
> >>
> >> Thumb typed by Carlos Pignataro.
> >> Excuze typofraphicak errows
> >>
> >>> On Oct 21, 2014, at 3:19 AM, Mach Chen <[e-mail]> wrote:
> >>>
> >>> Hi Stewart,
> >>>
> >>> Please see my replies inline...
> >>>
> >>>> -----Original Message-----
> >>>> From: Stewart Bryant [mailto:[e-mail]]
> >>>> Sent: Monday, October 20, 2014 7:10 PM
> >>>> To: Mach Chen; Eric Rosen; Carlos Pignataro (cpignata); Ross Callon
> >>>> Cc: [e-mail]; [e-mail];
> >>>> [e-mail]
> >>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label
> >>>>
> >>>> Mach
> >>>>
> >>>>> On 20/10/2014 11:04, Mach Chen wrote:
> >>>>> Hi Eric , Carlos, Stewart and others,
> >>>>>
> >>>>> Thanks for the discussion! Sorry for the top post.
> >>>>>
> >>>>> I do think that you're really exaggerating the complexity and
> >>>>> negatives. Given
> >>>> an LSR can support EL, Segment Routing, MVPN, context label, etc,
> >>>> IMHO it's not difficult for such kind of routers to support SL.
> >>>> Those solutions are not the same.
> >>>>
> >>>> ELs - have no impact on the receiver. I admit that they have an
> >>>> impact on the transmitter (but only two labels) but the only flow
> >>>> state is that an EL needs to be generated, you do not need
> >>>> additional transmitter context since this is generated from the packet itself.
> >>>>
> >>>> SR - has no impact at ay node other than the transmitter, and in
> >>>> many cases the impact is one or two labels. It does not change the
> dataplane..
> >>>>
> >>>> Context labels - I am not sure how wide the support  for the
> >>>> general context label use case is.
> >>>>
> >>>> What you are proposing is  a far more fundamental change to the
> >>>> dataplane than any of the above.
> >>> I may have different view on this, let me make a little bit
> >>> comparison between
> >> SL and EL:
> >> The EL is used for forwarding/dispatch decisions. The SL is metadata,
> >> not used for forwarding. The fundamental change to the dataplane is
> >> using it to carry metadata.
> >>
> >>> 1) For ingress LSR, it's almost the same, except that EL requires
> >>> the ingress LSR to generate the Entropy, then both just put
> >>> information into the label stack;
> >>>
> >>> 2) For transit LSR, EL requires the LSR to know how to handle the
> >>> ELI and EL, otherwise cannot benefit from the EL; SL does not bring
> >>> any requirement to transit LSR;
> >>>
> >>> 3) For egress LSR, it's almost the same, pop the EL/SL; of cause,
> >>> when do SL based PM, the egress LSR has to use the SL for
> >>> accounting, but such accounting is basic and necessary work for PM;
> >>>
> >> Extrapolating from your argument, we could add a number of labels to
> >> the stack that do not carry forwarding instructions without any concerns. SL,
> what's next?
> >>
> >>> Based above, from the dataplane point of view, the processing and
> >>> complexity is as the same level of EL, and it DOES NOT bring
> >>> "fundamental" change to the dataplane;
> >>>
> >> The change, in my view, is in the semantics of the label.
> >>
> >> Given how fundamental this is (in my mind) it calls for a more
> >> comprehensive understanding of the problem being solved.
> >>
> >> Thanks,
> >>
> >> Carlos.
> >>
> >>>>> I looked though the whole discussions so far, and I am not going
> >>>>> to reply each
> >>>> email one by email, I summarized the topics as follows:
> >>>>> 1) Requirement
> >>>>> Whether the requirement is compelling depends on whether you need
> >>>>> it. We
> >>>> did receive the requirements from SPs to support passive PM for
> >>>> MP2P based LSPs, especially for the case of MPLS based IP backhaul
> >>>> network. So for those SPs, it's a compelling requirement. Indeed,
> >>>> PM is not an easy work, and in IETF, several dedicated WGs work on
> >>>> PM related stuff, some WGs have worked on it over decade.
> >>>> I am not disputing the requirement for a method of measuring loss
> >>>> of customer traffic.
> >>>>
> >>>> However the requirement for domain wide source labels is not
> >>>> established. It is one method of identifying the source in a PM
> >>>> measurement, but it is not the only method.
> >>> Actually, the latest version DOES NOT require domain wide source
> >>> labels, the
> >> source label is just a carrier that is used to carry the domain wide
> >> unique Source Identifier (SI); the SI is transparent to the SL, from
> >> the convey information point of view, it's the same as EL.
> >>>>> This draft is mainly about how to do source identification that is
> >>>>> one of the critical requirements of the passive PM,
> >>>> It is about one method. The method you propose is not the only method.
> >>>>
> >>>> Also you have jumped directly to a S-D identification approach,
> >>>> without justifying this as being the required unit of identification.
> >>> Other than S-D identification, I am not sure that there are other
> >>> ways that could
> >> be used to perform passive PM. I noticed you mention destination
> >> based approach in another email, can you please elaborate how it works?
> >>>>> it is not intended to cover all aspects of PM. This is clearly
> >>>>> stated in the
> >>>> document. Other aspects, for example, the multiple line cards in
> >>>> the egress as Stewart pointed out, I do really think that is an
> >>>> implementation issue. For that case, you do need a centralized
> >>>> component to sum up and analyze the statistics and their correlations.
> >>>> It is not that simple as you know from your other draft, and it
> >>>> does not make sense to me to address the two requirements as ships
> >>>> in the night
> >> solutions.
> >>>> Given that you receive a packet on one line card, you have no idea
> >>>> whether a packet received on another line card (or even line
> >>>> interface on that card) was transmitted before of after the one you
> >>>> are taking as your accounting reference point.
> >>> We have a prototype doing IP based passive PM and do consider such
> >>> scenario
> >> and it works. In this case, you do need a centralized component
> >> (which could reside in a linecard, the main control card or an
> >> external entity (e.g., NMS)) that can collect all statistic information of the
> tested flow.
> >>>>> 2) Label stack depth
> >>>>> Regarding the label stack depth, there were some related
> >>>>> discussions (including
> >>>> this WG and other WGs) , some vendors have showed that is not a big
> >>>> problem, especially for those new generation modern routers/switches.
> >>>> That is an assumption that you need to justify, particular at the network
> edge.
> >>> We will see such devices come out, especially when Segment Routing
> >> progressing.
> >>>>> 3) Granularity
> >>>>> It depends on how you use it. In theory, the solution can support
> >>>>> any number
> >>>> flows. But there always be some tradeoff, as I replied in a
> >>>> precious email, the SI number itself is not the issue, the HW
> >>>> resource (e.g., the timers) is the critical constraint. That means,
> >>>> you cannot expect a router to
> >> support unlimited flows.
> >>>> For SI number, I guess that the main concern is mainly about the
> >>>> state maintenance and advertisement, actually it could be optimized
> >>>> to maintain and advertize a single SI block for each LSR. This way,
> >>>> the state and advertisement is a fixed number corresponding to the
> >>>> number
> >> of the LSR in the domain.
> >>>> The timers can be in s/w in the supervisor, since the time that a
> >>>> measurement is taken is not critical, so whilst there might be a
> >>>> filter and counter issue in the h/w, though no worse than IPFIX,
> >>>> there is not
> >> h/w issue with timers.
> >>> It depends on how you implement the measurement, timer for
> >>> measurement
> >> is important, it sometime determines the accurate of the measurement.
> >> And I also agree that filter and counter are the other critical
> >> issues. And all these belong to the HW resource. So, I am trying to
> >> say, when consider these HW constraints, the SI state should be not a
> >> bit deal. Because you cannot monitor unlimited flows on a device.
> >>> Best regards,
> >>> Mach
> >>>
> >>>> Stewart
> >>>>> Best regards,
> >>>>> Mach
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: mpls [mailto:[e-mail]] On Behalf Of Eric Rosen
> >>>>>> Sent: Saturday, October 18, 2014 6:20 AM
> >>>>>> To: Carlos Pignataro (cpignata); Ross Callon
> >>>>>> Cc: [e-mail]; [e-mail];
> >>>>>> [e-mail]
> >>>>>> Subject: Re: [mpls] IPR poll for draft-chen-mpls-source-label
> >>>>>>
> >>>>>> Carlos> Basically, two or three labels are added to the label
> >>>>>> Carlos> stack,
> >>>>>>
> >>>>>> Actually, that's two or three labels per LSP.  A packet may be
> >>>>>> going through a nested set of LSPs, which each label in the stack
> >>>>>> representing one
> >>>> of those LSPs.
> >>>>>> Each LSP may have its own source label.  Since a source label is
> >>>>>> likely to require three label stack entries, the number of labels
> >>>>>> in the stack
> >>>> could be quadrupled.
> >>>>>> And for what?
> >>>>>>
> >>>>>> Carlos> the document only lists PM as the application that needs
> >>>>>> Carlos> source
> >>>> labels.
> >>>>>> There doesn't seem to be general agreement that this is a
> >>>>>> compelling use
> >>>> case.
> >>>>>> Certainly not compelling enough to justify the complexity and the
> >>>>>> overhead that it brings.
> >>>>>>
> >>>>>> Carlos> What happens if a finer granularity than the source node
> >>>>>> Carlos> is
> >> needed?
> >>>>>> This is inevitable.  How long before folks are complaining "we
> >>>>>> can't run our network unless the egress LSR can determine the
> >>>>>> ingress interface for each packet".  This could lead to thousands
> >>>>>> of source label
> >>>> values for each ingress LSR.
> >>>>>> And what will happen when someone decides that the granularity
> >>>>>> needs to be per-subscriber, not merely per-interface?
> >>>>>>
> >>>>>> And it's not just "finer granularity" we have to worry about.
> >>>>>> What if someone decides that an ingress LSR needs to convey an
> >>>>>> arbitrary amount
> >>>> of "meta-data"
> >>>>>> about an LSP to the egress LSR.  Will the label stack become a
> >>>>>> set of labels alternating with meta-data containers?
> >>>>>>
> >>>>>> Do we really want to put stuff that doesn't affect the packet
> >>>>>> forwarding into the label stack?  Where will we draw the line?
> >>>>>>
> >>>>>> I don't think the authors really intend the mechanism to be
> >>>>>> generalized in this manner.  They're probably thinking "But we
> >>>>>> only intend for this to be deployed in a very simple case, where
> >>>>>> packets are being tunneled, where the ingress LSR knows who the
> >>>>>> egress LSR is, where they're in the same administrative domain, etc. etc.
> >>>>>> You're really exaggerating the negatives."  But the proposed
> >>>>>> mechanisms do lend themselves to abuse or this sort.  Once we
> >>>>>> start putting stuff in the label stack that isn't used for
> >>>>>> forwarding, how will we know
> >>>> when to stop?
> >>>>>> Carlos> Given this dramatic set of extensions and strong
> >>>>>> Carlos> requirements, it seems
> >>>>>> prudent to me to better understand the problem space of PM gaps
> >>>>>> before adopting a solution.
> >>>>>>
> >>>>>> I agree.  I think Stewart has made a good case that further
> >>>>>> analysis is
> >>>> needed.
> >>>>>> The problem isn't that there is no use for source labels, the
> >>>>>> problem is that the mechanism seems to bring a lot of problems
> >>>>>> with it.  Is this really the only solution?  And if so, is it so
> >>>>>> important to be able to do PM that we should be willing to take
> >>>>>> on all these
> >> problems?
> >>>>>> I also think the proposed LDP and BGP extensions are problematic,
> >>>>>> but those issues are really of secondary importance right now.
> >>>>>>
> >>>>>> So I don't support the adoption of this draft.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> mpls mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>> _______________________________________________
> >>>>> mpls mailing list
> >>>>> [e-mail]
> >>>>> 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
> > .
> >
> 
> 
> --
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html