The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2007-Mar> msg00406



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] mpls working groups lastcallondraft-ietf-mpls-ldp-typed-wildcard-00

  • From: "Bob Thomas \(rhthomas\)" <rhthomas@cisco.com>
  • Date: Fri, 30 Mar 2007 09:00:05 -0400
  • Authentication-Results: rtp-dkim-2; header.From=rhthomas@cisco.com; dkim=pass (sig from cisco.com/rtpdkim2001 verified; );
  • Cc: Ross Callon <rcallon@juniper.net>, David Ward <dward@cisco.com>, mpls@ietf.org
  • DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4362; t=1175259615;x=1176123615; c=relaxed/simple; s=rtpdkim2001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=rhthomas@cisco.com;z=From:=20=22Bob=20Thomas=20\(rhthomas\)=22=20<rhthomas@cisco.com>|Subject:=20RE=3A=20[mpls]=20mpls=20working=20groups=20last=20callondraft-ietf-mpls-ldp-typed-wildcard-00 |Sender:=20|To:=20=22Metz,=20E.T.=20\(Eduard\)=22=20<Eduard.Metz@tno.nl>;bh=O5+Ao7cbcfvTmU4CKEs738u0aOmSmOuDPRTBNr63fvI=;b=vt+Tc1hhGEQVLPN2u3zbBDgUJcujVVQsTkLBTys/y7x09GbbyFqD0b+1OQNQL3XzU8zqmxBvKZSnBDhj04qnHH/Wwg8FYJtMztHn6LGx8PZZdBkfQDxfXBpFp5GJjwFo;
  • Thread-Index: AcdwctlVhx6hYfNXSaSg7XeDsV11nwA2TTngADwVzsA=
  • Thread-Topic: [mpls] mpls working groups lastcallondraft-ietf-mpls-ldp-typed-wildcard-00
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id l2UCuts10638
  • X-OriginalArrivalTime: 30 Mar 2007 13:00:07.0093 (UTC)FILETIME=[573D9650:01C772CB]

Eduard,

Thanks for your comments.  Please search for #bt for some follow up.

Bob


> A few comments / questions:
> 
> ----
> Is the intention of the Typed Wildcard FEC element to replace 
> or to be complementary to the existing Wildcard FEC type? 

#bt
The intent is to be complementary to the existing Wildcard FEC type.


> Perhaps this could be briefly clarified in the draft. While 
> reading I wondered whether it is possible to do same with the 
> Typed Wildcard FEC as can be done with the Wildcard FEC Type, 
> ie if a Prefix Typed Wildcard FEC (as specified in section 5) 
> is followed by a Label TLV should be behavior be expected to 
> be same as that of the Wildcard FEC Type (e.g. in a Label release)?

#bt
Roughly speaking yes.  More precisely, a Label Release message carrying
an rfc3036 Wildcard FEC Type in the FEC TLV and a Label TLV would cause
the specified label to be released for all FECs regardless of type.  A
Label Release message carrying a Typed Wildcard FEC Element in the FEC
TLV and a Label TLV would cause the specified label to be released for
all FECs of the  specified type.


> ----
> Section 4:
>    Receipt of a Label Request message with a FEC TLV 
> containing a Typed
>    Wildcard FEC Element is interpreted as a request to send a Label
>    Mapping for all FECs of the type specified by the FEC 
> Element type in
>    the Typed Wildcard FEC Element encoding.
> 
> => replace "FEC Element type" with "FEC type"? Assuming FEC 
> type refers to all the information carried in the in Typed WC 
> FEC Element regarding the FEC, not just the FEC Element type. 
> FEC type also seems to be used in other parts of the document.

#bt:
I think the text:

   ... FEC Element type in the Typed Wildcard FEC
   Element encoding.

in the above should be replaced by the text:

   ... FEC Element Type field in the Typed Wildcard
   FEC Element encoding.

I agree that the use of "FEC type" in other parts of the document are
OK.


> ----
> The suggested FEC Type seems to be in use in already:
> 0x04        CR-LSP                              [RFC3212]

#bt:
Thanks for pointing that out.  It will be corrected in the next revision
of the draft.


> ----
> The draft specifies the Typed Wildcard FEC element for the 
> Prefix FEC type. Does this imply that for the other FEC types 
> defined in the LDP RFC (Wildcard and Host-address) typed 
> wildcarding is not required (or not allowed)?

#bt:
The Host Address type is being removed from LDP (see the latest revision
of draft-ietf-mpls-rfc3036bis-xx.txt).  The motivation for the typed
wildcard draft is to correct deficiencies in the rfc3036 Wildcard FEC
type.

Thanks,
Bob

> cheers,
> 	Eduard 
> 
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.se]
> > Sent: woensdag 28 maart 2007 15:11
> > To: mpls@ietf.org
> > Cc: Ross Callon; David Ward
> > Subject: [mpls] mpls working groups last call 
> > ondraft-ietf-mpls-ldp-typed-wildcard-00
> > 
> > Working Group,
> > 
> > this is to initiate a two week working group last call on 
> the working 
> > group draft "LDP Typed Wildcard FEC".
> > 
> > The document will be found at:
> > http://tools.ietf.org/html/draft-ietf-mpls-ldp-typed-wildcard-00
> > 
> > Please review and sent your comments to the mailing list or 
> directly 
> > to the working group co-chairs.
> > 
> > The working group last call will end EOB March 11 PDT.
> > 
> > Loa and George
> > 
> > --
> > Loa Andersson
> > 
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  loa.andersson@acreo.se
> >                                            loa@pi.se
> > 
> > _______________________________________________
> > mpls mailing list
> > mpls@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/mpls
> > 
> 
> This e-mail and its contents are subject to the DISCLAIMER at 
> http://www.tno.nl/disclaimer/email.html
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls