Subject: RE: Last call on MPLS multicast framework

From: Hummel Heinrich <[email-masked]>
Date: Tue, 9 Jan 2001 10:57:17 +0100

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.
   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 ?
     
   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.

   In PNNI a Multicast-branch bit was advertised by each ATM-switch,IMHO redundantly, because all people assumed that any 
   ATM-Switch provides branching-capable hardware. Well this is good news for ATM-LSRs:they all can branch.
   But how is the situation with LSRs that support the 32-bit label? Can we assume that each of them is capable to
   branch or do we have to assume that in a Multicast-LSP some LSRs are branching-capable while others aren't and that
   for this reason we have to make sure to add new branches only at branching-capable LSRs ?

   There is much more to say technically about MPLS Multicast.

   Politically: I don't think there is a MPLS Multicast yet. Version 04 is equal to version 01. 
   In Orlando a first VPN BOF failed whereby one argument was "let's do basics like Multicast first before we move on to
   higher applications like MPLS VPN". Well, it turned out differently :-)(
   
    Heinrich Hummel
    Siemens AG  

> This message begins a workgroup last call on
> draft-ietf-mpls-multicast-04.txt, "Framework for IP Multicast in MPLS"
>                      
> The last call ends Jan 19, 5pm est.
>                                
> ...George
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
>

---

From: Dirk Ooms <[email-masked]>
Date: Wed, 10 Jan 2001 10:02:09 +0100

Heinrich,

>    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.

>     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).

>    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).

>    Politically: I don't think there is a MPLS Multicast yet. Version 04 is equal to version 01.

I disagree on the first point (multiple implementations exist, some for
more than 2 years).

Regarding the versioning: there was a problem with the IETF database
(they switched to a new one), due to that '2 versions' were skipped. 01
expired in November 2000, I reposted it as 02, but it was renumbered to
04 by the editor because of this database problem.

dirk