The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] AW: your mail
If there were several NHLFEs there is only one proper interpretation and that is point-to-multipoint i.e. multicast. Either several branches out from the source node, or several branches in the middle of the multicast delivery tree. To interprete whatever pleases you, kills the entire state of the art. Heinrich -----Ursprüngliche Nachricht----- Von: Gray, Eric [mailto:egray@celoxnetworks.com] Gesendet: Dienstag, 2. Juli 2002 17:47 An: 'Hummel Heinrich'; 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: RE: your mail Heinrich, What a standard should not do is unnecessarily constrain implementations. If an implementation has more than one NHLFE for the same label, which one it (the implementation) chooses to use _really_ is an implementation local issue. The standard need not (and should not) say anything about it... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Tuesday, July 02, 2002 11:36 AM To: 'erosen@cisco.com'; Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Subject: AW: your mail Eric, Let me cite section 3.12 of RFC 3031: The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. If the FTN maps a particular label to a set of NHLFEs that contains more than one element,... What kind of logic is applied in saying : "the FTN maps each FEC to blablabla" followed by "if the FTN maps a particular label to blablabla" All I can conclude is, that a label is equal to a FEC. I am sure, I am not the only one who is lost. And if such kind of logic were written into this RFC intentionally, then I think things are getting out of control. Standards are not made that the one guy interpretes the label as a VC-label,the other one as a hint for load balancing, and a third one as a message from the Captain of the Night. BTW: Which signalling TLV of the LSP-establishment message contains the respective interpretation ? Heinrich -----Ursprüngliche Nachricht----- Von: Eric Rosen [mailto:erosen@cisco.com] Gesendet: Dienstag, 2. Juli 2002 17:02 An: Shahram Davari Cc: 'Eric Osborne '; 'George Sheng '; 'scullptor@yahoo.com '; 'mpls@UU.NET ' Betreff: Re: your mail SD=> So you do more than one lookup- so what? so you need to parse the whole SD=> packet in the core-so what? so you need to keep state in the core, Please pay attention. There is not more than one lookup; doing the hash does not require looking anything up. Finding the bottom label does not involve parsing the whole packet. There is no state kept in the core. SD=> so you have no longer a simple label swap It is true that the essence of load balancing over equal cost paths is that the outgoing interface is not chosen solely on the basis of the top label. So? SD=> MPLS was designed to have simple forwarding. Hashing takes it to new SD=> levels of simplification never seen before. You might take a peek at section 3.12 of RFC 3031. |
|