The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Identifier Semantics [Re: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt]
I see absolutely no need for this change. First it is possible (though perhaps unlikely) that a tunnel head end will need to break up a P2MP tree for scalability reasons and want to keep the same P2MP ID. Second an implementation may find it convenient to interally assign tunnel IDs and index on these. What difference would it make to any midpoint or endpoint if this field "Should" be a constant zero or not? ...George > Hi Folks, > > Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID > semantics as part of the last call and a discussion followed on this list. > > In order to resolve this discussion I had proposed some text. I have > received some comments on this offline and want to move this discussion to > a broader audience. > > Please comment on the text changes below, if you have objections or > suggestions. Else this will be incorporated in the next version of the > spec. > > How about the following rephrasing: > > 1. > > Section 4.1: > > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > > The P2MP ID provides an identifier for the set of destinations of the > P2MP TE Tunnel." > > to > > " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes a tuple > <Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP > ID) is unique within the scope of the IP address of the ingress LSR. The > Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP > Tunnel identifier, carried in the P2MP SESSION object, is unique within > the same scope as the ingress LSR IP address. > > The fields of the P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP ID field." > > 2. > > Section 4.2. > > " A P2MP LSP is identified by the combination of the P2MP ID, Tunnel > ID, and Extended Tunnel ID that are part of the P2MP SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." > > to > > " A P2MP LSP is identified by the combination of the P2MP ID, > Extended Tunnel ID that are part of the P2MP SESSION object, > and the tunnel sender address and LSP ID fields of the P2MP > SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is > defined in section 20.2." > > 3. > > 19.1.1 > > "P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP ID and identifies the set of destinations of the P2MP > Tunnel." > > to > > "P2MP ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It encodes the > P2MP Identifier that is unique within the scope of the Ingress LSR > IP address carried in the Extended Tunnel ID. > > 4. > 19.1.1 > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel." > > to > > "Tunnel ID > > A 16-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. It SHOULD be set to 0 > by the ingress LSR and be ignored on receipt." > > > 5. > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. Normally set to > all zeros. Ingress nodes that wish to narrow the scope of a > SESSION to the ingress-PID pair may place their IPv4 address > here as a globally unique identifier [RFC3209]." > > to > > "Extended Tunnel ID > > A 32-bit identifier used in the SESSION object that remains > constant over the life of the P2MP tunnel. This identifier > MUST be set to the ingress LSR's IPv4 address." > > 6. > > 19.1.2 > > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID may be set to a 16 byte identifier > [RFC3209]." > > to > > "This is same as the P2MP IPv4 LSP SESSION Object with the difference > that the extended tunnel ID MUST be set to a 16 byte identifier that is > the ingress LSR's IPv6 address." > > 7. > > 19.2.1 > > " IPv4 tunnel sender address > See [RFC3209]" > > to" > > "IPv4 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." > > 8. > > 19.2.2 > > "IPv6 tunnel sender address > See [RFC3209]" > > to > > "IPv6 tunnel sender address. This address MUST be the same as the address > in the Extended Tunnel ID field of the SESSION object." > > Thanks, > rahul > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls -- Elisheva Halevy Hochberg 978-936-1362 ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|