The MPLS WG Archive

[Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>]

My newer comments are inserted. 

> Hummel Heinrich wrote:
> > 
> > 
> >    TTL, see Section 2 and 10.1 in draft-ietf-mpls-multicast-04.txt:
> >    There cannot be an endless looping LSP as the IP-Header of LSP-setup messages have a TTL.
> 
> An LSP-setup message is going hop-by-hop, so it can endlessly go
> hop-by-hop.
	  And this LSP-setup message has no IP-Header with a TTL field that can be used to detect an eventual endless loop ?



> >    So why is the TTL field  part of the classical label at all? And why these tears about the lack of
> >     a TTL field in ATM/FR labels ?
> 
> To avoid loops (but I won't spend more words to it, because this is
> outside the scope of this draft).
> 
> > 
> >    For the same reason:Scoping of Multicast does not need the TTL-field in the label. It is enough if
> >    the JOIN or SUBSCRIBE message has a TTL field in the IP-header.
> > 
> >    While I think the TTL in the label is superfluous, I miss a Multicast-Bit in the label.
> >    In the ATM Forum we had a lot of discussions whether we can assume that each ATM switch is capable to branch, i.e.
> >    can support multiple oifs. With respect to MPLS-hardware:  Is every NHLFE prepared to have multiple oifs/outgoing
> >   labels? If there is no Multicast-Bit inside the label of each incoming label-switched packet, then this bit
> >    somehow must be part of each NHLFE.
> 
> 
> We are not assuming that every LSR supports point-to-multipoint LSPs. 
> The branching-capability will become clear during the LSP set-up phase
> (if an LSP is requested for a multicast FEC), there is no need to carry
> this information in the data.  Anyhow, even from the data one knows
> whether the LSP carries unicast or multicast traffic since the lower
> layer indicates whether the label is a unicast or a multicast label (see
> draft-ietf-mpls-label-encaps-08.txt). 
	   
	Right. And I know that there is no necessity to have such a Multicast-flag in the label. Nevertheless I can imagine that it could be advantageous
	for building MPLS hardware. It is not unusual that a protocol organizes itself.

	More important: Branching capability.
	How can a JOIN message navigate towards a branching capable router ? All it knows is a root (sender S, or Rendez-vous Point RP) by which it is guided!

	Another point:
	In case there is no branching capable LSR between the sender and the very first receiver, then I think the Multicast is over. Isn't it ? How is it garanteed
	that this won't happen ?    

	  Heinrich