logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

RE: (resend) Working group last call: PWE3 PPP assignmen t: msg#00012

Subject: RE: (resend) Working group last call: PWE3 PPP assignmen t
> From: "David Allan" <dallan@xxxxxxxxxxxxxxxxxx>
> To: "'Vernon Schryver'" <vjs@xxxxxxxxxxxxxxxxxxxx>, pppext@xxxxxxxx
> Cc: margaret@xxxxxxxxxxxxxx, narten@xxxxxxxxxx, ohta.hiroshi@xxxxxxxxxxxxx

> We had a problem in the MPLS space where existing implementations snooped
> payload in do Equal Cost Multi-Path (ECMP) and simultaneously preserve flow
> ordering. If it looked like an IP packet, use IP address information in
> doing the path choice. Most implementations also use the label stack. Normal
> mode of operation being to hash a path selection out of label stack and
> payload information.
>
> Net result of this was if the payload was not IP, (as in a psuedo wire) then
> all mechanisms for distinguishing OAM flows were impacted. If you used a
> reserved label, your OAM PDU would not have the same forwarding as the
> payload flow of interest. If you used an IP packet, the forwarding would not
> follow the payload flow of interest. 
>
> So the PW group came up with the PW PID which would allow OAM PDUs to be
> multiplexed with a PW flow without appearing as an IP packet to deployed
> ECMP LSRs, and not requiring a reserved label. Hence where we are today...

That's nice, I guess, but what does it have to do with PPP?  As far
as I can tell, you are saying that a PW PID is needed, and since
PPP has a completely unrelated space of date link layer numbers, you
should use one of them.

I must not understand that explanation or analogy with MPLS flow
labelling.  From your document, all occurance of your PW PIDs will
always be identical, always this new PPP DLL number.


Vernon Schryver    vjs@xxxxxxxxxxxx

_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext



<Prev in Thread] Current Thread [Next in Thread>